Talk:Page metadata

The first sentence below the Table of Contents made no sense

"For each type of meta information, a new DB table of cur and old is required. "

Oh. Now that I see it in typewriter font here in the talk page editor, I see I misread what I thought said "... our and old is required."

It is: "... cur(rent) and old is required." it makes perfect sense. Wb7 23:18, 1 April 2010 (UTC)

Support

We have something very similar on our roadmap as well, see bug 53508. The storage for this is being prototyped and discussed at User:GWicke/Notes/Storage. -- Gabriel Wicke (GWicke) (talk) 01:44, 12 October 2013 (UTC)

Some notes

• Interwiki links, most templates, and many "external links" are content, not metadata.
• IMHO Things like protection, construction, copyvio, etc... messages should be part of a series of extensions that display these notices (and do it in cleaner ways). Some of this data is already available to extensions (eg: the protection status). The method of declaring the rest is up for debate.
• I had an idea for category metadata (easily expanded to interlan interlanguage links not in Wikidata, editable description, etc...) which was well received when I posted it in either IRC or a bug report – can't remember which – but I never got to writing an RFC for:
  • UI editable category metadata should be stored using ContentHandler in a in a Content type's data separate from the wikitext, etc...
  • [[Category:...]] should continue existing for use by templates (though we may want to introduce a {{#setcategory:...|...}} which we would encourage templates to use).
  • The combined category data output by the Content type (wikitext categories + metadata categories) should include a bit of extra metdata on where each category was sourced from (or maybe simply an "editable" boolean).
  • We'll have an editinig UI and api for editing categories.
  • This editing UI will use that extra metadata to display all categories with non-editable ones greyed out to show the user what can and can't be modified through the UI.
  • Random thought I had now. We'll probably add a PHP interface for the Content type (or actually 2 of them; One for category fetching and the other for modification) for the get ("get category", "remove category", "add/set category") operations that the API would use on the Content instance to modify the data before storing. Then we can abstractly implement that on any Content type (we can even have things like JS/CSS/Lua with categories that don't need to written into the text). And use instanceof checks to see if a content type supports categorization and allows categories to be modified abstractly.

Daniel Friesen (Dantman) (talk) 07:18, 12 October 2013 (UTC)

Metadata searching

I'm considering MediaWiki for an internal company application. I'm playing around with Categories to tag pages and get to them, but one thing I'd really like is to be able to add metadata that I can search for and get a tabular result sortable by metadata. For example, imagine if the Wikipedia chemical element pages had metadata such as melting point and boiling point. I could then search for all articles with a melting point and boiling point and sort by boiling point. This would be similar to sorting items in a bug tracker by due date or by priority or by target release. Is there any facility like that in MediaWiki? BenFrantzDale (talk) 18:01, 13 May 2016 (UTC)

It looks like I want Extension:Semantic_MediaWiki. BenFrantzDale (talk) 18:23, 17 May 2016 (UTC)