Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

Hi Tim:

> It was the FOAF folks who, initially, instead of using linked data,
> used an Inverse Functional Property to uniquely identify
> someone and then rdfs:seeAlso to find the data about them.
> So any FOAF browser has to look up the seeAlso  or they
> don't follow any links.
>
> So tabulator always when looking up x and finding x see:also y will
> load y.  So must any similar client or any crawler.
>
> So there is a lot of existing use we would throw away if we
> allowed rdfs:seeAlso for pointing to things which do not
> provide data. (It isn't the question of conneg or mime type,
> that is a red herring. it is whether there is machine-redable
> standards-based stuff about x).

Are you saying that we should NOT use rdfs:seeAlso to point

a) from conceptual entities to Web pages (regular HTML, no RDFa)  
describing them, nor
b) from conceptual entities to images and logos depicting them?

Historically, we had always suggested a) for GoodRelations recipes and  
turned to recommending foaf:page instead only recently. The main  
reason to use rdfs:seeAlso initially was that it did not require  
anybody to commit to a second ontology.

Also, b) has been used in many cases in parallel to Yahoo's  
media:image property in the context of Yahoo Searchmonkey. As of  
today, Yahoo still recommends to use both, see

    http://developer.search.yahoo.com/help/objects/product

<span rel="rdfs:seeAlso media:image">
                   <img src="http://example.com/product.jpg"/>
               </span>

For my taste, using rdfs:seeAlso is perfectly valid (yet suboptimal,  
because too unspecific), according to the RDFS spec:

http://www.w3.org/TR/rdf-schema/#ch_seealso

Quote: "rdfs:seeAlso is an instance of rdf:Property that is used to  
indicate a resource that might provide    additional information about  
the subject resource.

A triple of the form:

S rdfs:seeAlso O

states that the resource O may provide additional information about S.  
It may be possible to retrieve representations of O from the Web, but  
this is not required. When such representations may be retrieved,  
***no constraints are placed on the format of those representations***."

So I tend to recommend that instead of discouraging the use of  
rdfs:seeAlso, clients consuming rdfs:seeAlso should take measures to  
not load unneeded payload. For example, they could limit such behavior  
to a context of certain FOAF elements or fetch the headers first and  
skip all PDF and images content. In the case of HTML, it will be  
difficult to tell ex ante whether it actually contains useful RDFa  
payload. The DOCTYPE and other header meta-data alone will be a bad  
indicator.

Best wishes

Martin





On 10.01.2011, at 16:01, Tim Berners-Lee wrote:

> It is well to look at and make best practices for the things
> we have if we don't
>
> It was the FOAF folks who, initially, instead of using linked data,
> used an Inverse Functional Property to uniquely identify
> someone and then rdfs:seeAlso to find the data about them.
> So any FOAF browser has to look up the seeAlso  or they
> don't follow any links.
>
> So tabulator always when looking up x and finding x see:also y will
> load y.  So must any similar client or any crawler.
>
> So there is a lot of existing use we would throw away if we
> allowed rdfs:seeAlso for pointing to things which do not
> provide data. (It isn't the question of conneg or mime type,
> that is a red herring. it is whether there is machine-redable
> standards-based stuff about x).
>
> Further, we should not make any weaker properties like  
> seeDocumentation
> subproperties of see:Also, or they would imply
> We maybe need a very weak top property like
>
> mayHaveSomeKindOfInfoAboutThis
>
> to be the superProperty of all the others.
>
> One things which could be stronger than seeAlso is definedBy if it
> is normally used for data, to point to the definitive ontology.
> That would then imply seeAlso.
>
> Tim
>
>
>
>
>
>
>
>
>

Received on Wednesday, 12 January 2011 14:26:27 UTC