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: Phil Archer <phil.archer@talis.com>
Date: Mon, 10 Jan 2011 13:00:20 +0000
Message-ID: <4D2B02E4.6050308@talis.com>
To: William Waites <ww@styx.org>
CC: Vasiliy Faronov <vfaronov@gmail.com>, Tim Berners-Lee <timbl@w3.org>, Peter DeVries <pete.devries@gmail.com>, public-lod@w3.org
Hmmm... no, sorry, William, I think we're destined to disagree.

On the Web in general, URIs don't, or certainly shouldn't, imply any 
particular content type. It is perfectly valid, for example, to return a 
PNG image from a URI that ends in .gif (awkward, unexpected, probably 
silly, but not 'wrong', especially if the Accept Headers indicate a 
preference for PNG over GIF). RDF does not require any URI to be 
dereferencable so that, as you say, you can process a graph without 
having to dereference anything. If you /do/ dereference a URI you might 
get a 406 Not Acceptable response, which, IMHO, is as valid as any other 
(and I'm trying hard not to reopen the 303 debate yet again here!!). If 
the User Agent can only accept certain content types then it should make 
that explicit in is request headers and be ready to handle a 406 in some 
intelligent way.

Phil.

On 10/01/2011 12:45, William Waites wrote:
> * [2011-01-10 08:55:59 +0000] Phil Archer<phil.archer@talis.com>  écrit:
>
> ] However... a property should not imply any content type AFAIAC. That's
> ] the job of the HTTP Headers. If software de-references an rdfs:seeAlso
> ] object and only expects RDF then it should have a suitable accept
> ] header. if the server can't respond with that content type, there are
> ] codes to handle that.
>
> I disagree that we should rely on HTTP headers for this.
> Consider local processing of a large multi-graph dataset.
> These kinds of properties can act as hints to process one
> graph or another without the need to dereference something.
> (tending to think of graph as equivalent to "document
> obtained by dereferencing the graph's name).
>
> Slightly more esoteric are graphs made available over
> ftp, finger, freenet, etc.. Let's take advantage of HTTP
> where appropriate but not mix up the transport and
> content unnecessariy.
>
> Cheers,
> -w

-- 


Phil Archer
Talis Systems Ltd,
Web: http://www.talis.com
Tel: +44 1473 434770
Twitter: philarcher1
LinkedIn: http://uk.linkedin.com/in/philarcher
Personal: http://philarcher.org
Received on Monday, 10 January 2011 13:00:56 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:31 UTC