cygri’s notes on web data

Keith Alexander experiments with using eRDF markup to populate HTML templates:

I was writing a php template, marking it up with eRDF, and I realised that what I was doing was describing variables with triples – which is essentially what I would be doing to write a SPARQL query to retrieve data for the template.

So the core of the idea is: using semantic markup in a template to generate queries, retrieve data and populate the template.

I have started to implement the idea, using eRDF for the semantic markup, SPARQL as the query language I generate to, and Smarty as the templating language. (I use the ARC RDF PHP classes for parsing the eRDF into triples, and for running the SPARQL queries).

Keith has blogged this in much more detail here, including code and template samples.

This is quite a clever idea. Let’s assume you have a web application driven by data from an RDF triple store. You generate HTML pages by querying the triple store and inserting the bits and pieces into an HTML template. Now if you add eRDF or RDFa annotations to the HTML template, in a way that reflects the original RDF data, then by definition the annotations completely specify what data you need to populate the page. And the template itself therefore must be sufficient to extract all the required triples from the store. No coding needed!

So, generalising the approach and glossing over many details: Just take a big ball of RDF data (dump or behind a SPARQL endpoint), and throw a bunch of HTML templates with embedded annotations at it, and you get a dynamic web site without writing any code. And the web site will have complete semantic annotations.

That’s an example of what becomes possible after you’ve payed the RDF tax.

Keith points out that this is similar to what Fresnel is designed to do, but I have to say that I find this template-based approach more appealing.

(Via simile-general)

Andy Seaborne announces a first draft of SPARUL, the SPARQL/Update Language:

This document describes SPARQL/Update (nicknamed “SPARUL”), an update language for RDF graphs. It uses a syntax derived form SPARQL. Update operations are performed on a collection of graphs in a Graph Store. Operations are provided to change existing RDF graphs as well as create and remove graphs with the Graph Store. A binding of SPARQL/Update using HTTP POST is described.

Max Völkel and I did a very rough proposal for a similar language back last year. We received some criticism over this: Tunneling application protocols over HTTP is not an optimal use of the web. Case in point: the WS-* stack. I tried to work out the issues by asking how RESTful SQL would look like, a potentially illuminating analogy. I found the results inconclusive—I understand the concerns raised by REST proponents, but haven’t seen a better alternative.

The main question, I think, is one of scope: Is SPARQL Update intended as an SQL-like language that applications use to communicate with their local or nearby data store? Or is it intended as public web infrastructure, similar to Web 2.0 APIs and HTTP PUT?

The SPARUL proposal doesn’t really take a position here, although this might be interpreted as a nod towards the former:

An update service that is separate from the query service has the advantages that different security mechanisms can be applied and that the query interface remains a legal, SPARQL service.

So, public query service and local update service?

• Aren’t URNs much more elegant than those brittle HTTP URIs?
• Why is everyone yapping about 303 redirects?
• Hash vs. slash?
• What’s the deal with content negotiation and the Semantic Web?
• Shouldn’t we use blank nodes anyway?

There’s a lot of confusion around URIs on the Semantic Web. You have to do quite a bit of reading and trial-and-error to arrive at effective solutions. Leo, Max and I wrote Cool URIs for the Semantic Web (Leo’s announcement) to take some of the pain out of this process.

A couple of random companion posts from my archives:

• Debugging Semantic Web sites with cURL
• Content negotiation with hash URIs (long)
• Fixing ambiguous concept URIs
• Game theory, convention, and coordination

And, always worth a link:

• Tag “semwebintro” at del.icio.us

Over in the comments to Henry Story’s bug ontology post, I wrote:

There should be RDF representations of program error reports, such as Java exceptions. Then I could SPARQL for “NullPointerException in class so-and-so of project foobar“, and possibly a solution has been filed, or at least I will find a related bug.

Drew Perttula adds:

As to Richard’s “RDF representations of program error reports”, see http://themongoose.sourceforge.net for one of several projects that hash up the stack trace into an error id. Those seem like they could lead to excellent automatic URLs which can be later associated with the tracking of the bug that makes that stack trace. I’d love to get an error and paste its url directly in my browser to see “this error has [n] frequency in the last few weeks; [these] other users have been experiencing it; [this] developer is working on the bug fix, and the details for that bug are [here]”.

This would be very useful and is entirely doable. Exceptions should have URIs that resolve to the project’s issue tracker or web-based support forum.

Congrats, Chris!

Henry Story considers design alternatives for a FOAF-enabled personal address book that works as a desktop application. How will it publish the users’ FOAF profile to the Web?

The first scenario considered by Henry is an individual who wants to publish to her own webspace. Here, in my eyes, FTP is king. Henry is right when he says:

[FTP is] a little tricky for the end user as he would have to understand the relation between the directory structure of the ftp server and its mapping to the web server urls.

But FTP is everywhere, and Web geeks are able to figure it out. This 75% user experience will be much better than the current “write RDF/XML by hand or use FOAF-a-matic” approach. (Anyway, it’s what I use to publish my FOAF file.)

The next thing could be WebDAV because it is fairly common and could provide a 90% user experience. As for the other options: scp has not enough users, APP is still too obscure, and HTTP PUT has already failed in the marketplace.

Henry also wonders about server configuration. Servers have to be set up for the correct MIME type, 303 redirects and so on. This has to be done differently depending on the server.

Don’t bother. Put foaf.rdf on the server, take foaf.rdf#me as the person’s URI. When this works, then you can think about adding server type detection code and a “Use cool URIs” checkbox that drops the proper .htaccess file on the server. Keep in mind what’s possible.

The enterprise is Henry’s second scenario:

These companies already have a huge amount of information on their employees in their ldap directory. This is reliable and authoritative information, and should be used to generate foaf files for each employee. … Now the question is: should this foaf file be read only or read/write? If it is read/write then an agent … could overwrite the file with different information from that stored in ldap, which could cause confusion, and be frowned upon.

Both the user’s desktop application and the company’s LDAP server can contribute useful information. How to combine them? Henry suggests two solutions. The first one – the server could compare the client’s file to his own data, and reject any contradictory bits – doesn’t convince me, it puts too much complexity on the server.

The second one is an external link in the read-only company-generated RDF. It points to another RDF file that can be edited by the desktop application just as in the other scenario. I like it. And there’s already a perfect property for the link: the good old rdfs:seeAlso.

Multiple files with links between them are much simpler than files of mixed ownership. That’s why we call it Linked Data.