RE: [httpRange-14] What do HTTP URIs Identify?

Paul,

> From: Paul Prescod [mailto:paul@prescod.net] 
>
> You can either presume that they have accidentally referred 
> to two different things by the same name or you an presume 
> that they are referring to the same thing and making 
> contradictory assertions about its class and quality. I know 
> how to handle conflicting assertions and useful semantic Web 
> software will also. 
 
Useful semantic web software will be non-monotonic? Ok...


> I could just presume that one of the guys 
> looked at the object and misunderstood what it is (an album 
> or a book) and look around for other evidence one way or the 
> other. Detecting and dealing with contradictions is easy.

It's easy because the isbn form is a well known /scheme/. The scheme
provides a wealth of semantics and importantly it constrains the domain
and range. Here the class of items it names are books and we use it to
show music is disjoint from book. We assume access to such an ontology
and agreement on it between the conflicting parties. That's fine; some
DAML, or even code that embeds the scheme semantics (as web servers
embed http semantics), will do the job.

 
> The standard way to decide is to use an 
> addressing/naming system that we agree is globally 
> unambiguous. "I'm talking about the Michael Jackson with this 
> social security number. Who are you talking about?"

The standard way to decide is not a globally unambiguous naming system.
That should be obvious from what you've just written, you didn't use the
name to decide, more information was involved. A naming system decides
nothing on its own.

 
> If, after using a global identifier, we could *still* be 
> talking about two different guys then the global identifier 
> is useless and should be discarded. The *whole point* of 
> global identifiers like URIs, phone numbers, social security 
> numbers, ISBN numbers is to uniquely identify
> things:

You're saying identifiers, but you're leveraging schemes (or types).


> "The International Standard Book Number (ISBN) is a 10-digit 
> number that uniquely identifies books and book-like products 
> published internationally."

So we need standard naming schemes? Fine, but I thought we didn't want
to generate more schemes. How many should we have? When would we be
finished?

 
> Another analogy: the credit card companies routinely deal with
> contradictions: "I bought that. I didn't buy that." 

That's non-repudiation, not ambiguity. Non-repudiation can be dealt with
through provenance or a transaction history (forms of evidence). A
causal naming system a la Kripke would be fine,  but that's not what the
architecture provides. We don't have a means of correlation (I imagine
this to be a useful part of the "web of trust").

 
> They don't tell merchants: "this credit card number is being 
> used ambiguously. Please figure out which of the two people 
> you are talking to." They say: "This credit card number is 
> generating an unreasonable number of contradictory 
> statements. Please ignore that card from now on."

Of course they don't. Why would they? And again, the set of names (card
numbers) is bound to a well defined type (credit cards accounts). This
is another /scheme/ in action. Plus what you've described requires the
combination of IT systems and a good number of people, which is not
going to be a cost effective approach.

Each time you've used a scheme in combination with a name to
successfully constrain the domain of things a set of names can identify.
There's nothing wrong with this at all; it's practical and makes the
problems tractable. But I could reasonably interpret your post as pro
restricting the range of the http: scheme or as a point of departure for
creating new per domain URI schemes. I don't think that's Jonathan's
current position, it's definitely not mine and I suspect it's not what
you'd want either. I'm still confused (what's new :), but I have feel
now for practical avenues, that don't require endless threads on naming.

I observe if there were means of querying the naming authority itself
for more information in a cost effective manner, we'd have a solution
that tees up with REST principles.

hoping-to-reach-a-higher-level-of-confusion-soon'ldy,
Bill de hÓra

Received on Saturday, 3 August 2002 10:31:21 UTC