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

Conrad Parker conrad at metadecks.org
Sun Mar 25 04:20:37 EDT 2007


Hi,

when you get to working on Ogg files (Ogg Vorbis, Ogg Theora etc.)
then please drop an email to ogg-devel at xiph.org :-)

I'm a maintainer of vorbis-tools (oggenc, ogg123 etc.) and I'm
interested in including support for CC standards. The details of
including XMP data have not been worked through for Ogg files, and it
would be good to ensure things interoperate.

Also, feel free to drop by #annodex on irc.freenode.net for chat about
related standards for embedding metadata in multimedia.

cheers,

Conrad.

On 25/03/07, Terry Hancock <hancock at anansispaceworks.com> 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
>
> --
> Terry Hancock (hancock at AnansiSpaceworks.com)
> Anansi Spaceworks http://www.AnansiSpaceworks.com
>
> _______________________________________________
> cc-devel mailing list
> cc-devel at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/cc-devel
>
>



More information about the cc-devel mailing list