Bryan Tong Minh wrote:
This issue has come up multiple times, but without
much result. What
specific features does Commons need to have? A list of this might be
interesting, because their are very likely users who are willing to
implement those kind of things, either as an extension, javascript hack or
external service.
Just thinking out loud here, none of this is feasible at this point ;-)
The concept of "articles" is, of course, entirely appropriate on Wikipedia:
there is one giant <textarea> into which all of the article's content goes.
Image pages (or, generically, "media" pages) on Commons, however, also
consist of one giant <textarea>, yet the data they hold can be divided into
a small number of discrete categories, which include:
- the title of the work (in a variety of different languages)
- the creator of the work
- the identity of the copyright holder of the work
- the date, time, and location of the creation of the work
- other media-specific metadata. For images, this is the exposure
information; for sound, this is information about the recording setup.
- the license under which the work is released
- information about post-processing (e.g. Photoshop, Audacity)
- categories to which the work belongs (i.e. [[Category:...]])
- Commons maintenance tags (e.g. {{SupersededSVG}}, deletion templates,
disputes of any kind)
With this in mind, then, it seems to me that it would make a lot of sense
for Commons media pages to consist of these fields, instead of one giant box
with all of this information. Speaking from a semi-OCD standpoint ;-), the
actual wikitexts of Commons pages are all over the place as far as form.
Whereas Wikipedia has a well-developed Manual of Style that dictates how
articles should be structured, Commons pages can contain a hodge-podge of
{{Information|...}}, redundant headings, categories, and the like.
I suppose my proposal—though as I said, this is really just brainstorming—is
to replace the giant <textarea> with some semblance of structured data
entry. I'll admit, I'm not particularly enamored with the idea of a
thousand input fields on each page, but compelling users to put the license
information in *this* box, and the author in *that* box, and the categories
*over there* is the only surefire way to standardize the look of media pages
on Commons. (A significant bonus here is that having the data structured
makes it infinitely easier to search—such structure could put the Commons
with the likes of Flickr as far as the Semantic Web goes.) As many people
have noted on this thread and elsewhere, MediaWiki is primarily an
encyclopedia engine, and needs significant changes to be really useful for
media.
As long as I'm dreaming out loud... a couple of years back there was a poll
to determine whether images should be added to articles, categories, or
both. I don't remember exactly, but I think the outcome was that we would
use a combination of articles and categories for the time being, but that
new software should be written to enable a "hybrid" approach. Well...
we're
still waiting :-) Don't get me wrong, I recognize that most (all?) of the
MediaWiki programmers are just hacking in their spare time, and aren't being
paid, but Commons really needs such a system put in place.
Personally, I think that articles should not be used for this purpose at
all, due to the fact that two pages (the image and the article) need to be
changed to add an image, whereas adding [[Category:Foobar]] will
automatically place an image in a category. OTOH, articles allow images to
be sorted into subcategories that would be too pedantic for the normal
category system (for example, "Foo at night", "Foo in the winter").
Anyway, my point here is that we need a better way to sort and categorize
media. The mythical "hybrid" system would dynamically add images to
categories, and still support implicit subcategories like "Foo at night".
(BTW, I have no idea how the specifics of such a system would work :-P)
Wow, that was a long post. I hope someone thinks at least some of this is a
good idea for Commons, and maybe then we can start to look for a way to
implement these changes.
Cheers,
--
Benjamin D. Esham
bdesham(a)gmail.com | AIM: bdesham128 | Jabber: same as e-mail
...and that's why I'm not wearing any pants.
