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

[Jon Phillips]

On Fri, 2005-04-15 at 17:47 -0400, Andrew Archibald wrote:
> 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.

I must heavily agree. I think the best (future) approach is normal svg
files in user-defined categories with an xml-based index of the package,
compressed in the format a user requests for packages. We need to get
with the times...

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

Yeah, that will just annoy users. What is great about the clipart is
that its usable and quickly available.

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

Yeah, we have discussed this much in the past. Please check out the wiki
and mailing list for past discussions on the subject. The file hierarchy
in the on-line and downloadable package is temporary. In the future, the
current hierarchy represents only one possible type of hierarchy that is
user-defined. To work in terms of strict hierarchy that we enforce on
users is really not very good. Think of it: Bob's Party Art package has
certain selections that bob has sought out. He could then download his
selections as a package, or even better leave online as a clipart list
(like music playlist) for others to browse, and that would change as new
images are added/changed to the repository. This is much better and more
dynamic.

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

I agree, but I see Mike's point about having a more standardized index
system that could be used to easily parse an Open Clip Art Library
package or folder with one of these xml files inside. My primary concern
is that we keep the format open, and keep the files available so that
people can navigate through and find what they are looking for.

Jon

-- 
Jon Phillips

USA PH 510.499.0894
jon at rejon.org
http://www.rejon.org

Inkscape (http://inkscape.org)
Open Clip Art Library (www.openclipart.org)
CVS Book (http://cvsbook.ucsd.edu)
Scale Journal (http://scale.ucsd.edu)