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

On 2011-01 -14, at 03:48, 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.
> 

I'm VERY sorry -- I certainly did not mean to convey fury at all.   You seemed to be suggesting that your argument followed from the
previous line.  I thought it didn't follow.

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

One I was unaware of.  A shame that they recommend that as it is very valuable
(from tabulator point of view certainly) to have an indication in the link that the destination is
an image. If one is looking for an image to illustrate something with, then one is
unlikely to dereference every seeAlso etc etc just in case.

Currently the tabulator has a cheat sheet of properties is knows have images
as objects, whether or not it is clear from the schema.    I certainly think that using as much semantics in a link as possible
is going to make the LOF web work much more effectively.

Also of course for an image I need to know that y is actually an image of x (rather than some related material but an image of something else).
foaf:depiction etc


> 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

Yes

> (except for the tone of the argument, to be frank).

Sorry, my mistake.

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

I don't think that looking at the HTTP headers is a good solution, as it means you have to do at least a HEAD
request for each thing.


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

Yes, exactly.


> For PDF and other human-readable resources, DC may provide useful properties.
> 

Yes.

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

Received on Friday, 14 January 2011 20:35:49 UTC