[Clipart] Comma-separated keywords in metadata

[Bryce Harrington]

On Sun, 18 Jul 2004, Jonadab the Unsightly One wrote:
> Bryce Harrington <bryce at bryceharrington.com> writes:
> 
> > 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.  ;-)
> 
> Is this format suitable for our purposes?  Could we just re-use it?

Yes.
 
> And isn't a jar just a special kind of zip anyway?  (I know sxw is.)

Yuppers, exactly.

> > If you do adopt a new extension, I'd strongly recommend:
> >    * Register it and its mimetype with TPTB
> 
> I hadn't thought about content-type.  Should we just use the same
> content-type as for ordinary .zip files, or should we use one
> specifically for clipart packages?  Maybe Archive/X-Clipart ?

Yeah, if it's a new file extension type, then I'd recommend also doing a
mimetype for it.  If it's just going to be .zip, then use the zip
mimetype. 

> >> >  * 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
> 
> The more I think about it, the more I'm not crazy about extensions
> longer than three letters.

Yeah I think you're right.

> Now that you mention generalizing for more things than just visual
> art, I'm thinking maybe the extension should be rethought in light of
> the possibility that the same package format could be used for
> collections of sound clips or whatnot.  That's still reusable art, in
> some sense, but not quite the same.  I'll think about this some more.
> 
> Now that I've thought about it further, I'm thinking we require the
> licensing to be covered in the metadata.  Do we want to require that
> in the package format spec itself, or just for OCAL contributions?

Hmm...  I would be tempted to be a little aggressive here and have it
required in the package format spec.  That way it eliminates the
question.  

> No, it absolutely should have the .txt extension if it's plain text.
> Otherwise it's a royal pain in the neck to open on some platforms.  If
> we were developing something only intended to work on POSIX systems,
> that might be different, but we're not[1].

Alright, fair enough.  It certainly doesn't hurt to have it, and you're
right that it can be a pain on Windows without it.

> > I'm not a big fan of those .xvpics subdirs that tend to show up
> > everywhere...  The other approach would be better.
> 
> The thumbnails spec says one .thumbnails directory in one place.
> We'll have to adapt it to use a directory inside the package, though.

Can you compose an email to the author of the spec summarizing our
issue?  Perhaps we can get a generalization into the spec that'll work
for our purposes?

Bryce