[Commons-l] Towards a Commons API

[Magnus Manske]

On 8/17/07, Brianna Laugher <brianna.laugher at 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