[Clipart] Comma-separated keywords in metadata

[Bryce Harrington]

On Mon, 12 Jul 2004, Jonadab the Unsightly One wrote:
> We'll need to make some adjustments to compensate for the fact that
> this specification is clearly intended only to deal with files stored
> on a desktop user's hard drive; we need to deal with files in a
> package or archive.  This means a couple of things...
> 
> 1.  The spec specifies thumbnails should be stored in a .thumbnails
>     directory inside the user's home directory
>     
> 2.  Wherever the spec talks about a file's location, it speaks of an
>     absolute uri (e.g., file:///home/foo/file), which will obviously
>     not do for files that are stored in a package that's being
>     transferred over the internet.
>
>     we'll have something more like
>     ocopackage://clipart/foo.svg or somesuch along those lines as the
>     file's canonical location.  
> 
> If all that sounds too complex, we could make up our own scheme for
> where to store the thumbnail within the package.  As long as it's a
> 128x128 PNG image, tools aware of our package structure should still
> have an easy time unpacking these thumbnails and storing them where
> the thumbnail spec says they should go.
> 
> Which way should we go?  Is it more useful to make some modifications
> to this thumbnail-storage spec and attempt to use it, or should we
> just make our own spec for thumbnails within clipart packages?

Hmm...  

I would favor placing the thumbnail next to the file it is a thumbnail
of.  Yes, this may make the package a little cluttery, but the benefit
is that whatever directory hierarchy that is imposed is only represented
once.  This is handy in that if the user wished to prune out some of the
dirs by hand, to eliminate stuff they are disinterested in, it would
work very intuitively.  Also, since we anticipate the user browsing the
structure with a tool rather than manually, the clutter of having the
thumbnails present shouldn't be too bad.

Bryce