bestkungfu weblog

Thus far, the Semantic Web is “unplugged” — it’s missing connectivity of SemWeb objects to each other. The tools and standards in existence are great for standalone servers pushing out content, but only HTML is going out over the wire. We’re missing the part where servers talk to each other. The famous SemWeb layer cake is missing a protocol layer.

A SemWeb protocol would be useful for clients (i.e, IE) that want to explore metadata or other relationships with the content it’s received; client apps that want to aggregate content to share it with other clients (ooh. Want that.); or to query into multiple SemWeb applications and unify it for the user.

An app using this protocol needs to be able to update, query, be easy to implement and deploy, support transactions, allow server introspection, resolve identity, be secure, support auditing, and have a small footprint. (I’d like to add that it should clean my toilet and make me cookies. Or at least contact my toilet-cleaning and cookie-making bots, discover what they do, and make them do it.)

HTTP and URIQA are two existing protocols that don’t fit all the requirements. HTTP doesn’t have query capability, a way to perform updates, etc., and that is keeping the SemWeb from gaining traction. URIQA, on the other hand, does these things, or does them better.

Moore and Andy Seaborne of HP wrote the RDF Net API and submitted it to the W3C. The goal was a way to remotely update and query RDF models. It was designed as an abstract protocol becaues they didn’t want to design an XML-based language, or do the syntax first. An abstract protocol allows different implementations. The API consists of:

query

Allows queries to be written in several languages, with a choice of result formats (RDF, XML, etc.)

getStatements

Evaluate contents.

insertStatements

Add new knowledge into knowledge base.

removeStatements

Delete stuff.

putStatements

Replace the knowledge base.

updateStatements

Batch job to insert and remove in a transaction.

options

What query languages the server supports, etc.

SOAP and HTTP bindings are available. RDF Net API meets the aforementioned design guidelines, with some limitations. There’s no security model, some issues with queries. Also missing is a Topic Map protocol. Moore describes topic map servers are “SemWeb servers in disguise.” Some of the approach with RDF Net API is reusable with topic maps. Among the issues is how to get small portions of a given topic map. (After he went from RDF Net to topic maps, I went from treading water to drowning. I’m not what you’d call a subject matter expert on topic maps. I tried to hang in there, folks. I really did.)