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: Jiří Procházka <ojirio@gmail.com>
Date: Mon, 10 Jan 2011 14:23:38 +0100
Message-ID: <4D2B085A.6070308@gmail.com>
To: William Waites <ww@styx.org>
CC: Phil Archer <phil.archer@talis.com>, Vasiliy Faronov <vfaronov@gmail.com>, Tim Berners-Lee <timbl@w3.org>, Peter DeVries <pete.devries@gmail.com>, public-lod@w3.org
On 01/10/2011 01:45 PM, 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

I agree, there is nothing wrong in having a subProperty which includes
more information, whether it be about the subject or object of the
triple, regardless if it's about content type or anything else.
I believe it is good practice to specify domain and range of property in
as precisely as possible. Failing to do so begs for usage which either
is wrong by the original intention or making the meaning of the property
very fuzzy, which in both cases results in less useful data.

Best,
Jiri


Received on Monday, 10 January 2011 13:24:17 UTC

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