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

On 1/14/11 3:48 AM, Martin Hepp wrote:
> 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.

+1

Kingsley

>
> 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.
>>
>>
>
>
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Friday, 14 January 2011 12:56:25 UTC