Re: Semantics of rdfs:seeAlso (Was: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?)

Hi John:
> IMHO (i) Martin is right regarding the (interpretation of the)  
> definition of rdfs:seeAlso (ii) Tim is right regarding the practical  
> issues thrown up by use of the wider interpretation of the range of  
> rdfs:seeAlso.
>
> The question is: how to fix this for the community in general -  
> maybe we should have 2 relations, one with a more restricted range  
> than the other...?

Thanks for the nice summary and the attempt to reconcile the two views  
on this. In fact, I was pretty surprised become subject to such verbal  
fury ("you made that up" ;-)") for just citing the official W3C RDFS  
spec.

Since there are many shop applications currently using rdfs:seeAlso to  
point to product images, based on Yahoo's official GoodRelations  
pattern recommendation from 2008 [1], every client MUST expect to run  
into non-RDF resources when following rdfs:seeAlso. That is a simple  
matter of fact.

The problem may not yet have had significant consequences since

- the product images are often rather small files and
- FOAF-related clients may rarely consume shop site data.

Yet it can lead to serious trouble in the future; hence it is good to  
have this discussion now (except for the tone of the argument, to be  
frank).

So fixing the code of existing clients that employ a non-standard  
heuristics instead of checking the HTTP results header and evaluating  
the media type and / or size of the representation of the resource  
seems the only option to me.

In parallel, we can discourage people to use rdfs:seeAlso to point to  
non-RDF resources in the future. It can easily be substituted by  
foaf:depiction for images and foaf:page for HTML resources without  
RDFa. For PDF and other human-readable resources, DC may provide  
useful properties.

Best

Martin

[1] http://developer.search.yahoo.com/help/objects/product#tab2

On 13.01.2011, at 18:41, <john.nj.davies@bt.com>  
<john.nj.davies@bt.com> wrote:

>
>
> John Davies.
>
> -----Original Message-----
> From: public-lod-request@w3.org [mailto:public-lod-request@w3.org]  
> On Behalf Of David Booth
> Sent: 13 January 2011 17:17
> To: Martin Hepp
> Cc: Linked Open Data
> Subject: Re: Semantics of rdfs:seeAlso (Was: Is it best practices to  
> use a rdfs:seeAlso link to a potentially multimegabyte PDF?)
>
> FWIW, I also agree with Martin's comments.  It is the client's
> responsibility to decide what to retrieve and accept:
>
> 1. The definition of rdfs:seeAlso very clearly states that "When such
> representations may be retrieved, no constraints are placed on the
> format of those representations."
> http://www.w3.org/TR/rdf-schema/#ch_seealso
>
> 2. Only the client can know what formats and how much data it wants.
>
> 3. The HTTP protocol already provides content negotiation and HEAD
> features to allow a client to find out what formats and data quantity
> are available before retrieving the data.
>
> 4. There is no hard and fast distinction between RDF data and non-RDF
> data.  With the right de-serialization, *any* machine readable data  
> can
> be viewed as RDF.  This is not only what GRDDL does with plain XML,  
> but
> it is inherent to RDF itself, because RDF is a data model -- not a
> syntax.  If the client can de-serialized from a particular format to
> RDF, then the document can be viewed as RDF, regardless of whether it
> can *also* be viewed as something else.  (After all, n3 can *also* be
> viewed as plain text.)
>
>
> IMO, if there are clients that ignore available HTTP features and
> blindly retrieve large quantities of data that they cannot consume,  
> then
> those clients should be improved.
>
>
>
> -- 
> David Booth, Ph.D.
> http://dbooth.org/
>
> Opinions expressed herein are those of the author and do not  
> necessarily
> reflect those of his employer.
>
>

Received on Friday, 14 January 2011 08:49:30 UTC