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
![http://example.com/product.jpg"/](http://example.com/product.jpg"/){kind=link}