Skip to Content.
Sympa Menu

cc-devel - Re: [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: Jon Phillips <jon AT rejon.org>
  • To: Terry Hancock <hancock AT anansispaceworks.com>
  • Cc: CC Developer Mailing List <cc-devel AT lists.ibiblio.org>
  • Subject: Re: [cc-devel] XMP Developer Challenges and Announcing "Palimpsest"
  • Date: Tue, 27 Mar 2007 15:09:41 -0700

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





Archive powered by MHonArc 2.6.24.

Top of Page