[Clipart] Comma-separated keywords in metadata

[Jonadab the Unsightly One]

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
   included.
   
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.

-- 
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/