On 8/17/07, Brianna Laugher brianna.laugher@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.
- ask for new License: namespace to be installed at Commons.
- move all license templates into the License: namespace.
- 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