- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 14 Jan 2011 07:55:51 -0500
- To: Martin Hepp <martin.hepp@ebusiness-unibw.org>
- CC: "<john.nj.davies@bt.com>" <john.nj.davies@bt.com>, david@dbooth.org, public-lod@w3.org
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