Re: The range of the HTTP dereference function

----- Original Message -----
From: "Jonathan Borden" <jonathan@openhealth.org>
To: "Tim Berners-Lee" <timbl@w3.org>
Cc: <danc@w3.org>; "'www-tag'" <www-tag@w3.org>
Sent: Wednesday, March 20, 2002 9:10 AM
Subject: 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?


No.   Look at your argument.

 1. "Tim suggests one can deduce things from the fact that a URI
  starts with http: and has no "#"."
 2. "This would allow one to write this really ugly daml code."
 3. "It would be awful if alll inference engines had to be use that code".

I cry 'foul!"

1. The abouteachprefix does not work for this, as it does
not look only at the document URI.  So the code is wrong.
2. Inference engines wouldn't *have* to use the rule anyway.

> >
> > - 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.


You might, in an RDF database, only know tings about
individual URIs.

But the telnet spec and the
URI spec which explains what a telnet: URI refers to
makes it clearthat it is a connection port which
is referred to, which is not something which
can be rendered.  It is something which can be
connected to.  You don't have to be able to write that axiom
in daml.

> ...
>
> >
> > 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.

Mine handles something which does do it. ;-)
But I am not forcing you to.

{:x log:uri [ string:startsWith "mailto:"]} log:implies { :x a
contact:Mailbox}.


(Note the level-breaker log:URI which relates a resource
to the string used to identify it.  Not kosher DAML.)

The internet RFCs tell you what you can do to a mailbox.
Mailbox is the domain of things like smtp:RCP and rfc822:to.
You can send an email message to, form or Cc one.  You can't render one.

One important leson here is that *RDF users inhabit the same web
as everyone else*.  RDF users's cannot use
telnet://example.com/  to refer to a car, because there is a spec
which says it is a telnet port.
And while you can relate a telnet port to a car
 <telnet://example.com/>  log:serverLocation :myCar.
you can't say the telnet port is a car.  The classes of telnet
ports and of cars are distinct.

URIs are universal identifiers. Each one identifies soemthing
(vague or abstract or concrete or specifci or whatever)
but identifies the saem thing in any context. That is the architectural
point.  This is where you get the reuse.

> > 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?

I am NOT talking about URIs in general.

I am just drawing infromation from the HTTP spec.

I could alternatively *try* to interpret the HTTP spec so that the
URI identifies a car.  But then how would I represent, when
the metadata came back about the thing, whether the creatorand
expiry date were those of the car or something describing the car?
HTTP could be extended to make that distinction, but it hasn't yet.
And it is pretty powerful in implementing a web of information
objects. And with RDF, those information objects can describe,
and give URIreferences to, anything at all.
But it is wise to use a hash or you get an clash when you try to
describe in RDFwhat you learned in HTTP.

You ca't learn this from RDF alone.  You have to model HTTP in RDF
and then you see the problem.  One doesn't do this in
"normal" RDF processing.  Just like in "normal" architecturally
pure web browsing you never know the URI of the document
you are reading.  You don't break levels.  Except when you need to.

> [...]
>
> >
> > 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>


Sometimes, sometimes not:

> <rdf:Description rdf:id="jb"> <!-- note the 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

(You mean "daml:Unambiguous", I think)
The URI has the advantage that everyone knows that it is
unambiguous from the get-go, and the more detialed properties of different
URI schemes are well-known and a rich variety is available.
You can use uuid; for example, mid:s, and so on.
http:.*#.*  URIs have the advantage that a machine or aperson
can look them up.  This is very valuable.  This is web architecture.
Identify things with URIs.  Use the URI infrstructure.

It also has the advantage that all web applications share this
particular unambiguous identifier scheme.
When you use anotehr one like SSNs, you take on
defining its properties and then promoting its global
use for coreference by different applications.
The whole point about the web is that you leverage off
all the folks who are indepedently doing that for URIs.

> 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.

Same false argument.  There are some axioms which come from
the lower layers and you don't have to use them.
However, is is often useful.

Tim BL

> Jonathan
>

Received on Wednesday, 20 March 2002 18:44:55 UTC