- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Mon, 15 Apr 2002 16:17:50 -0400
- To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
- Cc: w3c-rdfcore-wg@w3.org
>Patrick: >> But it seems that no'one (myself included) feels that the >> answer is 'yes' (apart from perhaps Jeremy, though he has >> not responded to this question directly) so I'll drop it. > >Whilst it is good of you to keep thinking of me, I have decided that I am >too far from the group consensus to contribute positively to the process. > >I have lost quite what the "question" refered to above was, but it seems >that the e-mail has settled on a rational point (which I disagree with). > >In some contexts the literal string "25" in the model theory denotes the >literal string "25" but "according to our shared understanding" there is a >corresponding value of 25. The 25 does not occur in the model theory, but >the application is expected to use it. > >Personally I detect doublethink. If the specification indicates that the >application should use 25 when it receives "25" That might be doublethink, but that isnt a correct conclusion. There isnt enough in this graph to insist that the application SHOULD use 25, only that it COULD use 25, if it knew enough about the 'context' to know that strings were being used here to indicate their values. But it couldnt know that from the RDF alone, since the RDF graph is consistent with other possibilities (eg that literals really do mean numerals rather than numbers). The MT stops just where the RDF stops: it goes that far and no further. Some RDF customers don't want to go any further, it seems (eg Dublin Core). >then wherever the official >line at which the model theory stops there is an implicit and >ill-articulated extended conceptual model which has the value 25 in it. It is UNarticulated because it depends on unarticulated content, ie something about the 'context' that isn't represented in the RDF graph. But the MT does not rule it out; it just doesn't aspire to describe it. >That >is the conceptual model that the specifications expect the application >writer to use (and document authors ...). My earlier argument that the >datatyping proposal was non-monotonic is refuted up to the model theory. >This is from the clarity that there is only "25" and not 25. But the >argument still stands as far as the conceptual model goes. > >It seems that the clarity of this thread that one idiom delivers In order to say this we would need to know what 'delivers' means. It is quite possible for the RDF graph to in a sense 'deliver' enough information to enable some engine to determine that a value (eg 25) is in some broad sense relevant, even though there is nothing in the graph which actually denotes or names that value. I don't see any problem in this situation: the same could be said about RDF without datatyping, if the engine to which the RDF is delivered happens to know enough about the meaning of some uriref and its intended meaning to enable it to draw some extra conclusion, more than is explictly represented in the RDF graph itself. There is no way to legislate against such a situation, even if we wanted to do so (and I suggest that we do not want to, in any case.) I dont think this has anything to do with the local/global datatyping issue as it has been discussed previously. > 25 whereas >the other delivers "25" should be made clear in the document I think that this is clear: each idiom has nodes denoting things unambiguously (literals denoting strings and sometimes bnodes denoting values) and it also has unambiguous wellformedness constraints. There is no ambiguity that I can see. >, and an >explicit admission that the disideratum of interoperability between the >global and local type mechanism has not been met. I disagree, see above. The local and global (ie range-based) datatyping machinery all interoperate. Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
Received on Monday, 15 April 2002 16:17:53 UTC