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
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
