- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Mon, 19 Apr 2004 16:19:29 -0400 (EDT)
- To: pdawes@users.sourceforge.net
- Cc: www-rdf-interest@w3.org
From: "Phil Dawes" <pdawes@users.sourceforge.net> Subject: Distributed querying on the semantic web Date: Mon, 19 Apr 2004 12:48:02 +0100 > Hi All, > > I like Patrick Stickler's assertion that in order to participate in > the 'semantic web', http URIs should be dereferencable to some > information about the URI. I believe that you meant information about the referent (denotation, meaning, ...) of the URI. If all that is available is information about the URI, then this is not very interesting, as I really don't need to know much about a URI. However, I do hope that you did not mean necessary information about the referent (denotation, meaning, ...) of the URI. I vigorously oppose any attempt to require that part of the meaning of a URI that my applications are supposed to abide by be the meaning that can be found in a document found by dereferencing the URI. To pick my favourite example, I do not want my applications to be required to abide by the information available at http://www.whitehouse.gov just because I use the URI http://www.whitehouse.gov/#GeorgeWBush, *even* if this information is only something like http://www.whitehouse.gov/#GeorgeWBush rdf:type foaf:person . > I am considering how an infrastructure > could be built where this could be exploited for distributed queries. > > The main problem with Patrick's concise-bounded-description idea from > this respect is how to find references to a term. > > For example: > > (p:PhilDawes, foaf:knows, ?person) > > ..is easy to resolve - just dereference p:PhilDawes and you probably > have the information you need. (I'm using dereference to mean 'look up > a description'). Well, I'm reluctant to ascribe any status to the information thus found that requires its use, and I certainly do not agree that it has to be the information you need. > However > > (?person, foaf:knows, p:PhilDawes) > > .is much more tricky, since these assertions are likely to be made by > users external to the domain owner of p:PhilDawes. Hmm. I'm not sure of this. For symmetric properties, it may be somewhat more likely for a document to put ``local'' URI references in the subject position, but what about properties that are conventionally written on way around. For example, I am more likely to write on one of my web pages sps:Sandy ex:loves pfps:Peter . than I am to write pfps:Peter ex:isLovedBy sps:Sandy . > Here's a straw-man solution: > > - In addition to its bounded description, dereferencing p:PhilDawes > also provides all the references it knows about. > > - When people author statements refering to p:PhilDawes, they POST > their triples to the description of p:PhilDawes. (Or maybe a third > party does). > > - The representation of p:PhilDawes polls the reference URIs it knows > about periodically to keep its data up to date. (facilitating the > removal of triples as well as addition) Independently of the authoritative status of the accessed web page I view this as extraordinarily dangerous. There is no way that I would ever subscribe to a scheme that requires any server that I have control over to make responses that include n666:antichrist owl:sameAs pfps:Peter . just because some other organization has this triple in some RDF document. I don't see how any responsible organization would ever subscribe to this scheme, even if they could somehow tag these ``contributed'' triples as having come from some other document. [...] > I am keen to hear any ideas that others may have on the subject since > in addition to helping bootstrap the semantic web, this is a facility > that would be very beneficial in my work intranet environment. I view this as a non-starter, even in a work intranet environment. Just as for the Semantic Web as a whole, there is no expectation that such local environments will have a common view of the world. > Cheers, > > Phil Peter F. Patel-Schneider Bell Labs Research
Received on Monday, 19 April 2004 16:19:57 UTC