- From: Pat Hayes <phayes@ihmc.us>
- Date: Sat, 29 Sep 2007 23:59:30 -0500
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: "Chimezie Ogbuji" <chimezie@gmail.com>, www-tag@w3.org
>On 29 Sep 2007, at 01:13, Pat Hayes wrote: >>If we temporarily ignore http-Range-14, then >>there is no connection at all between what RDF >>means by "denote" and what all other W3C or >>IETF specs mean by "identify". > >Let's be accurate, Pat. There is no connection >at all between what *rdf-mt* means by ³denote², >and what all other W3C or IETF specs -- >including other parts of RDF -- mean by >³denote², ³identify², ³indicate², and ³mean². The model theory of RDF isn't a 'part" of RDF. It is the (only official) specification of the meaning of RDF. The RDF semantics document is normative. The words cited mean the same thing throughout the RDF specification documents. And "denote" means there what it means throughout all of logic and linguistics, and has done for almost a century. I don't think other W3C or IETF specs (except OWL) even use the word. >The border between the Web and that weird >parallel URI universe isn't between RDF and the >rest of W3C/IETF. It's between rdf-mt and the >rest of the world. Without its semantics, RDF is just a notation for graphs represented in XML. It uses URIs to denote things, and that is ALL it uses them for (with a few borderline exceptions). The same applies to RDFS and OWL and will apply to the SWeb Rules language. >There are many examples throughout the various >RDF specs that make the intention quite clear: >RDF statements about ><http://www.example.org/index.html> are intended >to be statements about that which is identified >(in the RFC sense) by that URI -- the web page. Yes, that was (and is) a reasonable assumption, and I have no quarrel with it. (The RDF semantics does not stipulate this for two reasons: it is not part of the RDF design as such; and at the time the RDF spec was being written, this had not in fact been universally agreed, although it was widely understood informally to be a de facto convention.) My point has been only to get the terminology clear. These two notions, denotation and 'identifies', are different notions. I agree it makes sense to stipulate that for cases where 'identification' succeeds, that they should be understood to coincide: but that does not make them the same notion. >>As far as RDF semantics is concerned, URIs are >>just blank names with no associated structure >>or meaning. > >I assume by ³RDF semantics² you mean the rdf-mt document. Yes, as that is the title of that document. >Sure, rdf-mt takes the syntax of URIs from RFC 2396 but ditches the semantics. There are no semantics for URIs given in RTFC 2396. I read it very carefully, many times, looking for some. >This is one of the gaping holes left by the WG. > >I do understand why the was made -- a coherent >account of reference on the Web was perhaps >impossible prior to httpRange-14. But that >account is now possible, and the hole can -- and >ought to -- be filled, by the semantic extension >alluded to in [1]. We filled this in the CL design a couple of years ago. The ISO CL documents have a complete semantic specification for this. Its similar to the idea we used in the 'named graph' proposal. One has to assume that 'network identifiers', a subclass of logical names, are somehow associated with a unique (in this case) CL text, call this text(name). Then the semantic condition is that in any interpretation I, I(name)=text(name) whenever name is a network identifier. This makes identifiers denote what they identify. This is of course very simple to state, but it does need to be stated. (We actually made it a bit more complicated to handle logical equality properly, since it is possible to have two different copies of the exact same text.) >Don't give me any of that ³It's that way by design² crap. > >>>There is a school of thought that wants to see >>>URI-space as a blank slate for the purposes of >>>RDF, completely disconnected from the role of >>>URIs on the Web. Personally, I have trouble >>>seeing the advantage of this view. If you want >>>to operate in a universe parallel to the Web, >>>then why use URIs in the first place? Why not >>>simply use KIF or CL? >> >>There are reasons, connected with the global >>uniqueness of URIs. But I tend to agree about >>CL (which can use URIs as names, if one wishes >>to.) >> >>>(Although, in defense of the 3parallel >>>universe2 school, this view is legitimized by >>>a passage in rdf-mt [2], which, it appears, >>>directly contradicts rdf-concepts [1].) >> >>I don't think it does. Where do you see the contradiction arising? > >If you take the position that ³denote² in rdf-mt >means something different from ³identify² in >rdf-concepts or rdf-primer, then there is of >course no contradiction. I call that the ³RDF >model theory is irrelevant to the Web² position. They don't mean the same thing, and there is still no contradiction between the RDF semantics and concepts documents. The section you cite, section 7 on fragIDs, is not normative (unlike the model theory) and is consistent with the semantics; though it does, as it says, go slightly beyond it. It was, as I recall, an attempt by the editors to precisely state what all of us had begun to realize was a widely accepted convention for interpreting URIs, but had not at that time been drawn clearly enough to be uncontroversial: what Dan C calls the hash convention. >I'd much rather like to know what an extension >of the RDF semantics that takes the Web into >account would look like. It would require that someone give a clear, formal specification of what a URI 'identifies', and then it would stipulate that I(uri)=identifiedBy(uri) for any URI and any interpretation I. I havn't yet seen a precise specification of what a URI 'identifies', however. For example, if http://ex.ample/someRDF is an RDF/XML document, does the URI denote the textual document? The XML structure? The RDF graph? We decided to punt on issues like this, but they need to be answered. The CL spec is quite precise about this, since 'text' is a grammatical terminal in the syntax. Pat > >Richard > >[1] http://www.w3.org/TR/rdf-mt/#urisandlit > >> >>Pat >> >>> >>>>>No, you are wrong. >>>>>RFC 3986 says that the "nature" of <doc#term> is >>>>>determined by the media type of <doc>, governed by the RFC that has >>>>>registered that media type. The registration for HTML says that >>>>>fragments identify parts of the HTML document; >>>> >>>>Yes, I gathered this from Dan's follow-up response about the HTML RFC >>>>being the source of the 'problem'. Still, the ambiguity you are >>>>speaking about is between two completely orthogonal mechanisms for >>>>reference ("identification" versus denotation). >>>> >>>>Frankly (and this has been my perpetual theme), if there is serious >>>>concern about ambiguity, then a language well-equipped to handle >>>>ambiguity should be used. >>> >>>I do not believe that such a language can resolve the ambiguity. >>> >>>Quoting RFC 3986: >>> >>>3If the primary resource has multiple >>>representations, as is often the case for >>>resources whose representation is selected >>>based on attributes of the retrieval request >>>(a.k.a., content negotiation), then whatever >>>is identified by the fragment should be >>>consistent across all of those >>>representations.2 >>> >>>Combining a text/html representation with an >>>application/rdf+xml representation makes it >>>hard to achieve this consistency, unless >>>additional webarch trickery is used (303). >>> >>>The ambiguity arises on the webarch level, and can only be resolved there. >>> >>>Yours, >>>Richard >>> >>>[1] http://www.w3.org/TR/rdf-concepts/#section-fragID >>>[2] http://www.w3.org/TR/rdf-mt/#urisandlit >>> >>>>A vacuous notion of "identification" is >>>>simply not sufficient. >>>> >>>>>the registration for >>>>>RDF says that fragments can identify things outside of the document. >>>>>Thus the ambiguity. >>>> >>>>See above. >>>> >>>> -- Chimezie >> >> >>-- >>--------------------------------------------------------------------- >>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 -- --------------------------------------------------------------------- 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 Sunday, 30 September 2007 05:00:03 UTC