[Clipart] Comma-separated keywords in metadata

[Jonadab the Unsightly One]

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.

I concur.

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

-- 
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/