Re: Documents, Cars, Hills, and Valleys

 One of the most telling sentences I've seen in this discussion so far is this:

"Something that is frustrating for me is that people keep talking of the problem as if it
were just some philisophical excercise, without remembering that this
is a real-world problem that is making it difficult for people to
implement systems on top of RDF."

I would like to see some practical examples of what real world problems are caused by the two points of view. If this issue is really so important then I'd like to know what difference it's going to make to anyone or anything other than being able to say "a URI refers to a document, not a car".

I studied Philisophy (with Physics) some time back and there are hundreds of books written about the problem of reference both by linguists and philosophers (e.g. Wittgenstein, Moore, Ayer et al ) - as well as paintings painted ( http://www.rutgers.edu/~sgro/HTML_Documents/pipe.html ). 
I think as computer scientists, we should not get mixed up in these ultimately undecideable philosophical problems except where they interface with practical issues (- or at least we should save that for the dinner parties.) But in order to do that, we need to know what about this is a practical problem and what is just philosophical.




> Joshua Allen wrote,
> > Miles Sabin wrote,
> > > http://news.bbc.co.uk/ refers, not to a document, but to "Todays 
> > > news from the BBC", IOW they "see through" the protocol and the 
> > > document
> >
> > Not true.  Every user that actually is forced to use a URL is quite
> > aware that they are getting "a web page".  This is exactly the 
> > language that people use to talk about what they are doing when they 
> > type a URL into their browser's location bar.  Ask any person off 
> > the street, "if you type in something like http://blah into a web 
> > browser, what do you get back?"  They will tell you "a web page".  
> > Then ask them, "If I type http://www.news.com, do I get back a web 
> > page with the news on it?" they will say "yes".
> 
> OK, this is a straightforward empirical question (ie. we aren't
> likely to resolve this issue without going out and doing a survey, but
> we could do that and get an answer) so in the absence of evidence
> it's really not worth discussing any further. For all that, my
> intuitions run counter to yours. People are used to "seeing through"
> other media (telephones, televisions, telescopes) and I see no
> particular reason (other than comparative unfamiliarity) why the web
> should be any different.
> 
> > Users are not so stupid or mystified as you seem to be implying.
> 
> That wasn't at all what I meant. I think they're _right_ to treat
> http://news.bbc.co.uk as referring to todays news from the BBC. They'd 
> also be right to treat it as referring to an HTML document.
> 
> Here's another analogy. If I show you a photograph of the Eiffel
> Tower and ask you "What's that?", then I think that either of these
> two answers would be acceptable,
> 
> * It's the Eiffel Tower.
> 
> * It's a photograph of the Eiffel Tower.
> 
> because without additional contextual information the identifier I
> used in my question ("that" and pointing) is ambiguous. That
> additional contextual information might or might not be present: if
> we'd been having a conversation about architecture, then the first
> answer would be the most appropriate; OTOH, if we'd been having a
> conversation about the merits of photo-realism in 20th century
> painting, then the second might well be the most appropriate.
> 
> Much the same goes for todays news vs. a document. Except that
> typical users are far more interested in the news than they are in
> HTML, so in all likelihood the implicit context is one which would
> resolve any ambiguity in the URI in favour of the news rather than
> the document.
> 
> > > Insofar as meaning is determined by use this implies that in the
> > > general user community URIs, http: or otherwise, typically don't
> > > identify documents.
> >
> > You are confusing only yourself.  The fact that language can be
> > deconstructed and ambiguities can be artificially introduced is no
> > excuse for abandoning clarity.
> 
> I don't believe that I'm introducing any ambiguity which isn't already
> there. The fact that quasi-formal unambiguous definitions can be 
> introduced at will is no excuse for abandoning realism ;-)
> 
> > > For that matter, what about the XML developer community? As things
> > > stand a namespace URI refers to an abstract (ie. non-retrievable)
> > > resource rather than any particular document. IMO many of the 
> > > problems
> >
> > This is a totally orthogonal issue.
> 
> That's one of the points under discussion. I'm claiming that this is
> precisely the same issue in a different guise, and that thinking
> about it in these terms is helpful.
> 
> > A namespace URI is a unique name, period.  Until you need to make 
> > statements about a namespace or dereference a namespace, then you 
> > don't need something that identifies "the namespace".
> 
> I'm afraid I can't see any way of making these two sentences 
> consistent with each other. If a namespace URI is merely a unique
> identifier (ie. with no implication of there being any abstact
> namespace resource so identified) then there's nothing you could
> possibly make statements about. OTOH, if there is something you could
> make statements about, then a namespace URI isn't merely a unique
> identifier.
> 
> > > we've had with the interpretation of namespace URIs boils down to
> > > trying to square the circle of having a supposedly unambiguous URI
> > > refer simultaneously to two or more distinct resources.
> >
> > No, I disagree.  The namespace URL in an XML doc is not being
> > "interpreted" as referring to any resource.  Maybe *you* think of it
> > that way, but the software just treats it as a unique name.
> 
> Umm ... in namespace processing the software treats it as an 
> identifier of a namespace, surely. That's no more (and no less)
> problematic than software treating a bunch of bits as an integer.
> 
> Cheers,
> 
> 
> Miles
>