W3C home > Mailing lists > Public > public-lod@w3.org > January 2011

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

From: Nathan <nathan@webr3.org>
Date: Thu, 13 Jan 2011 11:21:36 +0000
Message-ID: <4D2EE040.3020302@webr3.org>
To: Phil Archer <phil.archer@talis.com>
CC: Martin Hepp <martin.hepp@ebusiness-unibw.org>, Tim Berners-Lee <timbl@w3.org>, Vasiliy Faronov <vfaronov@gmail.com>, Toby Inkster <tai@g5n.co.uk>, Peter DeVries <pete.devries@gmail.com>, public-lod@w3.org
Phil Archer wrote:
> Martin seems to be fighting a lone battle, but fwiw I'll add my +1 to 
> his comments.
> I do take the point that, in context, it's really nice if rdfs:seeAlso 
> gives a URI that provides more data in RDF and many applications will 
> make that assumption. But to /rely/ on that every time seems at odds 
> with the, AIUI fundamental notion, that a URI is an identifier and no more.
> I'd say that if you see an rdfs:seeAlso property, sure, send an HTTP 
> request, but do it with a suitable accept header. If you get a 200, 
> great, add the data, but be ready to deal with a 406 (I've got it but 
> not in the format you have specified in your request).
> Describing a URI with further triples is good, nothing wrong with that, 
> but to use that to decide whether or not to dereference an rdfs:seeAlso 
> URI means looking for a description of the linked resource and then 
> acting accordingly. That sounds like a relatively heavy bit of 
> processing that HTTP kind of takes care of for you.

So then if you use { S rdfs:seeAlso O } then O is used with a 
dereferencable http/https scheme URI which deferences to an information 
resource with a representation in any format which may or may not have 
something to do with the subject of the triple.

Apologies, previously I'd thought the O was a name which you'd look for 
in the subject position of other statements. (as in, any RDF URI 
Reference, any scheme, or any blank node).


Received on Thursday, 13 January 2011 11:22:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:11 UTC