Re: article on URIs, is this material that can be used by the SWEO IG?

>Pat Hayes wrote:
>
>>  				 None of this architectural 
>>doodlebugging can ever attach a name to a thing that is not 
>>physically connected to the Internet. Y'all seem to be blind to 
>>this very central fact.
>
>I find the idea of being physically connected to the Internet pretty sketchy.

I don't. In fact its about as concretely checkable as anything can 
be. I give the URI to a browser and click on it. Whatever comes back, 
if anything, comes back from something which is physically connected 
to the Internet. Put another way, it is physically connected if it 
can send and receive packets.

>I'm physically connected to my laptop, via it resting on my lap and 
>touching it. My laptop is connected to my cable modem via some kind 
>of radio waves, which is connected to my phone line via some kind of 
>cable and adaptor box. The word "physically" isn't really helping me 
>here.

Those are all physical. But now suppose what you are looking at is an 
image of a marble bust of Julius Caesar. There is no physical 
connection between you and the marble, or between you and Julius.

>  It's like asking where in the brain consciousness stops and mere 
>physical perception starts. Rathole. Is my phone "physically 
>connected" to the internet 'cos I can sync it via bluetooth thru my 
>laptop?

Yes, while it is being synched.

>etc. Questions without interesting answers. I can't see how they 
>tightly connect to issues of naming.

They don't: but I didn't say 'name', I said "identify". That is the 
TAG's special word for the relationship between URIs and resources, 
and it seems to mean a lot more than just naming. That is what I have 
been complaining about since I first got involved with this issue.

>
>I'd rather couch it as: have the Internet *community* agreed some 
>conventions for naming certain kinds of things, and writing down 
>their agreed namings is a common syntax?

Good question. But I don't really see how the Internet community can 
possibly do this. First, there really isn't such a community in any 
real sense. Second, how can any community establish conventions for 
naming everything that needs to be named? Human societies have not 
established such conventions.

>So maybe the Internet community agree a way of naming countries 
>using ISO country codes, and have a URN-based URI convention for 
>naming them, in a way that is widely used without problem or 
>confusion. That common understanding seems to me more pertinent than 
>whether the named entities are "physically connected" to the 
>Internet.

BUt how else is one going to use the name to "access" the resource, 
than for there to be some kind of causal connection between them? How 
would I access Italy?

>Sure, Italy is, I guess. But why does that matter? How could I check?

Give the URI for Italy to a browser and tell it to dereference the 
URI. Presumably that ought to work, if the URI does indeed identify 
Italy.

>>None of that will help. One can only use names which (are assumed 
>>to) refer, in order to establish the referents of other names. 
>>There is no way out of this circle, no way to 'anchor' or 'ground' 
>>the names in the actual real world, without appealing at some point 
>>to an act of perception. In everyday life, we point to things and 
>>say "that". On the Web, *for information resources*, we rely on 
>>HTTP to go fetch us a "representation" which is so exact a copy 
>>that we are satisfied that we have accessed the original resource. 
>>But the combination of the Web and non-information resources 
>>provides no way to anchor any name in the real world. THERE IS NO 
>>GENERAL WAY TO GIVE A THING A NAME USING INTERNET PROTOCOLS.
>
>That would be a kind of magic. But exchanging descriptions of things 
>that can uniquely pick them out when interpreted in practice...

I agree that is probably the best we can do, ie exchange 
descriptions. But now I return to another theme: descriptions can 
never *uniquely* pick something out. So this way of 'identifying' 
something cannot possibly live up to the standards set by the TAG for 
what URIs are supposed to be able to do. See my slides in defense of 
ambiguity: 
http://www.ibiblio.org/hhalpin/irw2006/presentations/HayesSlides.pdf

>  that seems a fine use for Internet protocols. And embedding those 
>identifying descriptions in Web documents seems somewhat useful too.

It would, if there were any. But there never are: at least, not which 
are adequate for ontological reasoning.

>>>In ontologies I use, I introduce such properties, see here:
>>>http://www.dfki.uni-kl.de/~sauermann/2006/01-pimo-report/pimOntologyLanguageReport.html#ch-IdentificationPimo
>>>
>>>we would need an W3C blessed property like this:
>>>
>>>paul:Rome a pimo:City;
>>>pimo:occurrenceRef http://en.wikipedia.org/wiki/Rome, 
>>><http://www.comune.roma.it/>.
>>
>>Not even the W3C has the power to make names refer. I have the 
>>greatest respect for the W3C, but it is not God.
>
>I think pimo:occurenceRef sounds just like isPrimaryTopicOf in FOAF. 
>It doesn't (from the RDF layer's point of view) declare a name, ... 
>but it is helpful (simply via being an 
>OWL:InverseFunctionalProperty) when publishing and exchanging 
>identifying descriptions.  A consumer of those descriptions in the 
>RDF 1.0 environment has no idea which subsets of a graph are 
>intended as identifying description, ie. playing a role something 
>like a name, and which are just random assertions. But that's 
>livable with I think.

You just gave a LOT away in a short phrase. Descriptions don't 
identify; reference is uncomputable. And I agree this is all livable 
with (after all, we do live with it in everyday life.) But if we have 
to live with this, then a lot, perhaps almost all, of what the TAG 
says about identification is baloney, when applied to the semantic 
web.

>It is useful to be able to mention things and indirectly identify 
>them through reference to documents and services that have more 
>widely known identifiers. One trick amongst many, sure, but a useful 
>tool in the toolkit.

Agreed. And Im all for building the toolkit piece by piece. But in 
order to do so, we have to all agree to completely ignore what the 
TAG says, or we will never get started.

Pat


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Saturday, 2 June 2007 06:15:21 UTC