- From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
- Date: Fri, 14 Jan 2011 09:48:59 +0100
- To: <john.nj.davies@bt.com> <john.nj.davies@bt.com>
- Cc: <david@dbooth.org>, <public-lod@w3.org>
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