- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Thu, 18 Apr 2002 16:17:47 -0500
- To: Patrick Stickler <patrick.stickler@nokia.com>
- Cc: w3c-rdfcore-wg@w3.org
>On 2002-04-18 1:02, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote: > > >>> The MT, IMO, stops short of the line. It gets 95% there and fails >>> to actually say how to get to the finish. It fails to capture >>> the ultimate "why" of the idioms. >> >> Patrick, you want to ALTER the MT, clearly. > >I actually don't think so. I just consider it acceptable >to interpret the present MT as all three of the datatyping >idioms identifying a datatype value, even if the inline >idiom does not provide explicit denotation for that value >in the graph. Of course a literal and a datatype 'identify' a datatype value in some sense, just as <3, inc> identifies 4. But we don't even need any RDF to tell us that. The issue here is to explain what datatyped RDF means, and if someone were to interpret this explanation as saying that a 'datatyped literal' means a datatype value (and how else could they be expected to interpret it?), then that seriously misrepresents the MT. The current MT clearly does not say that, in fact it says something that is clearly inconsistent with that. Thats why Im making all the fuss here. That would be a very different MT, and would have lots of other implications about tidiness and literal subjects and so on, and wouldn't support inferences that Dan C wants supported, and wouldn't sanction uses that Graham tells us the DCore want to have sanctioned, and so on. >What the users of RDF Datatyping need, IMO, is the ability >to express and communicate datatype values. If they can't >do that, then something is broken. They CAN do that, eg by using a dataype property or dlex. But they can also do other things: they arent OBLIGED to do that. And they can't do that using the inline idiom. If all the idioms had the same meaning, we wouldnt need them all. > >I don't think the MT needs to be changed. I actually think >we are in very violent agreement, and are just bandying over >words and how best to explain what the MT says to folks who >will not or cannot read the MT. > >It is your interpretation of the inline idiom as only constraining >literals to the lexical space and not actually identifying a >datatype value that I consider not "going all the way". It is important that it does not go all the way, because some users do not want to go all that way. They are passionately agnostic about values, and care only about lexical forms. They are devoted to text and want to be systematically sloppy about values: they want to freely mix strings and numbers and call them all 'age'. > >> The trouble with your >> position, however, is that the place you want to get to, that last >> 5%, is a place we have already surveyed, and we found problems with >> it. > >We found problems with trying to have all three idioms denote >the datatype value. But by agreeing that the inline idiom does >not in fact denote the value, even if it does unambiguously >identify the value, works just fine. It has all the appeal of theft over honest toil: it says there is a precise specification and also that we are cheerfully ignoring it. What is to stop someone totally ignoring the entire MT and saying that is OK because he is talking about what the RDF 'identifies', not what it denotes?Since we havn't defined 'identifies', who is to say he is wrong? > >> Some of our customers definitely do not want to be located there. >> They WANT to be able to be sloppy about datatype values, mix talk of >> strings with talk of integers, etc., and still they want to invoke >> lexical form checking using datatypes. > >I understood the concerns/desires differently. I heard that they >wanted to be able to use the inline idiom and leave the interpretation >entirely to the application, or at most, indicate which datatypes >should apply to the interpretation of which literal values. > >But perhaps you're right, and I've misunderstood... Well, check this out with Graham. > >>> If you want the MT to be the only level addressed in the RDF >>> Datatyping specification, then could we consider giving datatyped > >> literal pairings a formal definition in the MT. They need no >>> explicit denotation in the graph, no more so than the datatype >>> mappings do. They only need definition. Eh? >>> >> >> I don't see how this will help, or even what it really means. > >Forget the pairings. They are only a conceptual convenience that >captures what I consider to be the key mechanism of RDF datatyping. > >What I ultimately want to see from the MT (and thought it provided) >is that each and every one of the datatyping idioms (when complete) >define/identify/provide a specific datatype value. None of those words have a precise definition. Ask rather what the MT says the various parts of the graph denote, and you will get exact answers. > >>... The various idioms >> provide all the precision (or lack of it) that anyone seems to need, > >I consider all of the idioms to be equally precise, though some are >more explicit than others. > >> If you want to be sloppy, you can be; > >The only way to be sloppy, IMO, is to use an implicit idiom without >any rdfd:datatype assertion, i.e. for their to be no datatype associated >with the literal to tell the application what the intended interpretation >is. If you specify the datatype, it is fully precise. The datatype is, but the denotations of different parts of different graphs need not be. > >Not having a bnode to denote the value is not, IMO, being sloppy. What I meant is that if you (the user) are interested in lexical checking but want to be deliberately underspecified concerning datatype values, you have that option. That is what the drange datatyping does, or whatever its called now: it works with both the inline idiom and the dlex idiom, and does the same *lexical* check in both cases, even though the ranges are presumably different (or maybe the range is a union)(or maybe you just dont care about the range.) 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 Thursday, 18 April 2002 17:18:01 UTC