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