[Clipart] Metadata Proposal (WAS) developing an xml schema standard for packaged multimedia

Mike Traum mtraum at yahoo.com
Tue Apr 5 18:15:39 PDT 2005


I guess this discussion has already been had:
http://www.openclipart.org/cgi-bin/wiki.pl?MetadataDiscussion

I took a look at the RDF/XML + Dublin Core + Creative Commons
Metadata proposed here (and that's being added to the svg's). There's
no category field. If that's just tossed in with the 'subject', then
it's not really a category, but a keyword. How is a parser to know
what the category is? It looks like these aren't even keywords
anyway, but actually used to generate a file path.

Also, the proposal says nothing about bitmaps. I like Nathan's idea
of distributing an rdf per file in the package (zip/tarball).

If a metadata is approved and set, and openclipart packages are
distributed using this metadata, I will commit to writing a
cross-platform media organizer that will allow client side searches,
etc.

mike

--- Mike Traum <mtraum at yahoo.com> wrote:

> I tend to agree with what you are saying regading the files not
> being
> in the xml itself.
> 
> But, a schema still needs to be created for the metadata. What
> group
> would be the best for approching this idea with? This goes beyond
> the
> scope of just clipart, although I think it does belong in the realm
> of freedesktop.org.
> 
> I would highly disagree with the idea of bundling thumbnails (or at
> least make it optional). I think that should be the job of
> applications. There are plenty of thumbnailer apps. Besides, you
> already get this for wmv, jpeg, etc with Windows Explorer and Gnome
> Nautilus (wmf with the right plugin).
> 
> mike
> 
> 
> --- Nathan Eady <eady at galion.lib.oh.us> wrote:
> 
> > Mike Traum wrote:
> > > I think an xml schema should be developed for a bundle of
> > multimedia
> > > files. There may be one already, but in my brief search I was
> not
> > > able to come up with anything.
> > 
> > Maybe I'm just old-fashioned, but I would think that an archive
> > format,
> > such as PKWare ZIP format, would make more sense than XML for a
> > bundle
> > of files.  Even OpenOffice, which uses XML extensively, uses ZIP
> > for
> > packaging up groups of related files together.  Seems to work
> very
> > well.  Java and Mozilla also use the ZIP format for similar
> > purposes
> > (jar and xpi, respectively).
> > 
> > > This would allow metadata such as keywords and categories to be
> > > distributed with multimedia, allowing easier use on the client
> > side.
> > 
> > Metadata, such as keywords, can be embedded into the files (if
> they
> > are in an XML-based format, such as SVG) using RDF.  For files
> that
> > are not in an XML-based format, such as WMF, we have for lack of
> > a better solution been placing foo.rdf right alongside of foo.wmf
> > or whatever.
> > 
> > > For example, you could then download a bunch of clipart from
> > > openclipart.org as an xml file. This xml file could then be
> used
> > in a
> > > multimedia organizer application which would give you the
> ability
> > to
> > > search keywords and see the categories.
> > 
> > The multimedia organizer application would need to have knowledge
> > of the format in question.  If we accept that limitation, though,
> > ZIP works just as well:
> > 
> > For example, you could then download a bunch of clipart from
> > openclipart.org as a zip file.  This zip file could then be used
> in
> > a
> > multimedia organizer application which would give you the ability
> > to
> > search keywords and see the categories.
> > 
> > I don't see how using XML for the container format adds anything.
> > 
> > > I realize that svg has the ability to have embedded metadata,
> but
> > > many other format's do not.
> > 
> > If you don't like placing the metadata alongside in an rdf file
> > within the package, another option would be to put the metadata
> in
> > a manifest file, which could be included in the package.  The
> file
> > format for the manifest file could be XML, but ZIP could still be
> > used for the container format.
> > 
> > There's a significant advantage to using ZIP for the container:
> > users who don't have the multimedia organizer application
> installed
> > (e.g., because they haven't bothered to install it, or because it
> > does not yet exist currently) can use standard tools (info-zip,
> > pkunzip, Nautilus, Winzip, recent versions of Windows Explorer,
> > or whatever) to get at the clipart.  With an XML-based container
> > format, that becomes impossible, and the archive is useless to
> > anyone who doesn't have the special application.
> > 
> > I would think we should use XML for the metadata, but use
> > ZIP or something like it for bundling up the files together.
> > 
> > It should also be noted that we really need to package up
> > thumbnails, in addition to text-like metadata such as author
> > and title and keywords, with each file.
> > _______________________________________________
> > clipart mailing list
> > clipart at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/clipart
> > 
> 
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Personals - Better first dates. More second dates. 
> http://personals.yahoo.com
> 
> _______________________________________________
> clipart mailing list
> clipart at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/clipart
> 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Personals - Better first dates. More second dates. 
http://personals.yahoo.com




More information about the clipart mailing list