Using URIs inside URIs in Data 2.0

Danny Ayers spotted that John Barstow spotted Alex James giving a relational database view of the Web:
What I see as the real key to creating a virtual internet database or Data 2.0 is upgrading the idea of the foreign key.

A foreign Key in row in a database table is kind of the same thing as a hyperlink in a webpage.

[snip]

Continuing with the webpage analogy: this is a hyperlink to another page on the same site. Or somewhat more formally, but less accurately, you can think of it as a RELATIVE hyperlink, i.e. something like this: ‘/Table/Key’ rather than something like this: ‘http://Server/Database/Table/Key’.

Alex gets really excited and starts worrying how we will query such large amounts of data and mentions mappers that hydrate URLs as needed and he’s right to worry. This is pretty much the same issue we have encountered in our AJAX demos with sparql.org. Alex brings up relative and absolute URLs but leaves me wanting more. We are currently stirring interest on the subject and collecting all of the references to excellent work via a wiki page: RdfAndSql. I’m sure that the Web as a database is not a foreign idea to many, but now we actually have a query language for it, it’s called SPARQL. However, be mindful though that just because it looks like SQL, doesn’t mean it is.

Most importantly I want to address the key as a hyperlink idea because of what I’ve been coding in the past days. I’m implementing Atom Publishing Protocol on top of a Semantic store. In the specification, Atom entries have ids and are specified to be URIs. In the protocol specification, you post an entry to a URL of the form: http://domain/endpoint/collectionname. The entry can suggest an id, but the APP server is ultimately who decides what the atom:id will be. Their examples use either tag URNs (tag:example.org,2006:entry1) or UUID URNs (urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a). Moreover, the server must create links so that a RESTful client can go back to get/edit the entry later on, these take of the form: http://…/entry/id, and in ther examples they use: http://example.org/edit/first-post.atom. However, first-post.atom doesn’t resemble anything as those original sexy location-independent URNs (or URIs). The question that arises in my mind is what will an Atom implementation going to do in regards to atom:ids and atom:links?

It can choose between:

  1. A Plain URI:
    <?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2003-12-13T18:30:02Z</updated>
  <author><name>John Doe</name>
  <content>Some text.</content>
  <link rel="edit" href="http://example.org/edit/first-post.atom" />
</entry>
  2. A URI within a URI approach:
    <?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2003-12-13T18:30:02Z</updated>
  <author><name>John Doe</name>
  <content>Some text.</content>
  <link rel="edit" href="http://example.org/edit/urn:uuid:1225...4efa6a" />
</entry>

At first glance, option #1 looks correct, but this not really the first thing that comes to mind for implementators. David Johnson and Roller’s implementation which is a very similar setup as option #1 does as follows. The entries are already using UUIDs as keys, so he does two things, he replaces first-post with just the UUID in the edit link and swaps out the atom:id with an absolute URL of the form: http://example.org/roller/page/handle?entry=anchor.

For now, I’m experimenting with option #2. I think that if we tie our ids to a specific location and use a hidden function to go from ids to edit links, it will be like the days when we didn’t eve use permalinks in RSS or worse. Instead, I’m using a location-independent identifier that should be treated opaquely wherever it goes and the links shouldn’t hide the full atom:id of the entry. It doesn’t break REST and allows for a more distributed view of the web. I think that HTTP does tie naming and resolution just a bit too much, but as the Web evolves into a virtual database and the rows become atom entries, we’ll be forced to look at this issue in more depth.

I’ll appreciate feedback on the matter, because I have code to write.

About this entry

You’re currently reading “Using URIs inside URIs in Data 2.0,” an entry on Elias Torres

Published:
06.16.06 / 9am
Category:
Atom, SemWeb