discussion of the Creative Commons Metadata work

[Mike Linksvayer <ml AT creativecommons.org>]

On Fri, 2005-12-23 at 17:37 -0500, Tim Olsen wrote:
> On 12/23/05, Mike Linksvayer <ml AT creativecommons.org> wrote:
> > A long time ago there was some discussion concerning license metadata in
> > files disassociated from the web, eg
> > https://lists.ibiblio.org/sympa/arc/cc-metadata/2003-June/000123.html
> >
> > In retrospect the conclusion to shove a simultaneously semi human
> > readable and semi machine parseable statement in the "TCOP" field was
> > dumb.  It isn't very readable, isn't exposed by programs if it were,
> > isn't translatable, and is hideous from the perspective of machine
> > parsing.
> >
> > We're going to release recommendations for embedding similar web-backed
> > notices in several other file formats over the next year, so now may be
> > a good time to correct the original mistake, create a new recommendation
> > for MP3/ID3, and replicate that recommendation elsewhere.  (There isn't
> > that much properly marked content out there using the existing
> > recommendation, and only a few programs that look for compliant embedded
> > metadata, all of which I suspect would be glad to comply with a saner
> > standard.)
> >
> > The new recommendation would probably be to use two fields specifically
> > intended to contain URLs and only URLs.  For ID3v2, those might be
> >
> > WCOP (pointing to a license URL)
> >   Definition: http://www.id3.org/id3v2.3.0.html#WCOP
> >   Example value: http://creativecommons.org/licenses/by/2.0/
> >
> > WOAF (pointing to a web page describing a file, potentially including
> > license information/metadata)
> >   Definition: http://www.id3.org/id3v2.3.0.html#WOAF
> >   Example value: http://example.com/a_song_sung_by_me.html
> >
> 
> I'd say go with WCOP.  This way a publisher has the option of having a
> different link for WOAF.
>
> Where will the verification url go?

Both would be used, most importantly WOAF.

The current format says

blah blah {license-url} verify at {metadata-url}

license-url would move to WCOP
metadata-url would move to WOAF

> > Note that these map to current use of licenses and metadata on web pages
> > -- the license notice points to a CC license URL, and describes the
> > current page (the current page is its own "official page").
> >
> > Comments?  Suggestions for implementation in other formats?  I'm
> > particularly interested in EXIF, MP4/QT and OGG at this point.
>  
> Ogg has a LICENSE field which they say can be used for (among other
> things) a URL pointing to the license.  See
> http://www.xiph.org/vorbis/doc/v-comment.html
> 
> MP4 has a Copyright Atom.  See pages 36 - 37 of
> http://mediaxw.sourceforge.net/files/doc/MPEG%204%20System.pdf
> It's exact format is not specified in that document.  I wonder how, if
> at all, any MP4 files are using that atom.

Embedded metadata is generally un- or ill-used.  I've had a hard time
finding any QT/MP4 file using @cpy or cprt.

I've spoken briefly with the folks behind http://www.mp4ra.org/ and
that's one reason for this rethink.  I detect a strong preference for
defining new url-only fields rather than a special format for data in
the copyright atom.

> It might be difficult to persuade every file format owner to add a tag
> that is specifically for a license (and/or verification) url.  The
> nice thing about the semi-readable/parseable license statement is that
> we can use any field that relates to copyright or licenses.

That's true, but there's always the sort of resistance above (see also
dc:rights usage in another context) as well as general resistance to
parsing URLs out of text (then think of i18n).

> Furthermore, I don't think the current license statement is so hideous
> for a machine to parse.  Only the content after the words "verify at"
> is constrained - at least that's my reading of
> http://creativecommons.org/technology/mp3 and
> http://creativecommons.org/technology/ogg.

I agree it isn't hard, but it looks really hideous to some engineers.

> What can be hideous though, is if some programs are becoming dependent
> on what may be becoming a de-facto format:  <year> <copyright holder>.
> Licensed to the public under <licenseurl> verify at <verification url>
> 
> A more specific specification as to what a "CC-compliant"
> publisher/reader should or should not depend on may help here.  (a la
> RFC-style)

I agree and intend to produce that, but I don't think it is going to be
in the form of a more rigorously specified English sentence with URLs
included.

-- 
  Mike Linksvayer
  http://creativecommons.org/about/people#21