Talk:Field-value pairs
The big disadvantage is that it prevents having articles with the equal sign ("=") in the name.
- I tried a simple experiment: I went to edit the section containing this example and removed the initial space from the line containing the example. When I hit the "Preview" button, I did not get a link until I removed the equal sign from the putative link and replaced it with a space (i.e. "name=value" to "name value"). It would appear that you can't create an article with a space in it by this method; I would doubt it to be possible given the use of the eqaul sign in URL syntax anyway. HTH HAND. Phil 15:00, 11 Dec 2003 (UTC)
I like this idea. It takes care of the subpage problem quite nicely, or at least it could be implemented to. Subpage hierarchies are linear by nature, whereas a feaure like this, implemented to the nth degree, provides a basis for hyper-hierarchy, wherein an article may be, among other things, 'contained' or 'listed' under two or more articles. Hey, check it out: I used 'whereas' and 'wherein' in the same sentence. Dude. What was I saying? Oh, right. I also think there may be a better interface than in-line tags. Not that I can think of one. Not surprizingly, I really don't like the way interlanguage links are made. It's convenient, and I respect it for that, but something about it feels inappropriate, for lack of a better word. The interface fails to reflect the implementation. That's where I see this idea failing. Unless, of course, the placement of some tags could have meaning, such as tagging paragraphs or sections, or defining named anchors (eek, but someone had to say it). Then the interface would be necessary, and make sense. Unlike me. --Spikey 22:27, 17 Dec 2003 (UTC)
I took out the field_status column from the database definition. Here's another algorithm for doing a background-bot implementation:
- Bot looks for pages with type=category (this is a single quick DB query, by the way)
- For each one, it checks to see if the category page exists and is newer than all articles that have it as their category.
- If not, it renders and stores the page.
- It also stores another field in the fields db: article_count. That's the number of articles that refer to the page.
The count is necessary because if an article is deleted, the category page should be updated -- even though it's still newer than any articles that refer to it.
I didn't like the field_status bit, because it's very category-specific. This isn't just about categories. --Evan 23:51, 17 Dec 2003 (UTC)
Having metadata markup in the article itself works okay right now, with just interlanguage links and (now) categories, but as more metadata is added it could get pretty hairy.
I think it'd be a good idea to split metadata into a separate namespace: each article could have a corresponding Meta:<title> page (or whatever—"Meta:" might get confused with the Meta-Wiki), much like how they're matched up with pages in the Talk: namespace. All metadata that isn't article contents would go in the meta-page, including stuff like inter-language links and categories. This could remove some clutter from the articles' editboxes that could potentially confuse or scare off new contributors, and would also settle the matter of whether interlanguage and category markup should go at the top or bottom for good.
The disadvantage is that you couldn't add some content and, say, a category in a single edit. You'd have to perform two edits: one of the article, and one of the meta-page. - Gwalla 21:18, 31 May 2004 (UTC)
I don't know whether this is in active development or not, but interested parties should read en:OWL to see how the W3C plans to mark up the semantic web. IMHO it would be a good idea to avoid reinventing the wheel here. See also my contributions to en:Wikipedia_talk:Categorization. -- Avaragado 09:47, Jul 1, 2004 (UTC)
Fixed Fields
editI am interested to know if I can source the Page Title (for example) and incorporate it into each wiki page. Can I do something like {{{Page_Name}}} and have it return the page name of the existing page? I would like to use this to link to a page on another wiki with the same name. i.e. [[remote_wiki:{{{Page_Name}}}]] - Scott Spence, 16 November 2005
populating infobox-like templates?
editApologies if I missed it, but it seems to me one of the big things you'd like to be able to do with this metadata is to have it displayed in a consistent way, based on some per-thing template. That is, where today we have infobox templates like
{{Infobox City|area = 1,214.9
|population_total = 3,845,541
|latlong = 34 03 07 N 118 14 34 W
...
}}
with good support for field-value pairs this would instead be
area=1,214.9
population_total=3,845,541
latlong=34 03 07 N 118 14 34 W
{{Infobox City}}
(where I postulate the obvious sort of necessary mechanism which would let the template access the field values in the invoking page).
Even better (though this may seem a little extreme or far-fetched) would be to have the template automatically selected. That is, on a page containing
type=City
and if there weren't an explicit invocation, there could be an implicit invocation of the template, in some default location on the page, and driven by a per-project mapping from type values to infobox template names.
(Yes, I know, there would be lots of other details to work out, and the hierarchy/namespace/categorization of these hypothetical "type" values would end up being deeply, endlessly intricate, but you get the idea!)