Whenever I read an article, blog post or a comment that disses the Semantic Web, RDF or RDF/XML, I wonder why so many people find it necessary to try to belittle another technology or approach. It is almost always clear — at least to me — that there are no facts or knowledge to back up the claims, but it seems there are always enough readers out there that come away with the impression of facts instead of opinions.
I don’t know much about Topic Maps, Django or FreeBSD, but you don’t see me trying to argue that they are inferior, somewhat misguied or simply plain wrong. Even if that may be the case, I wouldn’t know, and I refuse to argue for or against something I don’t know anything about.
Perhaps those people out there feel out-of-the-loop for not understanding, and then pick arguments against another view instead of arguing for their own view? Perhaps they are trying to push an inferior technology and feel a need to make alternatives look inferior as well?
I don’t know.
But I do know, that the next time I see an “argument” against the Semantic Web, I will check the new GetSemantic Argument Wiki, and I hope that you will too.
In the meantime, please take 8 minutes of your day to watch Tim Berners-Lee talk about his vision for the web. That’s real.
Danny Ayers has been working on getting the SIMILE Timeline to eat SPARQL through the use of its JSON interface and some XSLT, he has notes on the ESW wiki.
While trying to get his work running here, I realized that the trip through XSLT to create JSON output really wasn’t necessary.
Instead, I’ve created a custom SPARQL event source parser, to load SPARQL results directly into the timeline. This way, the SPARQL results format generated by running the query doesn’t need a round trip into either JSON or the custom Timeline XML format.
The SPARQL Timeline demo works with any RSS 1.0 feed (try it with the one from Planet RDF) .
Update: Now also works with “raw” SPARQL results, try it with photos of laptops from The Gargonza Experiment (scroll to April of 2005). Expected variable bindings are
link, although the latter is optional and the first can be replaced by
Over the last week, Planet RDF has seen more than a few posts and comments on the RDF/XML serialisation syntax, most of them looking into its (almost not enumerable) possible variations.
Danny Ayers has a great overview with reference to the expectations, not an unimportant point — as my boss always tells me: It’s all about controlling expectations.
All in all, I agree with most of the comments on the subject, even parts of the ones that don’t seem to agree with each other.
In short: RDF/XML is just a syntax (it’s the RDF model that counts), and while I generally find it acceptable, the variation is one aspect I hope I would have done different had I been involved. That would make it more accessible to XML tools such as XSLT, leading to easier ways of generating clean XML for other uses.
The subject of RDF/XML variation is as close to being a permathread as it can be, and I’ve participated before myself, mostly with regard to the R3X syntax subset. I’ve been doing a lot of XSLT as well, and three recommendations come to mind when considering a syntactic profile or subset of RDF/XML, to reduce the variation:
- Drop the attribute form
- Except for aesthetic reasons, it’s not necessary.
- Don’t use typed nodes
- While it may seem easier and smarter to write
<rdf:Description><rdf:type rdf:resource="&foaf;Person"/>...</rdf:Description>, it makes it much harder to deal with nodes that have multiple types (and using named entities can help a lot too).
- Sort and group
- ‘nuf said — don’t break statements about the same subject into different elements, keep them together and don’t nest at all.
That said, I don’t consider the deficiencies of RDF/XML to be serious enough to warrant a new XML syntax — after all, there are plenty of RDF/XML parsers out there by now, and the real challenges lies elsewhere (see: Crisis, LargeTripleStores, and Tagtriples + identity precision).
There’s lots of talk about service descriptions these days, most notably around Tim Bray’s WSDL discussions (which includes SMEX-D), Norm Walsh’s NSDL for WITW, and the DAWG’s Saddle, to be a part of the SPARQL protocol. Phew, acronym overload…
Also in that space is OWL-S, an OWL-based Web service ontology that Danny Ayers has looked at. I though it would be fitting to describe semantic web services with RDF, so I tried it out but ended up feeling quite like Norm after his WSDL endeavour.
I did however manage to get something working, OWL-S Maker, which only uses a subset (and possibly in a wrong way), but is self-powered through its own service description, a PHP class (which currently has too many local dependencies to be worth anything to anyone but myself), and some XSLT. The descriptions could use some more work regarding the “typing” of inputs, but I thank Saddle may eventually provide some insights there. As for the general modelling of services, input, and output, I think I may have to look elsewhere — OWL-S seems too complicated.
As a usage example, see the Sparqlette service description input and the description of nearestAirport for a partially handcrafted example with two profiles.
UPDATE: This implementation has been updated, please see Named Graph Exchange.
Every now and then I’ve run into the need for transporting an RDF graph between triple stores. I use Redland/MySQL with contexts to store information about the origin of each triple, so up until now the only way has been to transfer the triples directly from one database to another. This is because triples are just that, triples, not quads, and RDF itself only provides reification as a way out, not a very attractive option for space and performance reasons.
There have been other approaches to dealing with graph naming in RDF, TriG is one, N3/cwm has another — here’s yet another way: Wrapping up the graphs not in a single document, but in a zip archive with an index mapping documents to names.
It may seem unwise to seemingly try to circumvent real provenance issues by “just” naming graphs, but this is only intended for exchange between trusted parties, it’s not a format that’s expected to be found and consumed as other RDF documents found on the Web.
Continue reading Exchange of Named RDF Graphs