[Clipart] uploading a file

[Jonadab the Unsightly One]

"Stephen Silver" <ocalocal at btinternet.com> writes:

> I uploaded a file to the Open Clip Art Library today for the first 
> time.  While I still remember them, I list here the problems that I
> encountered, in the hope that at least some of these things may be
> improved.
>
> (1)
> I tried to upload the file using the box on the OCAL front page.
> It complained about problems with the submission:
>  
>  * You did not specify the filetype.
>
> But the upload box on the main page does not have any option to
> specify this, and it was obvious from the .svg file extension
> anyway.

Guessing the filetype is something I was working on in a newer version
of the upload script, but I have to iron out some performance problems
with that before it will be ready to replace the current one.  (I have
a pretty good idea what I have to do; I just have to do it.)  So, for
now, the filetype still has to be specified.

As far as the upload box on the main page not having any way to
specify that, it used to, but that got lost in the site redesign.  The
upload form that you get if you click the "Submit Clip Art" link in
the sidebar is more complete.  (You don't need to fill out anything
that is already specified in the metadata.)

>  * The author field is not filled out.
>
> But this was specified in the RDF.

The embedded RDF cannot be read until the filetype is determined.
(Some supported filetypes do not embed RDF, and the ones that do don't
all embed it in the same way.)  If you specify the filetype, the RDF
should be read then, and these other errors should vanish.

Once again, guessing the filetype if possible *is* on the TODO list;
it just isn't done yet.

> (2) The upload page has a checkbox where one can assert that the "is
> not legally encumbered by trademarks or reserved rights".  I don't
> see how can anyone make such an assertion without doing a worldwide
> trademark search (and probably not even then).  Surely it should be
> qualified by "to the best of my knowledge" or something similar.

What does everyone else think about this?

> (3) I had given the file a name beginning with "sas-" in order to
> reduce the likelihood of a future collision with the name of some
> other file.  But the upload script renamed it (without warning) to
> two_red_dice_01.svg.

The upload script on the server does not know what the filename was on
your computer; it creates a new filename based on the title.  I could
fix this by replacing CGI::Lite with a handrolled form-parsing
routine, which I have thought about doing anyway, due to a bug we have
been experiencing wherein some files get corrupted in the upload
process.

The filename might still have to be altered for uniqueness in some
cases, though.

> (4)
> The upload script made some strange changes to the metadata in
> the SVG file.
>
> It changed 
>
>   <Agent rdf:about="">
>     <dc:title>Open Clip Art Library</dc:title>
>
> to
>
>   <Agent rdf:about="http://www.openclipart.org">
>     <dc:title>HASH(0x89d7d10)</dc:title>

This is something I definitely need to look into.  We've been seeing
similar things like this happen in various places, from time to time.

> It also stripped the date from the file, changing
>
>   <dc:date>2004-11-11</dc:date>
>
> to
>
>   <dc:date></dc:date>
>
> This may be related to the fact that most of the SVG files
> on OCAL have a dc:date element containing things such as "42"
> or "57", which do not appear to be dates at all.

I'm not sure what SVG::Metadata currently supports in the way of
dates.  I'd have to investigate that.

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