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

Trying to make sense of range and drange

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Fri, 15 Mar 2002 11:52:41 +0000
Message-Id: <>
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: Pat Hayes <phayes@ai.uwf.edu>, RDF Core <w3c-rdfcore-wg@w3.org>
This is a long-ish message.  The main part explores this key 
question:  according to [1], what can we say about the relational extension 
of ex:age (IEXT(I(ex:age)) given:

    ex:age rdfs:drange datatype:decimal .

[1] http://www.coginst.uwf.edu/users/phayes/simpledatatype23-02-2002.html

At 09:56 AM 3/14/02 +0200, Patrick Stickler wrote:
>On 2002-03-13 18:56, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
> >
> > Yes, I missed your point.
> >
> > Let me see if I get it now.  Given:
> >
> >    Bob age "35" .
> >    age rdfs:range datatype:decimal .
> >
> > you say there is a range type inconsistency?
> >
> > I agree that there is an inconsistency here.  I don't agree that it is a
> > problem.  Effectively, by saying that:
> >
> >    age rdfs:range datatype:decimal .
> >
> > (and assuming that the value space of datatype:decimal does not include
> > literal values) then I think you are saying that literals should not be
> > used with this property.
>Fair enough, if that is what folks want to say.
>My concern was that, without any rdfs:range constraint at all,
>one cannot utilize a generic RDFS validator to test explicitly
>typed datatype values, but if rdfs:range is used for that
>purpose, it excludes use of the inline idiom which always will
>conflict with any rdfs:range statement with a datatype object.
>And thus, this means that in a practical setting, where either
>idiom may and should be permitted to occur, rdfs:range is useless
>for datatyped properties since it eliminates cohabitability between
>the global and local idioms.
>Maybe that's just the way it goes. But it seems like we're losing
>alot of useful functionality from generic RDFS validation.

Ah... I was going to say that I would expect a generic RDFS validator to 
also know enough about datatypes, but I think I see your point 
now.  Condidering:

    ex:age rdfs:drange datatype:decimal .
    ex:Jenny ex:age "10" .

    ex:Jenny ex:age _:x .
    _:x datatype:decimal "10" .

the second part is consistent with:

    ex:age rdfs:range datatype:decimal .

but the former is not.   Hmmm.


Reviewing the model theory for datatypes [1] I find that I cannot tell what 
the relational extension for ex:age is intended to be.  I think it only 
works if:

    ex:age rdfs:drange datatype:decimal .
means that:
    <I(ex:Jenny),"10"> in IEXT(I(ex:age))

(where "10" is the sequence of two characters) and

    ex:age rdfs:range datatype:decimal .
means that:
    <I(ex:Jenny),10> in IEXT(I(ex:age))

(where 10 is the integer value)

This seems to be saying that rdfs:drange allows datatype lexical-space 
members in the relational extension of a property, and rdfs:range allows 
the corresponding datatype value-space members in the relational 
extension.  I wonder if that is what Pat intended?


[1] http://www.coginst.uwf.edu/users/phayes/simpledatatype23-02-2002.html

I'm thinking there may be a problem with the datatype proposal [1].  Consider:

    ex:age rdfs:drange datatype:decimal .

According to section 5 of [1], taking account that literals denote 
themselves, this means that

    <x,y> in IEXT(I(ex:age)) => z=L2V(I(datatype:decimal))(y) for some z

[i.e. y in the lexical space of datatype:decimal]

But later in section 5 we see that

    ex:age rdfs:drange xsd:number
    Jimmy ex:age _:x .
    _:x rdfs:dlex "35" .

means that Jimmy's age is the number 35, which requires that

    <I(Jimmy),35> in IEXT(I(ex:age))

but the number 35 is not in the lexical space of datatype:decimal, so we 
appear to have a contradiction.

As far as I can tell, this is a problem with [1].  More likely (I hope), 
I'm overlooking something.


[1] http://www.coginst.uwf.edu/users/phayes/simpledatatype23-02-2002.html

Graham Klyne
Received on Friday, 15 March 2002 07:18:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:56 UTC