- From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
- Date: Wed, 12 Jan 2011 15:21:00 +0100
- To: Tim Berners-Lee <timbl@w3.org>
- Cc: Vasiliy Faronov <vfaronov@gmail.com>, Toby Inkster <tai@g5n.co.uk>, Peter DeVries <pete.devries@gmail.com>, public-lod@w3.org
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