Bug 4065 - License is not always public domain in clip art browser
Summary: License is not always public domain in clip art browser
Alias: None
Product: openclipart.org
Classification: Unclassified
Component: website (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: default user for a product
QA Contact:
URL: http://openclipart.org/cgi-bin/naviga...
Depends on:
Reported: 2005-08-13 09:06 UTC by Jon Phillips
Modified: 2007-02-06 18:16 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Jon Phillips 2005-08-13 09:06:39 UTC
In working to get our site plugged via creativecommons.org, the devs. there
found a bug with how we are displaying licenses on this page as an example:
Notice, shouldn't all licenses be public domain. Ideally, this field could be
removed with something at the top that says all images are public domain. We are
only allowing public domain imagery so there is no need to state this each time
which suggests that we allow other declarations.
Comment 1 Jonadab the Unsightly One 2005-08-14 04:53:50 UTC
I've started looking at this, taking as an example the first image shown on that
page, namely, az-lizard_benji_park_01.svg.  It contains, within the cc:Work
element, the following license element:
     <cc:license rdf:resource="http://web.resource.org/cc/PublicDomain"/>
Additionally, the corresponding .txt file, which can be seen here:
Reads as follows:
Title:    AZ-lizard
Author:   Benji Park
License:  Public Domain
Keywords: lizard
So there are two issues with the way the navigate/browse script displays the
metadata:  First, it never reads past the first line of any given metadatum,
which I have known for a while, and second, apparently sometimes it does not
read things correctly at all.

I am tempted, rather than debug the way it reads the .txt files, to instead work
on getting it to read an index instead, since that should reduce the amount of
disk I/O consumed, at least somewhat, at least in theory, because it would be
reading one file insead of many.  (Eventually we want it to read from the DMS,
but reading from an index would be a stand-in measure meanwhile.)  Reducing the
disk I/O load we're putting on the server would be a Good Thing.

One problem is that the master index in the root directory is fairly large
(almost 4MB as of 0.17), so we might be trading disk I/O problems for memory
consumption issues.  Perhaps each directory should contain a metadata.txt
listing the metadata just from the files in that directory?  Thoughts?
Comment 2 Jon Phillips 2007-02-05 15:49:07 UTC
We are using a different system now, and the pd is definitely displayed now. We are nuking the old navigator, so it is an issue of time now.

bug/show.html.tmpl processed on Feb 27, 2017 at 06:48:46.
(provided by the Example extension).