CCTools Metadata and Liblicense

I'm looking through Subversion for modules relating to
metadata and came
across these three: xmp, cctagutils, and cli_tools.  These
all appear to
do some subset of what the embedding/extracting aspect of
liblicense[1]
does, so I want to pose the question:  Can we work towards
removing them
in favor of liblicense?

 * xmp - An embedding GUI frontend for liblicense could
replace
pdf_license_manager
             PHP bindings for liblicense could replace
jpeg-php,
although we'd have to figure out handling of arbitrary
metadata in
liblicense.
 * cctagutils - Liblicense can embed licenses in all formats
supported
by cctagutils.  The liblicense python bindings make it an
easy
replacement for cctagutils.  Liblicense doesn't do other
metadata that
cctagutils handles, but it already links against the
libraries that
would easily allow this.
 * cli_tools - 1) I couldn't get it to run (name
'validateOptions' is
not defined) and 2) from the README, it looks like it
extracts/embeds
licenses from MP3's.  That's exactly what liblicense can do,
except in
it's in python.  Again, the liblicense python bindings cover
that.

On a larger scale, consolidating metadata handling could
really help
towards clear metadata standards and easy metadata embedding
relating to
licenses.  During my research for a Google SoC project, I
came across
several CC/non-CC applications/libraries dealing with
metadata and
frankly didn't know what to make of them.  I wondered if
what I was
looking at was obsolete or an out-dated way of handling
metadata.  The
tools' methods of handling metadata I found and what I found
on the Wiki
contradicted one-another.  Several tools worked at one
point, and looks
like they have since become neglected and broken.

I think that consolidating license embedding and extracting
into
liblicense can help towards a definitive metadata standard
for
licenses.  CC could point to liblicense and say: "This
is how licenses
should be embedded in format X".  Already, Liblicense
reads and writes
licenses to avi, mov, jpeg, png, tiff, wav, vorbis, mp3,
flac, musepack,
svg, pdf, and smil.

Liblicense is portable.  It will (eventually) work on all
OS'es; the
libraries required for embedding/extracting licenses are
all
platform-independent.  And it's in C so bindings, IMHO, are
trivial to
write. (I hear we've just picked up Ruby bindings)

Liblicense doesn't yet do everything it needs to for my
proposal, but
I've got (at least) the rest of the summer to work on it. 
Let me know
what needs to be done, and I can get on it.  And if anyone
else would
like to jump in, liblicense is in an early state, making it
a great time
to step up and get involved.

Cheers,
Jason

[1] http://wik
i.creativecommons.org/Liblicense

_______________________________________________
cc-devel mailing list
cc-devellists.ibiblio.org
ht
tp://lists.ibiblio.org/mailman/listinfo/cc-devel

Comments inline...

On 7/14/07, Jason Kivlighn <jkivlighngmail.com> wrote:
> I'm looking through Subversion for modules relating to
metadata and came
> across these three: xmp, cctagutils, and cli_tools. 
These all appear to
> do some subset of what the embedding/extracting aspect
of liblicense[1]
> does, so I want to pose the question:  Can we work
towards removing them
> in favor of liblicense?
>
>  * xmp - An embedding GUI frontend for liblicense could
replace
> pdf_license_manager
>              PHP bindings for liblicense could replace
jpeg-php,
> although we'd have to figure out handling of arbitrary
metadata in
> liblicense.

Sounds like we need PHP bindings, and then we can think
about it.  I
haven't looked  pdf_license_manager in a while, so I
can't comment on
it directly.  The arbitrary metadata handling will be needed
in
general if we want to replace cctagutils, etc (since they
handle
things like title, author, etc).

>  * cctagutils - Liblicense can embed licenses in all
formats supported
> by cctagutils.  The liblicense python bindings make it
an easy
> replacement for cctagutils.  Liblicense doesn't do
other metadata that
> cctagutils handles, but it already links against the
libraries that
> would easily allow this.

This would be great -- we need the following:

* Windows/Mac OS/Linux builds all working.  IIRC there may
be a
wrinkle or two with needing Visual Studio for Windows, but
we can
cross that bridge when we come to it.
* Handling for arbitrary metadata, as mentioned above.

>  * cli_tools - 1) I couldn't get it to run (name
'validateOptions' is
> not defined) and 2) from the README, it looks like it
extracts/embeds
> licenses from MP3's.  That's exactly what liblicense
can do, except in
> it's in python.  Again, the liblicense python bindings
cover that.
>

Agreed; see above.

> On a larger scale, consolidating metadata handling
could really help
> towards clear metadata standards and easy metadata
embedding relating to
> licenses.  During my research for a Google SoC project,
I came across
> several CC/non-CC applications/libraries dealing with
metadata and
> frankly didn't know what to make of them.  I wondered
if what I was
> looking at was obsolete or an out-dated way of handling
metadata.  The
> tools' methods of handling metadata I found and what I
found on the Wiki
> contradicted one-another.  Several tools worked at one
point, and looks
> like they have since become neglected and broken.

I don't see us making ccLookup/ccPublisher (which both use
cctagutils)
revisions a priority in the near future, but having the
ability to
consolidate those libraries would be a definite benefit.

NRY


>
> I think that consolidating license embedding and
extracting into
> liblicense can help towards a definitive metadata
standard for
> licenses.  CC could point to liblicense and say:
"This is how licenses
> should be embedded in format X".  Already,
Liblicense reads and writes
> licenses to avi, mov, jpeg, png, tiff, wav, vorbis,
mp3, flac, musepack,
> svg, pdf, and smil.
>
> Liblicense is portable.  It will (eventually) work on
all OS'es; the
> libraries required for embedding/extracting licenses
are all
> platform-independent.  And it's in C so bindings, IMHO,
are trivial to
> write. (I hear we've just picked up Ruby bindings)
>
> Liblicense doesn't yet do everything it needs to for my
proposal, but
> I've got (at least) the rest of the summer to work on
it.  Let me know
> what needs to be done, and I can get on it.  And if
anyone else would
> like to jump in, liblicense is in an early state,
making it a great time
> to step up and get involved.
>
> Cheers,
> Jason
>
> [1] http://wik
i.creativecommons.org/Liblicense
>
> _______________________________________________
> cc-devel mailing list
> cc-devellists.ibiblio.org
> ht
tp://lists.ibiblio.org/mailman/listinfo/cc-devel
>
_______________________________________________
cc-devel mailing list
cc-devellists.ibiblio.org
ht
tp://lists.ibiblio.org/mailman/listinfo/cc-devel