Skip to Content.
Sympa Menu

cc-devel - Re: [cc-devel] CCTools Metadata and Liblicense

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: "Nathan R. Yergler" <nathan AT yergler.net>, Jason Kivlighn <jkivlighn AT gmail.com>
  • Cc: CC Developer Mailing List <cc-devel AT lists.ibiblio.org>
  • Subject: Re: [cc-devel] CCTools Metadata and Liblicense
  • Date: Tue, 17 Jul 2007 17:24:20 +0100

Awesome...all integration work sounds nice...ppl here at guadec keep saying
how cc comes up wrt to metadata as top hits in google...soooo...we are
leading and doing some things right... ;)

Jon


-----Original Message-----
From: Nathan R. Yergler <nathan AT yergler.net>
Sent: Tuesday, July 17, 2007 5:44 PM
To: Jason Kivlighn <jkivlighn AT gmail.com>
Cc: CC Developer Mailing List <cc-devel AT lists.ibiblio.org>
Subject: Re: [cc-devel] CCTools Metadata and Liblicense

Comments inline...

On 7/14/07, Jason Kivlighn <jkivlighn AT gmail.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://wiki.creativecommons.org/Liblicense
>
> _______________________________________________
> cc-devel mailing list
> cc-devel AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/cc-devel
>
_______________________________________________
cc-devel mailing list
cc-devel AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel





Archive powered by MHonArc 2.6.24.

Top of Page