Potential RDF method for mapping rel/rev relationships
It’s been interesting watching - to be honest, I’ve been very busy and not able to pay a tremendous amount of attention - the discussion over rev=canonical being put forward primarily by people like Jeremy Keith. Of course, my first thought is how we can do this in RDF. Here’s an idea I just came up with. We use URNs to map HTML agreement-based semantics like ‘canonical’.
There’s nothing to it. “canonical” just becomes urn:rel:canonical. We can decide on some other prefix if we like, but why the hell not? We don’t need to represent the difference between rel and rev in RDF, because that’s just determined by the placement of the subject and object. if { ?a urn:rel:canonical ?b . }, then ?a is the canonical URL for ?b.
Now, you might ask, why use urn:rel:canonical at all? Why not just use owl:sameAs? I mean, the two are virtually indistinguishable. Fine. We write ourselves an OWL rule saying that urn:rel:canonical is owl:sameAs the property owl:sameAs. But I don’t think that urn:rel:canonical is the same as owl:sameAs. The latter says that the two resources are equal, and that all the properties of the subject of owl:sameAs can be transferred to the object. In philosophical jargon, owl:sameAs presumes the truth of the Indiscernibility of Identicals and the Identity of Indiscernibles, and simply states that both of the slots in the two-place predicate fit in the x and y position of Leibniz’s two II principles.
Is this the case for urn:rel:canonical? I’m not totally sure. At some level, if, say, tommorris.org/foaf#me represents me, then a TinyURL that 30X redirects to the same URI should have the same properties. My brain says it should, but my gut says that it doesn’t. There’s a reason why people spread is.gd, bit.ly and TinyURLs. We might specifically want to make statements about those URIs: when they were shortened and by whom. Some of the URIs have bad stuff like iframes (DiggBar) - some of them have features that are supposed to be quite useful (previews). On some you can monitor the number of people who click through, and on others you can actually change the URI of the redirection (initial reaction: yuck, but it could be marginally useful sometimes). I’m not much of a fan of any of these features (I’m not much of a fan of URI shorteners. They only have two uses for me: Twitter and for rickrolling/jarrolling etc. In the latter, I’m not really bothered too much about semantic purity, and in the former, well, Twitter could do something smarter with URIs). Even so, all this stuff seems like something we should perhaps leave open. People are using canonical in HTML, so it seems sensible to make it so they can use it in RDF. urn:rel:canonical solves that problem, and also gives us a namespace for other rel/rev links.
Before people start using this, I hope we have a reasonable discussion about this. The only problem we really have is that there are other rel values that have been codified differently. XFN values like ‘me’, ‘friend’ and so on have been put under the namespace vocab.sindice.com/xfn# while the jokey XEN values have been put under buzzword.org.uk/rdf/xen# - but here’s the thing. If we are parsing simply based on rel values, without any guidance as to their semantic meaning, we can’t be 100% sure that a rel=’friend’ link matches the XFN definition. It might be a pretty good guess: not many people will add a rel attribute for ‘friend’ to a link if they don’t mean something broadly like what the microformats community means by it. Perhaps one could quite easily build that into the process though: just by default, if one is turning HTML into RDF, use urn:rel, then convert known urn:rel values into a more qualified URI if one can be reasonably sure that it is the meaning. For instance, if one parses a webpage containing a whole stash of things which look like microformats, then you can be a whole lot more sure they are microformats. Similarly, if you are parsing a site like Twitter, you can be sure that the microformats are real - I mean, they appear in the same regions of the DOM on plenty of different pages.
Anyway, urn:rel. Thoughts welcome. Now I’ve got to actually get on with some work.
