[Clipart] metadata: aren't the keywords actually categories (and can keywords be added)?

[Andrew Archibald]

Mike Traum wrote:

> Anyway, when you describe the localized packages for end users, I
> assume you mean something similar to what is being done now, with
> clips extracted into a directory structure? If so, this is my concern
> about having an image with mutiple categories (which, many will
> surely have). Do you have multiple copies of the file in the tarball?
> Seems redundant. You could use symbolic links, but then you'd have to
> distrubute separate packages for different OS's (besides the fact
> that I doubt MS shortcuts play nice with other tools, for example
> image organizing applications such as ThumbsPlus). This is why I like
> the idea of one big xml, assumming there was a clip organizer
> application to go along with it.

One big XML is totally useless to applications that don't understand the 
format.  Currently, I can use OCAL images in the GIMP, Inkscape, Mozilla 
Composer, etc. etc.  Many of those can only handle bitmaps; that's fine, 
since the package contains bitmaps.

It's true that people who can run the specialized clipart-tool can extract 
files from the XML and save them to somewhere in their home directory, but 
this adds an extra step before using the image in each of those programs. 
And if you can't use the specialized clipart-tool... (for example, I don't 
have a Java VM on my machine).

If the problem is "what do you do with files in multiple categories", there 
are lots of solutions.  Hard links are great; symlinks are fine too.  If 
you use tar, whatever tool untars the files will presumably do a credible 
job of simulating them on machines that don't have them (probably make 
copies for hardlinks and shortcuts (?) for symlinks).  Extra copies are 
fine too, unless we get loads of files in too many categories.  You could 
even just fall back to putting the file in the "best" (or first) place that 
comes to mind.

> The whole reason I've been lurking here is because I'm interested in
> writing a os independent (java-based) GPL'd clip organizer similar to
> what MS has with their Office suite. Then, you can import these
> packages (as well as Microsoft's, and whoever else is dirtributing
> clip packages w/ metadata) and still have them searchable on the
> client side. You'd no longer need to distribute thumbnails, as the
> clip organizer would be able to do this as well. And, you'd be able
> to see the properties of the file (copyright, etc) from a decent
> interface. This effort shouldn't really be that hard, but I want to
> make sure that openclipart is moving towards a package structure that
> would be ameniable to such an effort. Otherwise, I'd only be allowing
> import of MS's files, which many users can't legally use (under their
> EULA).

Surely you can support any format we document, without much trouble?

Andrew