RE: Back to HTTP semantics

Hello Pat,

<snip/>

> >>
> >> I don't read them as making any such link. They are simply references
> >> to establish, in the usual way of references in written technical
> >> prose, what certain terms of art are intended to mean. So the RFC2369
> >> reference in RDFMT establishes, normatively, that when the body prose
> >> of RDFMT uses the phrase "URI", it means by that what RFC2369 means  
> >> by it, and not, say, to refer to the University of Rhode Island. BUt that
> >> does not in itself establish the kind of link that you imply here,
> >> which has to do with RDFMT treating URIs as names which refer in some
> >> way established or influenced by RFC2369. In fact, RDFMT explicilty
> >> denies this, in its own normative prose. As far as RDF semantics is
> >> concerned, apart from  one or two corner cases (reification and
> >> seeAlso), the Web could not exist at all and nothing would be
> >> different.
> >
> > Fair enough... I won't argue about this, though I would say that the  
> > meme that RDF interpretration of URI are constrained by what might  
> > be called the Web natural interpretation is not original to me.
> 
> I understand. The RDFWG was of course aware of it and it came up  
> explicitly in the OWL debates under the rubric of "social meaning". It  
> was probably the most contentious issue we faced, so much so that we  
> decided to formally postpone it: but I was on the side of those who  
> wanted to give some guidance (in can't be more than that) in the spec  
> itself. But what I was reacting to in this thread was your  claim that  
> the normative references **themselves** address this possible link of  
> meaning. They don't.

Yes... I know, I was perhaps trying to stretch things a little too far. FWIW I remain intrigued about quite what is implied by a reference that is normative - how much of its 'surrounding' world it pulls in and quite how durable it is in the face of change - eg. RFC 2396 -> RFC 3986.

> > Whilst I can understand and appreciate the denial that you mention  
> > in RDFMT with respect to the formalism presented there in - leaving  
> > interpretation unconstrained by the web itself - I think there are  
> > many who see interpretation implicitly constrained in that way when  
> > one joins the logical system RDF with the pragmatics of the web.
> 
> Yes, of course, but the point is that there isnt (yet) anything  
> normative said about any such joining. Some folk feel that, as a  
> matter of principle, there should not be. I disagree, but the issue is  
> extremely contentious. Which is why I tend to get anal at suggestions  
> that the RDF MT implies things about it simply by referring 
> to RFC2369.

Interesting, I suppose that I had taken the social meaning debate to be more about the legal standing of a what a author might have said by incanting a given set of triples and whether they could be held to account for it in a court. I can see that the grounding of URIs is significant to such a discussion - but at least at the time I'd not twigged that acted at the intersection of RDF/Web interpretations of URI.
> 
> > Eg. If in RDF one were to use http://www.w3.org as a reference to my  
> > left foot, there would be an inconsistency in the total system even  
> > that were not so from the RDF interpretation alone.
> 
> Well, you need to say what you mean by 'inconsistency' here. 

I mean something along the lines of saying that organisations and left-feet are disjoint - but I'll concede that the inuition that http://www.w3.org names either an organisation or its 'homepage' on the web (and I'll confess to not knowing which - but suspecting the latter) is a human intuition that I could not defend logically.
 
> Apparently you aren't using the term in its logical sense. 
> What sense  are you using it in? You seem to be pointing along a road to a new  
> research area, which should probably be called 'web semantics' or (I prefer) 'blogic'. 
> But this requires some new science that hasn't been done yet.

Interesting... I think that you're serious - in which case you'll probably have to ask me more questions. But there is a chance that you're having some fun with me :-)

> >>> Without such normative references I'd agree that there is nothing to
> >>> drive such a conclusion... but with them... Roughly speaking I'd
> >>> regard the normative references as constrainting the RDF
> >>> intepretation of URIs with the 'normal' web interpretation of URIs
> >>> (at least for those that have the latter).
> >>
> >> Those references don't constrain the RDF interpretation of URIs in any
> >> way at all. Not a smidgeon. In any case, RFC2369 simply does not speak
> >> of interpretations of URIs, or indeed of any semantic issues.
> >
> > :-) - RFC2396 and friends and various social registration processes  
> > set up a social system by which URIs become bound to things.
> 
> Bound to, but not referring to. And not many kinds of thing.

It is funny how instinctively we/I find myself avoiding the use of some words in some places - I came close to saying "...come to refer..." but, I also liked what I used to think of as more significant difference between URIs and URIRefs: the former in as sense being a things own sense of self identity (however obtained - baptism or whatever) and the latter being a reference made *using* a URI. Laterly, however they have simply been taken as expressing different syntactic constraints. Anyway, "bound to" does go with the former rather than the latter notion.

> 
> > But... I guess that comes down to what Jonathan called "reading  
> > between the lines".
> >
> > Many of the early URI scheme specifications describe that binding in  
> > very operationalised terms (the FTP URI scheme is as good example -  
> > see http://tools.ietf.org/html/rfc1738, section 3.2 and  
> > subsections). In the light of our other exchanges I think that FTP  
> > URI would be seen as designating a 'container' rather than its  
> > 'content'.
> 
> And I don't think it says much about how URIs can refer to people,  
> relationships, etc. etc.

Yes... It says nothing about that - neither really does the HTTP scheme spec embedded in 2616 which, IIRC, has as similar operationalised description that speaks in terms of connecting to ports on computers and the exchanges that ensue. 

> 
> Pat

Stuart
--

Received on Monday, 15 June 2009 18:28:53 UTC