[Clipart] Comma-separated keywords in metadata

[Bryce Harrington]

On Fri, 9 Jul 2004, Jonadab the Unsightly One wrote:
> > 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?

In Inkscape we implemented a jar-based format for collections of svg
documents.  Inkview can open and view these types of files.  It uses
.jar or .sxw as the file extension name.  Someone had suggested .inkjar
but that got way too many rolled eyes.  ;-)

If you do adopt a new extension, I'd strongly recommend:
   * Register it and its mimetype with TPTB
   * Consider how to generalize the file structure for things beyond our
     own needs, such as presentations, frame-based animations, etc.
   * Discuss it on inkscape-devel, regarding adding support for it

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

       .artz
       .ocal

> >  * 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 ?

I'd suggest leaving it open ended if possible.  Who knows what people
will want to put in it in the long term.  txt files, css, ecma/js, etc.

> >  * 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?

Yes, sounds good.

> >  * 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?

Yes, and allow optionally LICENSE too, since that's common.

> >  * 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?

Yes, also optionally README.

> >  * 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'm not a big fan of those .xvpics subdirs that tend to show up
everywhere...  The other approach would be better.

Bryce