[Clipart] Comma-separated keywords in metadata
Jonadab the Unsightly One
jonadab at bright.net
Fri Jul 2 05:01:48 PDT 2004
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,
unless someone can think of a reason why it should be something else.
Archive::Tar should make this quite feasible. 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 embedded. PNG and other formats
would still have it separate.
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
ZIP. 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.
* 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.
* Require all image files to either have embedded metadata or
be accompanied by a samename.rdf metadata file.
* 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
We could borrow an extant spec for this, if there is one, or we could
just create one.
We probably would not get any submissions in such a format initially,
but if we distribute the clipart in a standardized format like that,
it might become a de facto standard, which could be a useful thing.
> Yes, I did mention that we can get access to MySQL. I've been
> thinking about this since then, though. There is definitely an
> advantage to using files as the primary data storage mechanism, and
> I'd like to do that as the base. This way, I can rsync off all the
> files from our server and process them locally using basic
> file-oriented tools.
Okay. I'll hold off on the database stuff for the moment then. I do
think we'll eventually want to store certain things there that we
won't want stored in the images, e.g. user login and contact info.
But that can wait; first I think we should work on getting tools in
place to allow people to easily help categorize the images.
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/
More information about the clipart