RE: datatypes and MT

>  > >The literal denotes a value in a value space, just as any lexical
>>  >form in a lexical space of a data type denotes a value in the
>>  >value space of the data type.
>>  >
>>  >I thought that was crystal clear.
>>
>>  No, it is not clear. In fact, this is a way of stating the issue
>>  under discussion: HOW should denotation in RDF be related to the
>>  lexical-to-value space mapping of a datatype? We have several
>>  possible answers on the table now. In some of the proposals, literals
>  > denote strings.
.....

>To say that a literal "10" represents the string '10'
>which represents a lexical form is about like saying
>"The name of myself is Patrick"
>
>Maybe in some contexts you'd like to say such things,
>but that's not the norm.
>
>If you want to say a literal is a string, say it, i.e.
>
>    xxx --someValue--> "10" --rdf:type--> xsd:string .
>
>I.e., the literal represents a lexical form for
>a data type, and the interpretation of that lexical
>form is up to the application.
>
>Eh?

Well, I am of your mind on this issue; but my point was only that 
there are those who differ, and that the alternatives need to be 
decided between, so that right now we should be more in the mode of 
considering the options, than of declaring one of them to be 
obviously correct. Though I guess the latter is one way to vote on 
the former :-)

>  > >Defining in RDF in any way that "10" maps to 'ten' within
>>  >the scope of the data type xsd:integer is interpretation of
>>  >the literal, and should not be done by RDF; at least not as
>>  >part of the core model.
>>
>>  What do you mean by 'done by RDF'? Such a condition can certainly
>>  form part of a semantics for RDF, but of course that is not to say
>>  that it directly corresponds to any kind of process that would be set
>>  in motion by any kind of RDF processor or engine.
>
>By 'done by RDF' I meant that in order for RDF to actually
>define a mapping from lexical form to value, it has to have
>some built-in canonical representation of that value, which
>I don't think should be done.

Right, I agree that should not be done. But the mapping can be used 
in defining the semantic conditions without involving any 
*representation* of the value.

>Unless RDF has built-in data types, any mapping expressed in
>RDF is just a mapping from one lexical space to another,
>such as from a non-canonical lexical space to a canonical
>lexical space, which does not map to any *values*, per se,
>since RDF can only deal with lexical forms.
>
>If the lexical space and the value space happen to be
>a perfect intersection, then that is a coincidental
>property of the data type, not the result of RDF
>mapping lexical forms to values.
>
>>  >All that RDF should do is allow one to say that "10" is a lexical
>>  >form corresponding to some value in the value space of the
>>  >data type, not how that mapping occurs or what the mapping is.
>>
>>  But consider an RDF extension like DAML+OIL, which is able to assert
>>  that two values are equal. An inference engine for DAML+OIL might
>>  well need to be able to 'know' that some piece of RDFS has as a
>>  semantic consequence that a literal equals - has the same value as -
>>  another expression. This might for example have important
>>  consequences for a cardinality reasoner.
>
>Sure, but there's a difference between (a) being able to make
>the statement that two lexical forms map to the same value and
>thus can be considered to denote an equal value, and (b) how
>one determines that such an equality relation exists.
>
>The former does not require knowledge about the lexical space
>or value space of the data type, the latter does.
>
>Thus, if a DAML+OIL reasoner wishes to determine if some
>value denoted by a lexical form is 'greater than' some
>other value denoted by another lexical form, it must
>base its determination on relations defined in RDF about
>in terms of those lexical forms and their associated
>data type(s) -- and those statements may be transient
>and asserted by employing a (possibly external) system
>component that 'knows' about those data types and is able
>to assert the necessary relations.

Well, I would like to provide a general-purpose scheme which shows 
how to incorporate a datatyping system into the semantics of RDF , so 
that the resulting language, which might be called 'datatyped RDF' 
has a coherent semantics which respects both RDFS reasoning and any 
consequences that arise from the datatype reasoner. Maybe this would 
be implemented in terms of a protocol between two systems which would 
keep their own internal representations separate from each other; but 
the unified semantics would, I hope, show how they could work 
together coherently so as to respect one another's intended meanings.

>Thus, the reasoning system is providing interpretation
>of those literals (mapping lexical forms to values) and
>based on that interpretation inferring relations (expressable
>in RDF) between values denoted by those literals, but the
>actual mapping from lexical form to the value is not
>expressable in RDF (because RDF has no internal canonical
>representation of values, only a representation of
>lexical forms).

Not *expressible* no (if it were, why would we need the datatyping 
mechanism?); but *useable* from within RDFS (or DAML+OIL, eg), I 
would hope.

.....
>
>If we're going to use notations to express ideas, let's be
>sure that the ideas are actually expressable by the notation.

Amen to that.

.......
>
>>  >The key word above is "determine". RDF does not
>>  >determine the equality of lexical forms, even if
>>  >an RDF statement or construct might assert it.
>>  >
>>  >Just as rdfs:range does not determine the type of a
>>  >value, it just asserts that the value must be of
>>  >a certain type.
>>
>>  But that is what 'determining the value' means, is it not? (What else
>>  could it possibly mean?) I am completely unable to understand the
>>  distinction you are making here. Can you explain it in semantic terms?
>
>Probably not. Though I think I may have answered this question
>above. To recap, in order for a mapping from lexical form to value
>to be defined in RDF, RDF must be able to provide a canonical
>representation for each value, for each data type, and I don't
>see that as practical.

Ah, OK. We were miscommunicating over what 'determine' means, I 
think. I took it to mean, describe sufficiently closely to fix a 
single meaning; you took it mean, define explicitly. To me, the RDF 
(using the S style):

aaa eg:prop _:x .
_:x xsd:integer "10" .

already 'determines' that the value of _:x is ten. No need for the 
literal to be canonical; it just has to be enough to lock down a 
single value under the declared datatype in every possible 
interpretation. If we adopt the semantic conditions appropriate for 
the S style, it does that.
(Those conditions BTW would be that if uuu is any URI denoting a 
datatype mapping d, then
  <x,y> is in IEXT(I(uuu))  iff  d(y)=x.  Notice that the datatype 
mapping goes 'backwards' here, from the object - which would be 
treated as a string - to the subject - its value under the datatype 
mapping.)

>And even RDF did provide a canonical
>representation for each value, that representation would still
>be a lexical form to most computer systems, so the "mapping"
>would simply be between a non-canonical lexical space to a
>canonical lexical space, not really from a lexical space to
>a value space.
>
>Is that any clearer? Sorry that I can't offer you a mathematical
>definition...

I get your point (and agree with it) but think that we were at cross purposes.

Amazing how often a disagreement turns out to be a misunderstanding.

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, 15 November 2001 13:38:49 UTC