Skip to Content.
Sympa Menu

cc-devel - [cc-devel] XMP Developer Challenges and Announcing "Palimpsest"

cc-devel AT lists.ibiblio.org

Subject: Developer discussion for Creative Commons technology and tools

List archive

Chronological Thread  
  • From: Terry Hancock <hancock AT anansispaceworks.com>
  • To: CC Developer Mailing List <cc-devel AT lists.ibiblio.org>
  • Subject: [cc-devel] XMP Developer Challenges and Announcing "Palimpsest"
  • Date: Sat, 24 Mar 2007 14:22:55 -0500

I recently became interested in CC's XMP Developer Challenges, which
recommended providing support for Adobe XMP embedded metadata tagging
for multimedia files.

I have a project that would benefit significantly from better tools
for handling metadata, so I am now developing one, to be called
"Palimpsest", which provides a Python module for processing multimedia
metadata:

Palimpsest 0.1-alpha

So far, it only knows about GIF files, though I have implemented the
XMP Scanner concept described in the Adobe XMP Specification as the
fallback plugin.

I have immediate plans to develop JPG, PNG, SVG, Ogg Vorbis, and FLAC
format plugins.

Plugins for Palimpsest are easy to write, and I have provided HTML
documentation on how to do this with the package. So, you can quickly
expand this list to include your favorite multimedia formats. I can
immediately suggest: WAV, MIDI, PDF, PS, Blend (Blender), MP3 as likely
candidates for contributed plugins.

The current user interface is rather primitive and does not yet live up
to my expectations of the project. The documentation explains both how
things work now, and how I plan for them to work. Major TODOs include
providing Dublin Core adaptation both for "native named fields" and for
XMP data, as well as interchange between the two. I also plan to add a
"Notices" interface which will allow usage as simple as this:

>>> from palimpsest import Palimpsest
>>> f = Palimpsest("myfile.jpg")
>>> f.copyright = (2007, 'Terry Hancock', 'CC-By-SA 2.5')
>>> f.write("myfile.jpg")
>>>
[...]
>>> f = Palimpsest("myfile.jpg")
>>> f.copyright
'(C) 2007 Terry Hancock / CC-By-SA 2.5'
>>>

More complex interfaces will allow read/write access to just about any
metadata that can be embedded into multimedia files.

Please read the HTML documentation in the package for more detail. I'll
post the URL when I get it put online.

Obvious uses would be for web applications like ccHost, mediawiki, or
Plone (and whatever Flickr is using) to automatically tag uploads with
embedded metadata, and of course for client programs that can read the
embedded data from already downloaded files. I decided to focus on just
writing the standalone Python module, because it should be easy to
incorporate into a wide variety of applications.

There is not yet a command-line script, but it would obviously be easy
to write one using it.

HOW TO GET PALIMPSEST 0.1-alpha:

Package download URL (from Sourceforge project site):

http://sourceforge.net/project/showfiles.php?group_id=8578

The 0.1-alpha contains the full source and unit tests. 0.1-alpha-dev
adds about 2.5 MB of test files in /moretests for testing new filetype
plugins (I probably need to find or make a shorter Ogg Vorbis file).

Subversion repository browsing interface:

http://light-princess.svn.sourceforge.net/viewvc/light-princess/palimpsest/

Please contact me if you need more information or run into problems with
writing plugins or other use of the package. I am subscribed to the CC
Developer ML.


Some things I'd like to discuss about the (not yet written) high-level
interface design include:

What to do with XMP data or adapted Dublin Core data once we have it.
Can we define "math" operators for concepts like "combination",
"derivation", "collection", etc?

e.g.:

xmp_collab = xmp1 & xmp2

would create an XMP (or DC?) object to represent the correct attribution
and licensing of a work which derives from the works from which xmp1 and
xmp2 are taken?

Or maybe there should be helper functions like:

xmp_collab = derivation(xmp1, xmp2)

instead.

What kind of interface would you like? What concepts should it incorporate?

I support four types of data: native named fields, XMP packets,
free-form comments, and visible text fields. There are advantages and
disadvantages to each, so I don't think it's possible to condense things
much further. Music players, for example, expect to use native fields to
display artist and song title, so XMP alone isn't good enough. Visible
fields are a bit controversial (are they really metadata?), but should
be very handy for things like XML documents that contain attribution and
licensing statements that are rendered as part of the content.

Comments invited.

Cheers,
Terry

--
Terry Hancock (hancock AT AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com





Archive powered by MHonArc 2.6.24.

Top of Page