[Clipart] Comma-separated keywords in metadata
Jonadab the Unsightly One
jonadab at bright.net
Tue Jun 29 21:18:55 PDT 2004
Bryce Harrington <bryce at bryceharrington.com> writes:
> Yes, agreed. And particularly something suitable for adding/editing
> keywords "as we go" because I figure initially we'll just set up
> some broad groups, like 'animals', 'people', 'signs', etc. and then
> as work collects folks can add narrower and more specific terms.
>> If there are 600+ images _with_ metadata, and _most_ people didn't
>> include it, wow, that's a lot of metadataless images sitting
>> around, with no author info!
> Fortunately we had several artists who were very good about
> submitting their work as a tarball with a README or other file with
> their license, title, and author info, so it was not hard to add the
> metadata. We still have a number of images without metadata, but
> unfortunately we also have no way of determining the author info.
> See the PASSFAIL report in the tarball for details.
I see. Hopefully having the upload script will help with this for
future SVG submissions, but should we have a separate upload script
(or generalize the existing one) for tarballs (and PNGs and other
formats?), that puts the metadata in $samefilename.RDF or something?
>> Should we be adding an optional author-email field to the upload
>> script? I was already thinking of having it at least provide a
>> link to a page that lists known/supported optional fields, or
>> something. As it stands, the user has to just _know_ what fields
>> they can add, which seems wrong. Maybe instead of the current
>> system for optional fields where the user specifies the name and
>> value for the field, there could be dropdown lists for the field
>> names, or something? (That would be easy to implement...)
> An email address or URL for the author would be really nice to have,
> because then we'd have a way to contact them in case there were
> questions. However I suspect that in many cases the author would
> not want their email address going out in the clipart "publically",
> lest it wind up on a web page somewhere and some spambot harvests
> it. So if you do add an email address field, also be sure to
> include a checkbox for them to specify whether or not the address
> should be included in the metadata or not (assuming there's another
> place to keep the address...)
We've been meaning to store some stuff in a database anyway. Didn't
someone say there's access to MySQL? One advantage of the db is it
would allow us to store things that are not supported directly by
SVG::Metadata. Another is that we could store potentially-sensitive
info that shouldn't go into the .SVG itself. Another is that we could
store metadata for non-XML submissions, such as tarballs.
[Jonadab heads off to read the POD for Class::DBI]
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/
More information about the clipart