- From: Jonathan Borden <jonathan@openhealth.org>
- Date: Wed, 20 Mar 2002 09:10:50 -0500
- To: Tim Berners-Lee <timbl@w3.org>
- CC: danc@w3.org, "'www-tag'" <www-tag@w3.org>
Tim Berners-Lee wrote: > > Dan, > > Here is my argument the HTTP URIs (without "#") should be understood as > referring to documents, not cars. > > URIs can identify anything. > > However, different schemes have different properties. > HTTP is a protocol which provides, for the client, a mapping > (the http URI dereference function) > from URI starting with "http:" and not containing a "#" to > a representation of a document. The document is the > abstract thing and the representation is bits. > > You say that what I call document could be widened to include > cars. > > Of course, you can always take a system and remove a domain > or range restriction in theory. But if inference systems use it > and you take it away, they break. Current candidate languages that employ domain and range restrictions, namely RDF Schema and DAML/OWL, are able to state restrictions on particular URIrefs, but current inferencing systems do not have _implicit_ restrictions on all URIrefs of a particular scheme. For example, what you are suggesting is _as if_ for every URIref which starts-with "http:", <daml:Class rdf:aboutEachPrefix="http:"> <daml:subClassOf rdf:resource="#document"/> <daml:disjointUnionOf rdf:parseType="daml:collection"> <daml:Thing rdf:resource="#document"/> <daml:Class> <daml:complementOf rdf:resource="#document"/> </daml:Class> </daml:disjointUnionOf> </daml:Class> Even if "rdf:aboutEachPrefix" were enabled (it has been removed from the current RDF update), is this what we want our inferencing engines to be burdened with? > > - This is not what people do at the moment. > > - The properties of HTTP are useful to know, and to be able > to infer things from. For example, if I ask > { <telnet://telnet.example.org> log:contents ?x } -> { ?x a :Interesting }. > then software would be allowed to infer, from the fact that a telnet URI is > involved > that there will be no defined contents. The difference is that you define this on a _particular URIref_, not every conceivable URIref rooted in a particular scheme. ... > > These are useful rules. They connect with common sense understandings > and also by being architectural invariants, they provide stable bases for > building > more efficient systems. This is not at all clear to me, see above. I suspect adding such rules will be a burden on inferencing systems, rather than an efficiency. In any most current systems are not equiped to handle such "rdf:aboutEachPrefix" rules. > > Why do you want to extend the range of http URI dereference to cars? Why do you want to restrict what one can say about a URI? [...] > > In this way, Resource in URI and Resource in RDF can be similarly anything, > but we have an important concept of a <part of the Web information space> > <document?> or whatever. I agree that most abstract resources such as those of class <#Person> are not normally identified with an http: URIreference. Rather, such abstract resources are 'identified' with anonymous resources (rdf bnodes) e.g. <rdf:Description> <!-- note no rdf:about or rdf:ID --> <rdf:type rdf:resource="#Person"/> <ex:email rdf:resource="mailto:jonathan@openhealth.org"/> <ex:ssn rdf:resource="xxx.xxx.."/> <ex:person.name rdf:parseType="Resource"> <ex:given>Jonathan</ex:given> <ex:family>Borden</ex:family> </ex:person.name> </rdf:Description> and if <ex:ssn> is defined as a daml:UniqueProperty then an inferencing engine _can_ draw conclusions about two such descriptions referring to the same person. So for the vast majority of abstract resources (i.e. things that are not documents on the web), it is best to refer to them by daml:UniqueProperty's On the other hand, I am not sure we need to burden our inferencing engines with parsing each and every URIref they come across in an attempt to assign specific classes to individuals. Jonathan
Received on Wednesday, 20 March 2002 09:14:00 UTC