[Clipart] Comma-separated keywords in metadata

[Jonadab the Unsightly One]

"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
> embedded.  

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

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
     confusion.
     
>  * 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
     .png obviously
     
     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.
   
     /clipart/LICENSE.txt perhaps?
   
>  * 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.
     
     /clipart/README.txt maybe?
     
>  * Probably should specify how thumbnails should (optionally) be
>    included.

     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.

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