[Clipart] Comma-separated keywords in metadata
Jonadab the Unsightly One
jonadab at bright.net
Fri Jul 9 09:15:58 PDT 2004
"Jonadab the Unsightly One" <jonadab at bright.net> writes:
> Bryce Harrington <bryce at bryceharrington.com> writes:
>> Yes, that sounds like a very good approach. A nice option would be
>> if the user wishes to include the metadata in the tarball, that they
>> could name it some specific name and the upload script could check
>> for that file and, if there, pull it out and validate it as normal.
> I'm planning this. I'm thinking metadata.rdf for the magic filename
Done. Checked in. Should be live on the site. Feel free to test.
> Archive::Tar should make this quite feasible.
It even should handle gzipped tarballs transparently and
automatically, assuming I correctly installed IO::Zlib (which I'm not
certain about; I've never used CPAN as a non-root user before and had
a little trouble with ExtUtils::Install and ExtUtils::Command not
wanting to use directories I had permissions for; so the gzip
functionality should be tested).
> Also it may be possible to place metadata specified at upload time
> in such a magic file inside the tarball (along with any that is
> already there) so that both SVG and tarballs can have the metadata
This is done too, and the tarball is automatically gzipped for storage
(same caveat about IO::Zlib).
> I'm also thinking maybe of eventually adding a zip-based
> clipart-package format, analogous to OpenOffice's zip-based document
> formats, where we specify a certain arrangement to things inside the
Anyone else have thoughts on this, or should I just Make Something Up?
> Here's what I'm currently thinking:
> * Use an extension other than .zip, preferably one that hasn't been
> used for any other very major thing before.
.oco Stands for OpenClipart.Org
.ocozip perhaps? Or should we stick to three letters?
.sxa (The a stands for "Art"; c is taken for Calc.)
.zca Zipped Clip Art
I assume .clp and things like that have been used in the past by
various software for various uses and should be avoided to save
> * Require that the entire contents of the archive be inside a
> single folder with a certain name ("clipart" seems obvious)
> so that it will unzip into a single directory.
> * Allow optional heirarchical directory structure for categories
> within the main directory, but also allow any or all of the files
> to be loose in the main directory.
> * Specify what image formats can be in the package.
.svg of course
Others? .gif and .jpg ? .tiff ?
> * Require all image files to either have embedded metadata or
> be accompanied by a samename.rdf metadata file.
Or should it be permissible to have the directory-wide
metadata cover all of them, with the understanding that when
any images have their own metadata, that overrides the
general directory-wide metadata?
> * Allow each directory (including the main one) to have a magic-name
> metadata file (maybe metadata.rdf) that applies to all of the
> images in that directory and downward, unless it is contradicted by
> metadata specified at a lower level (e.g. for a subdirectory or for
> a specific image).
> * Probably wouldn't hurt to specify a LICENSE file.
> * Probably wouldn't hurt to specify an optional README file which can
> contain whatever information the author wants to include, with the
> understanding that downstream distributors and users are not
> required to keep it if they remove the images from the archive.
> * Probably should specify how thumbnails should (optionally) be
I'm thinking the thumbnail for foo.svg should be
foo-svg-thumb.png (so then you could have foo-png-thumb.png if
you have a foo.png).
Or should we do an .xvpics subdirectory a la Gimp, so that the
thumnail of foo.svg would be .xvpics/foo.svg even though it's not
an SVG? Does anyone here know what format Gimp's thumnails are
in and how hard that is to work with?
I personally would lean toward the simpler foo-ext-thumb.png
convention, but I can see the argument for going the other way.
> We could borrow an extant spec for this, if there is one,
Anyone know of one?
> or we could just create one.
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/
More information about the clipart