[Clipart] Comma-separated keywords in metadata
bryce at bryceharrington.com
Sun Jul 18 14:28:31 PDT 2004
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?
> And isn't a jar just a special kind of zip anyway? (I know sxw is.)
> > 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
> >> > * 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
> 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.
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?
More information about the clipart