Developer discussion for Creative Commons technology and tools

[Jon Phillips <jon AT rejon.org>]

Cool...please update the cc wiki page about XMP with what you are
doing...

http://wiki.creativecommons.org/XMP

this is all great...

On Sat, 2007-03-24 at 14:22 -0500, Terry Hancock wrote:
> 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
> 
-- 
Jon Phillips

San Francisco, CA
USA PH 510.499.0894
jon AT rejon.org
http://www.rejon.org

MSN, AIM, Yahoo Chat: kidproto
Jabber Chat: rejon AT gristle.org
IRC: rejon AT irc.freenode.net