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

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

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Tue, 19 Feb 2002 14:41:38 -0600
Message-Id: <p05101409b898624f0f5b@[]>
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: w3c-rdfcore-wg@w3.org
>On 2002-02-19 1:34, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:
>>  OK, let me try to fix this.
>>  ...
>>  (What we really want to be able to say is that the range of
>>  otherProperty is a subset of the range of ex:integer, ...
>I'm not sure I follow. What we want to say, in Dan's case, is that
>the range of some property is the lexical space of ex:integer
>(which, from a particular point of view, is of course some kind
>of subset of the "totality" that is ex:integer, leaving out the
>value space and mapping.
>Is that what you meant by "subset of the range of ex:integer"?
>>  Still, we do need something. So how about using drange to do it. In
>>  other words, lets make the following extra specification on drange:
>>  when ddd is a datatype property,
>>  ddd rdfs:drange aaa .
>>  means that (the class extension of) aaa is *precisely* the range of
>>  ddd, ie precisely the lexical space of the datatype,
>But the above rdfs:drange statement implies that
>   aaa rdf:type rdfs:Datatype .

It only entails that if the appropriate 'local typing' triple is 
included in the graph, not in general. And I addressed this point in 
the email you are citing.

>and a datatype is *not* a lexical space, it is both a lexical
>space and value space.

No, it is a value space. (Please don't get things confused even more 
than they already are :-). So if this were used in the context of 
local typing, it would entail that the lexical space of aaa was the 
value space of SOME datatype. If you were to go and use aaa in a 
datatyping context then this might cause some odd things to happen, 
but I doubt if any rational person would use it in that way.

>And now your back to multiple URIs for datatypes, which we spent
>ages getting past.
>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?

>If someone wants to mint their own URI that
>is meant to denote the lexical space of a datatype, and then say
>    ddd rdfs:range aaa .  (note rdfs:range, *not* rdfs:drange)
>then fine, but they are likely going to be the only ones that
>recognize that lexical space URI -- and it's needless anyway
>since that semantics is provided "for free".
>I think the real issue here was being able to use inline idioms
>and assert that those literals were members of the lexical space
>of a datatype, which seems to require one more (final) range
>property. C.f.
>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? .

>-- 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.

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. For example, the lexical forms would be 
potential values when the doublet idiom was used.

But in any case, we rejected the 'in-line' idiom, with no value node, 
right? We don't WANT that to be datatype-sensitive.

>  > We already have
>>  a name for the precise value space of the datatype,
>If you're talking about URIs, we only have a single name for
>the totality that is a datatype -- value space + lexical space + mapping
>(+ optional canonical lexical space). We have no name for the precise
>value space of any datatype.

Yes, we do. Read the proposal again: the datatype name used as a 
class name denotes the value space of the datatype.

>Or do you mean, via rdfs:range we already have a way to precisely
>constrain a property to the value space of a datatype? (which I agree)
>>  This means drange exerts an extra kind of semantic magic, but only
>>  when applied to a datatype property.
>Right. And since it's magic ;-) the explicit statement defining the
>range of a datatyping property to its lexical space is not needed.
>>  Happy with that?
>Yes, if it is combined with the union interpretation of rdfs:drange
>and the datatype property range statements are left implicit without
>requiring actual URIs to denote the lexical spaces.
>>  Pat
>>  PS  Patrick S, I think you maybe already suggested this??? I didn't
>>  grok it at the time.
>There were two things I suggested recently to try to work out
>the mysteries of ranges, both of which are touched upon above,
>but which I'll recap here just to be clear (if I can ;-)
>a) that for any datatype property, it is understood (though does
>    not require any explicit statements) that the range of a datatype
>    property is the lexical space of the datatype and the domain of
>    a datatype property is the value space of the datatype -- which
>    I think is intuitively what datatype properties are all about,
>    and I expect that this is evident in numerous earlier sources,
>    such as Sergey's S proposal materials and lots of postings, etc.

Right, I agree.

>b) that the interpretation of rdfs:range is to constrain only to
>    the value space of a datatype, that the interpretation of rdfs:drange
>    is to constrain to the union of the value space and the lexical space
>    of a datatype,

No, that doesn't make sense.  drange has the same value constraint as 
range, but in addition imposes some extra semantic conditions on 

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Tuesday, 19 February 2002 15:41:43 UTC

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