![[Home]](/static/logo.png){kind=logo}
Metadata support in wiki may facilitate advanced features like facet browsing, topic grouping, better categorizations, etc.
To put it simply, metadata is stuff about data. PageMetaData is information that describes the page.
Most pages may benefit from having additional information associated to them, even though this information is (most often) invisible when the page is viewed. This data describes the page or classifies it, eventually groups it together with other pages (on the same subject). One must negotiate on a few common meta data names (fields), but can always invent and introduce new ones, where appropriate. The goal is to have a selection of useful field names and associatable values for each.
A sample chunk of meta data for a page could be:
Most Wikis already have a small amount of meta data associated to each page, by means of required database notes. The author, lastmodified and created times are stored in Wiki databases as is the page history (see BundledPages). But unlike that basic meta data (which exists for every page), meta data is an addition, can be absent, but is not limited to a few hardcoded fields.
This may optionally correspond to the <META> tag in HTML, which provides additional page descriptions for search engines. A Wiki could use this semantic data to present page lists based on other page classifications than only the basic categories nowadays used. For example a user could search for pages of the type ‘documentation’ from the author ‘admin’ containing one or more keywords.
There are already multiple simple implementations, like the CategoryCategory thing or BuiltinCategories. But unlike that, real meta data can negotiate much broader (without difficult SubCategoryConstructs). SnipSnap has a sophisticated Label feature, though page labels are assigned outside of the page’s body text, rather than being a markup extension.
It’s common to connect PageMetaData with RdfForWiki, publishing page information with RdfForWiki.
DublinCoreForWiki is particularly common way of doing this.
Declarative, freeform attributes at the beginning of every wiki text:
@Category: Java Programming @Type: Howto @Keywords: Java, Frameworks, Jakarta Struts, Hibernate
Which could render as:
A click a link should show a list of pages with the same metadata value.
(This is a navigation issue, not a metadata issue. It should be a separate feature idea.)
To use a Wiki for book building, one could for example add meta data like:
This may be also useful for later conversion of a complete Wiki into a DocBook or PDF document, but could already be used to provide a real PageIndex for existing pages, because one topic/page links to another.
Comments by GoofRider: When discussing navigation in the context of metadata, the appropiate implementation, I believe, would be assigning page numbers in a specific namespace, like:
@Chatper: SomeWikiBook:1
Then the navigation menu can be generated using a macro like:
[[BookNavigation(SomeWikiBook)]]
In any case, this is mostly a navigation issue. While it’s a good example of what addtional functionality can be made possible by having metadata support in wikis, nevertheless, it’s beyond the scoop of a discussion regarding the implementation of metadata support itself.
People use wiki for all sorts of things. People are now storing FOAF data, and other data meant for machines, in wiki.
You could have a metadata tag that told how the data was supposed to be returned.
You could specify: Content-type: application/rdf+xml or Content-type: text/plain … or whatever.
You just read the metadata for the page, cached or straight from the page, before responding, and then start your response with what the metadata says, or return as a normal HTML page if there’s no metadata.
It should be noted that it’s dangerous to consider PageMetaData a direct mapping for the <META> tage in HTML. The <META> tag is all but one possible presentation (i.e. a view) of metadata of a page. If we consider PageMetaData as a mean of only to present <META> tags, then we’re reducing PageMetaData to a presentation feature, rather than an architectural design feature as it’s originally intended.
Other than HTML <META> tags, metadata of a wiki page may also be presented in RSS, XML, RDF, vCard, iCal, TopicMaps, as well as many others. HTML is all but one presentation.
PageMetaData itself needs to exist in its own context interally, outside of the raw body text. However, an implementation may declare metadata within the body text itself. In fact, in-bodytext declaration should be considered as merely an input method – the fact that a user enter metadata and body text together in the same UI does not neccessary imply nor restrict them to be stored together. The WikiEngine will parse and extract metadata fields once the page is saved, and save metadata in a different context internally (like separate database fields). Off-bodytext declaration like labels in SnipSnap or metadata in FacetWiki can lead to other problems, because it results in additional page data that do not exist on the body text itself. It’ll make editing and importing/exporting complicated.
Ideally, all human-entered metadata associated with a wikipage should be contained with the raw body text itself, so things like global replace will continue to work for metadata. But at the same time, WikiEngine should extract and store metadata in a separate context from the body text as well, in order to support advanced features.
Though whether a WikiEngine choose to use an in-bodytext, delcarative approach or a separate textarea as a metadata input method is a design decision that’s up to the programmers themselves, there’s little compelling reason why a wiki should use a separate UI for metadata input, other than keeping the wiki syntax clean. Consequently, the existence of a separate textbox or UI for metadata complicates the input interface itself. A declarative approach has the advantage that all human input will be contained within the page itself, a valuable design simplicity.
It’ll be architectually cleaner if the raw body text is considered simply a recording of human input. Whatever semantic information and metadata that a WikiEgine may extract out for the raw body text should be handled transparently to the user.
(Note to all: sorry if this section sounds like a relatively subjective opinion. Feel free to provide counterpoints. - GoofRider)
Does meta data need revisions like the page text itself? If yes, than it makes sense to keep the meta data in the page text. If not, it makes sense to keep it elsewhere. – NirSoffer 2007-02-03
| status | wiki engines |
|---|---|
| Implemented | DiamondWiki PmWiki MeatBall:FacetWiki Wiki:RhizomeWiki SnipSnap FlexWiki |
| Developing | - |
| Intend to Develop | ErfurtWiki |
| Considering | - |
| Rejected | - |