Raw

Seki is my little project intended to explore some of the space around the notion of a Linked Data Platform (bit of praxis there, I didn't envision it that way when I started). The W3C have chartered an LDP Working Group, so obviously I'll be watching over there for tie-ins. The approach I'm taking is to build a front end/bridge to a SPARQL 1.1-capable triplestore. So far I've got a rough skeleton down so it can behave essentially as a (very crude) CMS. When I was last looking at the code I hit something of a stumbling block with how best to cover authentication/authorization. On paper it looks like the modeling side of it should be straightforward, though in practice there are a lot of choices, not obvious which are better - Bergi (the Bergwinkl one)) has been putting some time in on it recently, I reckon I'll just follow his lead. Protocol-wise, I think for now I'll just go with HTTP Basic. Seki uses node.js and I get the sense that it'll be very straightforward to wrap the appropriate parts in HTTPS. (I think when I asked around, Hixie's suggestion was Basic over HTTPS).

My intention was once Seki was fairly usable I'd slap it on hyperdata.org, play with it live there. As it happened the DB behind the Wiki I had running there got corrupted, so a couple of days ago I pushed Seki in its place. It's far from what you'd call fully functional yet, but all I needed right away was it to serve static files, and that it's doing admirably.

Once I've go it going properly with basic CMS functionality (with auth), I plan to have a go at hooking in some of the things I saw at the Salzburg workshop the other week - Apache Stanbol, the VIE widgets and associated bits and pieces. The motivation there is in part that those things are just cool stuff, but there's a slightly deeper reason too. Their design is such that they are strongly componentized, with primary interface everywhere being the Web. Architecturally, IMHO, that has to be the right direction.

<http://hyperdata.org/Hello> a sioc:Post ;
	dc:date "2012-04-02T07:24:53.676Z" ;
	dc:title "Hello World!" ;
	sioc:content "My first post." ;
	foaf:maker [ foaf:nick "danja" ] .

schema:articleBody owl:equivalentProperty sioc:content .
schema:author owl:equivalentProperty foaf:maker .

schema:name rdfs:subPropertyOf dc:title .
schema:datePublished owl:equivalentProperty dc:issued .
schema:Article rdfs:subClassOf sioc:Item .

foaf:nick rdfs:subPropertyOf schema:additionalName .

Top-level terms

I think it would be very helpful if schema.org was a bit clearer about "top-level" terms. Right now Thing has description, name, image, url. Ok, not bad as a first pass against what's needed on the Web. But url is/should be redundant (but that's just my semweb prejudices), there's slight conflict between description and content-oriented terms like articleBody which has the intermediate node of Article. (This isn't a new phenomenon, RSS history is littered with the wreckage of content vs. description, and higher up the architectural tree it's one of the features of httpRange-14). Ok, maybe description is useful enough to leave alone, similarly name is probably reasonable to cover the top level of label, title, name. image I suppose is fair enough, a pragmatic approach to something that could easily get messy if more WebArch was brought into the picture. I guess my recommendations then would be to add a term Item (for a generic Information Resource, superclass of Article etc) and date (for a superproperty of all dates).

Automatic mapping

I haven't yet decided whether or not to use the Web vocab or schema.org versions of the terms in my internal RDF, I suppose I could even use both. But my little experience above demonstrates it's not yet obvious how to map across even with these really common terms. If the starting point was something richer, the amount of work involved could easily explode. Some kind of automation is desirable, for the benefit of someone like me in the current situation, a publisher of semantically marked-up HTML that would like their material to connect with the Linked Data Cloud, or someone writing an app that consumes data across different vocabularies. A service (or two) springs to mind: give it a term and it responds with correspondences from other vocabs, or give it a lump of data and let it offer a translation to the preferred vocab(s)/format. There are at least two approaches to implementation: SPARQL CONSTRUCT and/or RDFS/OWL inference (in both cases the use of generic superclasses/properties could be useful). The front end could offer something like the Rich Snippets Testing Tool for authors together with an open API for translation by app developers, to give a leg-up for integration/mashups. It would be nice if the good folks behind schema.org would consider throwing some resources in this direction.

See also :

• Dan Brickley at the BBC on schema.org (video)
• Danbri has moved on – should we follow?
• I, for one, welcome our new Microdata Overlords

Comments to G+ please

It is possible to learn enough Javascript and node.js to do useful stuff in a week.

I've just done it. I'm not exactly familiar with the idioms and I'm sure there are constructs I've not yet encountered, but it's to be expected that broad knowledge will take time.

Of course I had encountered JS before, around HTML/browser, but had never tried doing any proper coding with it. It certainly doesn't lack power, but one drawback I'd say is that its flexibility means that it isn't always obvious what's going on. That goes double for node.js, where having callbacks everywhere can make things confusing (though I'm beginning to get used to that).

The little app I've put together is much more concise than it would be in the languages with which I'm familiar (mostly Java and Python), but then needing a lot of comments to explain what's going on isn't a good smell.

However, if my vague understanding of how node.js works is remotely correct, I get performance/scalability for free (something that'd need a lot of thought in Java/Python). node.js really does lend itself to Web wiring.