While browsing Google Labs today just to see what’s going on over there, I ran across something rather interesting for the ReadWriteLinkedData folks:
I then coded up a nice little service which converts the Atom feed offered by DataWiki to RDF/XML, although it’s a little bit of a kludge. But I did have a few notes on the current state of things over with the DataWiki (many of these things are bugs and issues simply due to being in the early stages of DataWiki, so it’s not like they can’t be fixed!):
Dereferenceability is good. Right now, although many of the URIs provided in the Atom feed can be dereferenced, most can’t even be dereferenced to XML, but only to HTML. The XML namespace of a particular wiki does not even link to a particularly useful description of the Wiki’s contents! Although this might be alright for a simple XML feed, it’s not so nice for RDF, which likes links which can be dereferenced to something meaningful.
Pablo and the others working on DataWiki shouldn’t take this as a harsh criticism: this seems to be a common problem with people first introduced to RDF (and here, it wasn’t even in RDF to start!). Indeed we’ve had the same discussion with the guys over at Facebook when they put out their Open Graph Protocol, and successfully convinced them to put out a dereferenceable namespace URI.
Describe your schema. Granted, this dovetails nicely with the previous point, in that, once the schema is dereferenceable, it should actually have meaning. Right now, the namespace of a particular wiki is just a base URI, without a fragment identifier. This causes problems if I want to refer to the particular schema properties (e.g. name, comment, etc.). Thus, I’ve taken the liberty of modifying the base namespace to add a fragment ID so as to be able to make the properties dereferenceable (even if they aren’t in practice). Following the reference should (ideally) give some description, however.
Pushback should be easy. It should be possible to push back using any number of methods. I should be able to find out what the schema looks like and push (such as through WebDAV, or RESTful HTTP, or SPARQL) back to the server. Right now, it’s not trivial to actually push changes back with my converter, so I don’t do this. But then, this ties into the bug where, currently, I can’t get XML data for individual data items, and as such, can’t dereference them.
Datatyping is nice, but only if it’s done right. Right now, there’s no way to determine how I should interpret a field. Part of this is because datatypes aren’t supported yet. Well, that’s fine, but I hope that in the future, I will be able to map whatever layman datatypes that are supported into corresponding XML Schema Datatypes and RDF Resources. The latter is especially important if there are ever links between data-items, or we lose the whole point behind a Wiki (or Linked Data!).
Remember web applications! One thing I’ve tried to do with the converter is to keep it simple: it just uses an XSL transformation (so anyone can reuse it with their own DataWiki). I’ve also tried to play nicely with AJAX by enabling cross-origin requests (CORS). Hopefully DataWiki can do the same.
Anyway, this is rather exciting stuff, so I hope that this will keep rolling. As Semantic MediaWiki and the ReadWriteLinkedData efforts have shown (not to mention DataPress and RDF support in Drupal 7), there’s definitely a need to actually reveal meaningful data in a user-editable format. With people in Google starting to take to the idea as well, I don’t think it will be too long before we start seeing this idea really take off for the public at large.