On 01/22/2011 01:15 PM, Bryan Tong Minh wrote:
Handling metadata separately from wikitext provides
two main
advantages: it is much more user friendly, and it allows us to
properly validate and parse data.
This assumes wikitext is simply a formatting language, really its a data
storage, structure and presentation language. You can already see this
in place by the evolution of templates as both data and presentation
containers. It seems like a bad idea to move away from leveraging
flexible data properties used in presentation.
In commons for we have Template:Information that links out into numerous
data triples for assets presentation. ( ie Template:Artwork,
Template:Creator, Template:Book with sub data relationships like
Artwork.Location referencing the Institution template. If tied to SMW
backed you could say "give me artwork in room "Pavillion de Beauvais" at
the "louvre", that is missing a "created on" date.
We should focus on apis for template editing,
Extension:Page_Object_Model seemed like a step in the right direction
but not Something that let you edit structured data across nested
template objects and we could stack validation ontop of that would let
us leverage everything that has been done and keep things wide open for
what's done in the future.
Most importantly we need clean high level apis that we can build GUIs
on, so that the "flexibility" of the system does not hurt usability and
functionality.
Having a clear separate input text field "Author:
____" is much more
user friendly {{#fileauthor:}}, which is so to say, a type of obscure
MediaWiki jargon. I know that we could probably hide it behind a
template, but that is still not as friendly as a separate field. I
keep on hearing that especially for newbies, a big blob of wikitext is
plain scary. We regulars may be able to quickly parse the structure in
{{Information}}, but for newbies this is certainly not so clear.
We actually see that from the community there is a demand for
separating the meta data from the wikitext -- this is after all why
they implemented the uselang= hacked upload form with a separate text
box for every meta field.
I don't know... see all the templates mentioned above... To be sure, I
think we need better interfaces for interacting with templates.
Also, a separate field allows MediaWiki to understand
what a certain
input really means. {{#fileauthor:[[User:Bryan]]}} means nothing to
MediaWiki or re-users, but "Author: Bryan___ [checkbox] This is a
Commons username" can be parsed by MediaWiki to mean something. It
also allows us to mass change for example the author. If I want to
change my attribution from "Bryan" to "Bryan Tong Minh", I would
need
to edit the wikitext of every single upload, whereas in the new system
I go to Special:AuthorManager and change the attribution.
A semantic mediwiki like system retains this "meaning" for mediawiki to
interact with at any stage of data [re]presentation, and of course
supports flexible "meaning" types.
Similar to
categories, and all other"user edited" metadata.
Categories is a good
example of why metadata does not belong in the
wikitext. If you have ever tried renaming a category... you need to
edit every page in the category and rename it in the wikitext. Commons
is running multiple bots to handle category rename requests.
All these advantage outweigh the pain of migration (which could
presumably be handled by bots) in my opinion.
Unless your category was template driven, in which case you just update
the template ;) If your category was instead magically associated with
the page outside of template built wiki page text, how do you build
procedurally build data associations?
--michael