A toucan describedby data
Author(s) and publish date
- By:
-
-
Ada Rose Cannon
-
- Published:
If there's one thing guaranteed to spark a huge amount of e-mail on any of our mailing lists, it's raising the issue of the difference between an information resource (IR) and a non-information resource (NIR). The poster boy example is that of a toucan*. If I put http://example.com/toucan in my browser I might receive all manner of things down the wire. An image of a toucan, an audio clip of its call, a video of it in flight. Who knows, I might receive the virtual reality experience of having a toucan sitting on my desk. But a toucan cannot be transmitted as a series of bytes.
The most recent version of this debate began with a blog post by Ian Davis, CTO of (W3C Member) Talis, in which he argued for a new solution to the IR/NIR debate for linked data. After several days of intense e-mail discussion, he posted an updated version that relies on the Content-location HTTP header to disambiguate between the two. Whether the proposal survives and becomes an accepted alternative way of publishing an electronic document describing a real world object, both of which have URI identifiers, remains to be seen. But it looks hopeful and well worth considering.
It was during the debate that I realised that there was a mistake in the POWDER specifications, work on which I lead between 2007 and 2009. Admitting a mistake is always embarrassing but not to do so would only prolong the agony.
As part of POWDER, we specified a link relationship type of describedby. Now included in RFC 5988, this is a very general relationship that is defined thus:
The relationship A 'describedby' B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.
So far so good. But POWDER can be serialized as RDF/OWL and so we wanted to create a semantically identical RDF property. The relevant prefix used is wdrs so the property in question is wdrs:describedby. The error made was that we had written into the namespace document and one part of the spec an inference that wdrs:describedby pointed specifically to POWDER documents. This was a mistake as evidenced by other parts of the text.
So, an erratum has been published, with full details of the error, the (unlikely but) possible implications and the steps taken already to rectify the situation. Having done this, we can say that all of the following are legitimate and semantically identical:
- XHTML, ATOM
<link rel="describedby" href="/doc" type="foo/bar" />- HTTP
Link: </doc>; rel="describedby" type="foo/bar";- RDF
@prefix wdrs: <http://www.w3.org/2007/05/powder-s#> .
<> wdrs:describedby </doc> .
* Anyone know where the toucan meme came from originally?
I actually just made up the toucan idea as I was writing my first post. I just needed an example of something that clearly wasn't an electronic document.
Phil,
You wrote:
what about inert object. If the URI contains all instructions which leads to the copy of the object at a different place. I'm thinking about fabs for example. It will not be the same atoms, but does it matter?
Just silly thoughts in the afternoon. :)
I think your describedby is similar in meaning to foaf:topic, and to one use of dcterms:subject.
There are some variations...
X foaf:topic Y, says that Y is one of the (possibly many) things that is a subject/topic of (a Document) X.
(Y foaf:page X says the same thing backwards)
X foaf:primaryTopic Y, says that Y is the thing that is the main or primary topic of the document X.
(Y foaf:isPrimaryTopicOf X says the same thing backwards; also foaf:homepage is similar, but raises some broad expectations/intuitions about the kind of document, it's content, role etc.)
X dcterms:subject Y says that either Y is a subject code that stands for one or more of document X's subjects; perhaps represented as a string, or using SKOS. Or in some uses, same as foaf:topic, that Y (perhaps a Person or Place) is one of the things that X is actually about. As an aside, foaf:focus is a relationship that mediates between these two idioms; it links from a 'subject as a thing' to the thing itself, eg. from a SKOS concept of the city Paris, to 'Paris itself'.
If we see X wdrs:describedby Y, ... is it more like foaf:page, or foaf:isPrimaryTopicOf? That is, could it be repeated with multiple non-identical values? Is it an inverseFunctionalProperty? Can we figure out the mappings between all these similar constructs?
Dan.
I quite see your point, and that there are many instances where foaf:topic etc. may be used where wdrs:describedby is used. However, if we anchor our thinking in the @rel type of describedby, the object of the wdrs:describedby property is always expected to be a URIref and never a literal.
Can you have X foaf:topic Y or X dcterms Y where Y is a string literal?
A wise person (you) once told me that the finest specification writing can never tell people exactly how to use something. The final arbiter is always implementations and common consensus. If an individual feels that foaf:topic or foaf:isPrimaryTopic or dcterms:subject is appropriate to their situation, that's what they'll use. I think in the particular scenarios that @iand was talking about wdrs:describedby is a marginally better fit, but only marginally.
Hi Phil. Yes, foaf:topic is always a thing, a thing that some doc is about.
Re Dublin Core ... the dc usage in the http://purl.org/dc/elements/1.1/ subject: is a mix of strings and things. I believe the intent with the newer dcterms namespace is to point more to things, but that this isn't an absolute rule.
I've absolutely no problem with people using other properties, for whatever reason. But if there are actual counter examples where the one property (on its own definition) applies, and the other doesn't, we ought to write those down so that folk have a clear map of the options. Do we have one for the subject / topic / describedby situation yet?