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<[email protected]> é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
