Re: around the table on datatypes [ was: Re: datatyping draft 3 (for telecon)]

>On 2002-02-19 22:41, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:
>
>>>  On 2002-02-19 1:34, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:
>
>>>  We don't need (and should avoid) any explicit statements about
>>>  the range of a datatype property. It should be understood (and
>>>  mandated) from the MT or other specese that the implicit range
>>>  of a datatype property is the lexical space of the property
>>>  and the implicit domain of a datatype property is the value space
>>>  of the property.
>>
>>  Sure to the last sentence, and that's just what I proposed. But Dan C
>>  *wants* to be able to make assertions about that lexical space,
>>  right? So why would we want to prevent him doing so?
>
>I never suggested preventing him. In fact, my comments were
>made with the goal of enabling him to do so.
>
>
>>>  This works in conjunction with the interpretation of rdfs:drange as
>>>  being the union of the lexical space and value space
>>
>>  That interpretation doesn't make sense to me. What use is having a
>>  class consisting of all the strings and all the values? Theres almost
>>  nothing useful to say about it, and it is a *weaker* constraint than
>>  the one you would get by using simple rdfs:range, so how can it
>>  possibly do any datatyping? .
>
>The very point is that it the weaker constraint, a constraint which
>applies to the values of properties. It simply says that some property
>can have either a member of the value space with attached lexical form(s)
>or a single member of the lexical space -- but in either case it is crystal
>clear which value is identified (even if the value has no explicit
>denotation in the graph).

Its not clear to me at all, and I see no way to state it as a 
coherent semantic condition. If we could do this, datatyping would 
have been a trivial exercise from the beginning.

>
>A datatype *is* both values and lexical forms, and the union range
>constraint simply constrains a property value to be some valid
>representation of a value based on the context of that datatype.

Well, it requires us to CHANGE it when the context is enlarged, ie to 
have a nonmonotonic logic, is one problem.

>
>The only significant difference in such a scenario between the inline
>idiom and the bNode idioms is whether the value itself has explicit
>denotation in the graph -- but the datatyping interpretation that
>is relevant to some application is all the same.
>
>>>  -- and using
>>>  rdfs:lrange to constrain a property to members of the value space.
>>>  It's clean, generic, explicit, and says exactly what we mean to say.
>>>
>>>  C.f.
>>>
>>>  http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0469.html
>>
>>  No, that doesn't work. What you want is a kind of 'switched union'
>>  where in one context it means one thing and in a different context it
>>  means something else. BUt a class union is just a union; the members
>>  are all just mixed together, and theres no way to choose which you
>>  get in what circumstances.
>
>Ahhh, but in this case, there is. Because it is clear from the graph
>syntax which is which. Crystal clear.
>
>If the property value is a literal, you have a lexical form.
>
>If the property value is a bNode, you have a value.

But in some cases, the values can be lexical forms; so this is not 
well-defined, in general.

>And you can also constrain the property values to one or the other
>by adding additional range constraints for rdfs:Literal and
>rdfs:Resource,

No, that doesn't work. rdfs:Resource is everything, so intersecting 
with it doesn't select at all, and rdfs:Literal is literal values, 
but bnodes can denote literal values just as literals can (in fact, 
if they couldn't, then rdfs:dlex would be meaningless.)

>because the intersection of ddd.(lex U val) and
>rdfs:Literal is ddd.lex and the intersection of ddd.(lex U val)
>and rdfs:Resource is ddd.val.
>
>>  For example, the lexical forms would be
>>  potential values when the doublet idiom was used.
>
>No, because it is defined that the range of rdfs:dlex or a datatype
>property is a lexical space, not the entire datatype.
>
>The union treatment is restricted to the interpretation
>of rdfs:drange, and you wouldn't use rdfs:drange to define
>any range of either rdfs:dlex or a datatype property because
>that is overridden by the fixed range of those properties
>to lexical spaces.
>
>>  But in any case, we rejected the 'in-line' idiom, with no value node,
>>  right? We don't WANT that to be datatype-sensitive.
>
>I'm not so sure. I do agree that we gave up on trying to
>make datatyping work but that was before the idea of
>the union range interpretation.
>
>We don't want to preclude use of the inline idiom without
>datatyping, but that is not necessarily the same as precluding
>its use with datatyping.

The issue isn't precluding, but the fact that the meaning *changes* 
when you remove the datatyping.

>
>And alot of folks I think have been thinking that statements
>expressed using the inline idiom in conjunction with some
>kind of range constraint should mean *something* insofar
>as datatyping is concerned.

Well, I guess my reaction used to be to take this seriously, and now 
my reaction is to say that they were overconfident, and tough luck. 
Its not as though changing

xxx yyy "zzz" .

into
xxx yyy <gensym> .
<gensym> rdfs:dlex "zzz" .

is really all that hard. I think it is one line in emacs, for example.

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 Wednesday, 20 February 2002 13:48:06 UTC