Re: The range of the HTTP dereference function

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