On 8/17/07, Brianna Laugher <brianna.laugher(a)gmail.com> wrote:
While I look at all these random blogs, I notice the
proliferation of
Flickr plugins...part of Flickr's success, I feel certain, is due to
their API which allows anyone to easily "plug" Flickr into another
application - a blog, a website, facebook, etc. And in multiple ways:
by license, by keyword, by author(or, close enough: uploader). They
also have that
Commons could do this, but first we need to standardise. Anyone who
actually has tried to write a tool to pick up this stuff will know it
is hit and miss.
Well, there is one catch prior to that: IIRC, Flickr plugins
transclude the image from the flickr servers. Would we want this for
commons - using our bandwidth to display images on blog pages? (I'm
not saying yes or no here, just asking the question)
first, the easy one: licenses. There is a painful
problem at the
moment that we have no way of knowing which templates are license
templates and which ones are not. New ones are created all the time
and old ones may be converted to deletion templates. (ook.)
Since I have written my share of tools dealing with licenses, here's
what I recommend: Don't go for templates, but for categories. See
http://commons.wikimedia.org/wiki/MediaWiki:GalleryDetails.js
for a brief list of bood/bad categories that, in practice, cover most
images quite well (note that these are /beginnings/ of category names,
so "CC-" fits any category starting with "CC-").
so, my proposal.
1. ask for new License: namespace to be installed at Commons.
2. move all license templates into the License: namespace.
3. separate any template which conflates license and source, e.g.
"PD-NASA", "GFDL-GeoDB" (or whatever). Anything which is in the
public
domain, regardless of how it got there, should have {{License:Public
domain}}. Indicating source by text + template is fine.
Now I am not sure if there is actually a good reason we have license
categories. Is it safe to assume that no one ever searches via
license? If so, is there any extra functionality we gain from having
the category?
If not, we can quit using categories as well as templates to indicate
licenses. If it is useful, we should change all license categories to
be prefixed with License:. So instead of [[Category:GFDL]] we would
have [[category:License:GFDL]].
Well, few people will search starting at [[Category:GFDL]]. However,
if the problem is to display the license of a certain image, it is
very useful. It would be easier to prefix all the license categories,
but only marginally so. For a complete list of all license categories,
get the subcategories of [[Category:Copyright statuses]] (of of a few
of these). This could be done centrally (toolserver) once a day.
So, the second problem, keywords. Let's reduce
this to an easier
(although less complete :)) problem: categories. Being able to have
per-category feeds would be extremely cool. Imagine such a feed on QI
or FP. Totally awesome.
Just FYI: Ages ago, I added a Recent Changes filter for changes in a
category and its subcategories. It should still be in the code, but
(guess what) deactivated.
So in general we can assume that categories on a file
act as
describing keywords. There are two exceptions. One is license
categories (see above). The other is maintenance categories, such as
deletion, cleanup, user.
So I propose we rename all these kinds of categories, to
"Maintenance:X" or "Meta:X" for deletion and cleanup, and I guess
"User:X" for user.
I dunno. maybe these don't interfere too much. Sometimes they are
useful. This change is not as important as the license one.
In general, I think it is good for us to look at Flickr and say: how
do they facilitate sharing their content? how can we do that too?
Full agreement :-)
Magnus