W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2002

Re: simplified datatyping proposal

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Fri, 22 Feb 2002 12:15:20 -0600
Message-Id: <p05101423b89c351f8a8f@[]>
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: w3c-rdfcore-wg@w3.org
>On 2002-02-22 1:16, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:
>>>  On 2002-02-20 19:41, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:
>>>>   Can I ask y'all for some clarification. Do people want to support
>>>>   BOTH in-line and bnode forms at the same time? That is, should the
>>>>   following mean the same thing and be affected in the same way by a
>>>>   drange assertion on ex:age ??:
>>>>   (1)
>>>>   person:Jenny ex:age "10" .
>>>>   (2)
>>>>   person:Jenny ex:age _:x .
>>>>   _:x rdfs:dlex "10" .
>>>  Yes.
>>>>   As things are at present, (1) means that Jenny's age is a character
>>>>   string, no matter what else you say, whereas (2) says her age is
>>>>   something that can be described by a character string, so can be
>>>>   modified by other datatyping. We can change this, as I say, but only
>>>>   at a cost.
>>>  It depends on how much of the datatyping interpretation is
>>>  intended to be captured in the graph.
>>>  If we agree that a literal denotes a literal always, and at
>>>  some level above the graph, we may determine based on the
>>>  combination of a literal and a datatype that the literal is
>>>  string equal with a lexical form that denotes a value, great.
>>>  But we don't then have to say that the literal node *denotes*
>>>  the value. It still denotes the literal.
>>>  Datatyping interpretation can happen above the graph. The
>>>  knowledgeg necessary to make those interpretations consistently
>>>  and unambiguously is captured in the graph. And in the graph,
>>>  a literal always denotes a literal.
>>>  Where is the problem?
>>  The problem for me is that none of this makes the any sense at all. I
>>  have no idea what you are talking about.
>It wouldn't be the first time ;-) and it's surely my inablity to
>explain it clearly enough in some language we both understand...
>>  1. If a literal always denotes itself, then datatyping information in
>>  the graph (in particular, about ranges expressed using rdfs:drange
>>  for example) cannot influence the meaning or truthvalues of any
>>  'in-line' use. That is how my first 'simplified' proposal worked, but
>>  I gather you did not like that.
>>  (To emphasize: if "15" denotes "15", then
>>  Jenny ex:age "15" .
>>  says that Jenny's ex:age is "15". It does not, cannot, and never will
>>  say that Jenny's ex:age is 15, no matter what you do above, inside or
>>  underneath the graph. End of story; nothing more to be said; nothing
>>  can change it (short of re-writing the entire RDF MT from the ground
>>  up.). )
>Then we're agreed. Insofar as the RDF MT is concerned, it cannot
>mean 15. That is exactly how it should be -- since it can never
>mean 15 in the graph

That phrase 'mean 15 in the graph' doesn't quite make sense to me. 
The graph is just syntax: what it means depends on how it is 
interpreted. Are you saying here that "15" cannot mean 15 in ANY 
interpretation? There is no way to possibly make the RDF literal "15" 
mean the number 15 in any way, under any circumstances, by adding any 
kind of knowledge.

Just wanted to make sure.

>  because the knowledge needed to make that
>value determination is extra-RDF knowledge, such as the actual
>definition of the mappings of xsd:integer, which are *not*
>expressed in the graph nor have explicit RDF MT interpretation.
>>  2. I do not know what you mean by a 'level above' the graph, and in
>>  any case that is irrelevant, whatever it means, since we are here
>>  talking about the graph.
>We're talking about the graph, yes, and what the MT interpretation
>of the graph is, yes, and I'm saying that insofar as the MT
>interpretation is concerned, a literal always denotes itself.
>The functional significance of some literal above/outside of
>the MT

What does that mean? The MT describes interpretations of the graph. 
There aren't any other interpretations 'above or outside'. There are 
only interpretations of the graph.

>, serving as a lexical form of some datatype, and
>having a mapping to a specific value of that datatype, is
>defined *outside* of the RDF MT. And that is as it should be,
>since we are not defining our datatypes in RDF, we are only
>associating datatypes with lexical representations of datatype
>values, and needing a clear, consistent interpretation of
>that *PAIRING* and nothing more. Nada. Zip. Just the pairing
>of liteal and datatype. Everything else depends on extra-RDF
>treatment by applications with complete knowledge about the
>specific datatype.
>This has been the core/hear/soul of the TDL concept from
>day one.

Which is probably why I have never understood it. It seems to consist 
only of denials, not of actual content.

>All RDF captures is the pairing.

HOW??? Where in the interpretation of an RDF graph is such a 
'pairing' ?? YOur green hexagons weren't in the graph or in any 
interpretation of the graph, they just kind of arrived out from left 
field. The pairs did all the work, but they weren't anywhere in the 
interpretation. This is just semantic horse feathers.

>Period. And the pairing is
>consistent and explicit for applications that know what to
>do with it, in order to get some actual value.
>Why do folks keep trying to make this so darn'd difficult
>by trying to capture the totality of datatypes in the RDF





And by the way, I havn't been trying to capture the 'totality' of 
datatypes in the MT; that is what I want to avoid doing. The only 
place my MT conditions even mention DTs is by using a *single* 
semantic function L2V, which selects the lexical-to-value mapping of 
a datatype.

And we arent 'making it' difficult: it IS difficult because different 
people all have different idea about what pieces of RDF mean when 
datatypes are around. The confusion doesnt arise from the MT; it 
simply exists , and the MT can't do everything at once. Any one of 
these perfectly rational pictures has a simple MT, but we go round 
and round in circles because WE are confused. Abandoning the MT isn't 
going to make anything *clearer*.

>All we need (all we've ever needed) to capure is the
>pairing of literals to datatypes and give applications
>clear and consistent instructions on how to recognize
>those pairings and which piece of the pairing is the
>lexical form and which piece is the datatype.

Right. Once we get that clear, it is routine to put those rules into 
some MT semantic conditions. But some people want the range to be the 
value space, and some want it to be the lexical space. And it can't 
be both at the same time.

>>  3. I do not know what you mean by the distinction between a string
>>  and a lexical form. Seems to me that lexical forms *are* strings.
>>  (They sure look like strings on the page.)
>A literal is an RDF literal. It is a syntactic element of the graph.
>A lexical form is a member of the lexical space of a datatype. It
>is, if you will, a literal with a purpose, a literal with a consistent
>interpretation within the context of that datatype.

No, it isn't. You have already agreed to that, see above. It has a 
FIXED interpretation.

>The fact that both a literal and a lexical form may be represented
>as strings does not mean they are the same 'thing'.

You still havn't told me what you mean by 'lexical form'.

>>  4. What kind of interpretation happens 'above' the graph? And how can
>>  it make any difference  to  what the graph means?
>noting the correction in

None of that makes any sense to me.  We have a genuine difference of 
agreement, and your proposal seems to be to say 'both'. Thats like 
saying something is red and green and claiming you've settled on a 
color. (Which is fine until you have to buy the paint.)

>Everything under "Interpretation:" corresponds to non-MT, extra-RDF
>application interpretation "above the graph", but based on explicit
>rules or guidelines set forth for the consistent use of datatypes
>in RDF by whatever documentation we produce.

The semantics *IS* the consistent rules or guidelines.

Look, if you don't want to cook, stay out of the kitchen. I can do 
the cooking, just tell me what you want. But don't come in here 
treading on the eggs.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Friday, 22 February 2002 13:15:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:10 UTC