FrontPage SiteMap RecentChanges HowTo Blog

Matching Pages:

RSS

RdfInWikis

Flexible meta-data

The primary goal of RdfInWikis is using the ResourceDescriptionFramework to frame a Wiki's meta-data. While the engine may only use and present a fixed set of meta-data (say, the DublinCore), adding more should be a matter of altering the front-end, not altering the internal storage.

This has nothing to do with RDF/XML (though you could use RDF/XML internally). At its heart, RDF contains just two ideas: every predicate is just a URI; every statement (piece of meta-data) is just a resource, like everything else. If a Wiki can handle that, it can handle the following parts of RdfInWikis.

Adding meta-data

Initially, meta-data comes from two sources: the Wiki engine, and the Wiki user. The former can add a lot of value to a Wiki if combined with some later goals, like ontologies and emission. Many Wikis provide an RSS feed in addition to RecentChanges-style pages, allowing remote aggregation of updates to many Wikis. DublinCoreForWiki suggests a full set of DublinCore meta-data that can be emitted for existing Wiki pages.

How to manually add RDF meta-data to a page is the focus of some current research. Perhaps the most Wiki-like approach is to extract information from the plain text of the page, using a prescribed MetadataSyntax. Again, the goal should be to pick a method that extends simply and logically to cover a wider range of meta-data.

This has no connection with RDF/XML, and probably shouldn't, as RDF/XML is not generally regarded as human-readable.

See also MeatBall:RdfForWikis.

Adding ontologies

Once your Wiki starts supporting larger sets of properties, you will want a standardised way of writing an ontology, teaching the Wiki to understand and build upon the meta-data it's given. This gives us, for instance, indices.

This has nothing to do with RDF/XML. OWL (WebOntologyLanguage) is appropriate here. Eventually, there will be choices about what to store and what to re-deduce if an ontology uses the more complex parts of OWL, since the quantity of implied meta-data begins to dwarf what is actually provided.

Presenting voluminous data

Meta-data, like everything, has issues of scaling. Small quantities can be used for indices and the like, but when a category like biology has hundreds of sub-categories and thousands of entries, other approaches will be needed. Simple query forms will help meta-data presentation scale, and graphical displays can be provided for that high-tech twist.

More complex querying systems can only be designed once a site has accumulated lots of meta-data. Visions of intelligent agents and natural-language query systems are nice, but cannot be made concrete until earlier parts of RdfInWikis have been adopted on a wide scale.

Emitting meta-data for machines

RDF/XML is a standardised way of emitting meta-data for other machines to read, and any Wiki using RDF internally will probably want to provide a RDF/XML stream. This does not prohibit emitting DC in <meta> elements or in human-readable form; indeed, the more ways you can skin a cat, the better. (All this repetition must be done by the Wiki, though, not by people.)

Other candidates for the emission format are RSS 1.0 (a deviant of RDF/XML) and TriX?.

Reading meta-data from machines

Reading in standardised meta-data allows one to connect sites (UnifiedCommons).

This is probably the hardest step. Reading arbitrary RDF/XML is tough, as the standard contains a lot of special cases for people who wanted to write by hand. Other formats might prove more tractable, but one must still handle external meta-data that changes, and may even have cyclic dependencies on one's own meta-data emissions.

There are also issues of balancing automation with defence against spam. If we make it easy for one site to hand us meta-data, we make it easy for spammers to overwhelm us. WebLogs are continually encountering this problem as the major 'blogs get targeted by advertisers. This ties in with existing Wiki technology like StableCopy.

Earlier presentation (redundant?)

There are several possible overlaps between the ResourceDescriptionFramework and Wiki techniques/technology.

  1. Using RDF metadata to describe traditional Wiki resources (pages, images, etc.). DublinCoreForWiki is one way to do this.
  2. Using Wiki techniques (editing open to all, simplified markup language/MetadataSyntax) to create RDF descriptions for any kinds of resources.
  3. Using Wiki techniques to make RDF descriptions of Wiki resources; in other words, a mixture of both of the above.


CategoryWikiTechnology

Example (unimplemented) Applications

Right now a text search for the above phrase doesn't find the results indicated. The page [NeuroWiki:HippocampalBasketCell?] says "Also known as perisomatic inhibitory cells" and also "These interneurons are necessary for the HippocampalThetaRhythm?", and the hippocampalThetaRhythm is a type of oscillation (in fact, the page is even in NeuroWiki's categoryOscillation). A human who read both pages would know that, but the computer doesn't.

Implementations

(Maybe enough links? ;))

Discussion

I realize that Dublin Core is not the be-all and end-all of RDF, but the stuff on DublinCoreForWiki is RDF, and it is for wikis. The simple Dublin Core stuff is valid XML, but it's also valid RDF. The new extended Dublin Core recommendation is RDF-only. The extended version, at the bottom of the page, has much of the functionality (links, versions, etc.) requested on MeatBall:RdfForWikis.

The particular syntactical expression of Dublin Core (i.e., whether its in RDF or some other syntax) isn't IMO what's valuable about it, it's the specific semantics developed by the library community for expressing metadata about information resources, like subject, author, publication date, etc. and the fact that it has become such a standard within the international library community (9,000 institutions cataloguing 54 million records). If librarians don't know how to organize information, nobody does. Because the Dublin Core Metadata Initiative (DCMI) has published a document on how to express DC in HTML or XHTML, there's little need to be able to parse RDF, and little need to worry about the ability of browsers to process it. I've found most of the time, expressing the DC metadata within <meta> elements (as according to the DCMI spec) provides everything I need. In my own application, I sniff the DC content out of XHTML documents by simply grabbing the document's <head>, extracting its <meta> elements, and processing accordingly. Likewise, when I generate XHTML, I populate the documents with DC metadata, all in <meta> elements. No need for anything fancier and harder to process.

Don't conflate RDF/XML with RDF. "Getting Wikis to use RDF" is a broad title for many parts:

  • A clean way of extending the meta-data stored by the Wiki. DublinCore is a big initial step here, mainly because it's such a widely-applicable standard.

This has nothing to do with RDF/XML. At its heart, RDF contains just two ideas: every predicate is just a URI; every statement (piece of meta-data) is just a resource, like everything else. If a Wiki can handle that, it can handle RDF.

  • A standardised way of writing an ontology, teaching the Wiki to build upon the meta-data its given. This gives us, for instance, indices.

Again, this has nothing to do with RDF/XML. OWL is appropriate here, and basic implications and deductions. Choices about what to store and what to re-deduce if an ontology gains complexity.

  • A standardised way of emitting meta-data for other machines to read. This will probably be RDF/XML, or RSS. This does not prohibit emitting DC in <meta> elements or in human-readable form; indeed, the more ways you can skin a cat, the better. (All this repetition must be done by the Wiki, though, not by people.)

  • Reading in standardised meta-data to connect sites. This is probably the hardest step: reading arbitrary RDF/XML; balancing automation with defence against spam; handling external meta-data that changes, and may even have cyclic dependencies.

A Wiki can use RdfInWikis without needing to do all of these; PeriPeri isn't finished with the first three. The benefits are a solid foundation for meta-data initiatives :)

Sorry, I still don't see why DublinCoreForWiki shouldn't be linked from this page. So I put the link back in.

If you have a very specific purpose for this page, you need to add it up at the top, here. Otherwise, I see "RDF in Wikis" meaning exactly that: using RDF in wikis. The mechanism described in DublinCoreForWiki is an example of that.

OK, I'm having a lightbulb moment. Chris, are you trying to describe building RDF descriptions with a Wiki technique? Or using RDF to describe (traditional) Wiki resources like pages and possibly images or other files? Or a combination of both -- using wiki technique to create RDF that describes other wiki-created resources?

Oh, hey: I guess I'll just ask that question in DocumentMode.

Building. Check out MetadataSyntax.

I've stuck in a new presentation. Is it acceptable?

I finally understand what you guys are talking about! :) I find it very readable. Thanks.

Could we move this page to WikiFeatures?

Move? I would object. Copy? I guess that's part of the license :)

Well, only if WikiFeatures has either ShareAlike or GFDL or a disjunction of them. I thought it was PublicDomain, but actually I think no policy is posted.

But I'll go ahead and copy it anyway if no one objects.

The text at the top is mine; you can definitely copy that.

I was just reading this great primer on Notation3 ("N3"). I wonder how appropriate this would be for hand-edited RDF in Wiki pages.

There's a cool experimental N3 Wiki out there, too.


See also CrystalPalace.

Define external redirect: HippocampalBasketCell ZebraFinchRAInhibitoryNeuron TriX HippocampalThetaRhythm

EditNearLinks: ShareAlike FacetWiki PeriPeri PmWiki DocumentMode MetadataSyntax StableCopy CrystalPalace WebLogs PlatypusWiki

Languages: