Adding lrange to the recent proposal (was: Re: the S-B problem and what to do about it.)

Following Patrick's suggestion, I would like to urge that we allow 
the use of rdfs:lrange. I know this looks like terminology-bloat, but 
it makes possible a very elegant and I think easy-to-use way to 
display the user options (see *** below).

In the interests of everyone's sanity, I will not put this up as yet 
another web document.

On 2002-02-25 07:42, "Patrick Stickler" wrote:

>On 2002-02-24 22:05, "ext Aaron Swartz" <me@aaronsw.com> wrote:
>
>>  On 2002-02-24 2:54 PM, "Pat Hayes" <phayes@ai.uwf.edu> wrote:
>>
>  >> ex:age rdfs:range _:x .
>  >> xsd:integer rdfs:range _:x .
>>>
>>>  If that is acceptable, then that solves the problem, since it frees
>>>  up the datatype name itself to have the value space as its extension
>>>  when used as a class name.
>>
>>  I have no problem with the basic concept behind this, but I think that this
>>  specific version of it isn't going to work since it's impossible to write in
>>  RDF/XML.
>
>One way to express the above semantics, which I've proposed
>before with no response whatsoever from anyone, is to use a
>specific range property that asserts a lexical space specific
>constraint on property values.
>
>I.e. rdfs:lrange.

>It can be easily expressed in RDF/XML.
>
>It has clear, reasonably mnemonic meaning to users.
>
>It leaves rdfs:range to denote constraint to value space.

Right, I like this idea and suggest that we adopt it. So the 
definition of rdfs:lrange is as follows:

aaa rdfs:lrange ddd .

means that the rdfs:range of aaa is the lexical space of the datatype ddd .

(The MT is:

IEXT(I(rdfs:lrange)) = {<x,y> :  <u,v> in IEXT(x) implies L2V(y)(v) 
is defined }

That makes this synonymous with

aaa rdfs:range _:x .
ddd rdfs:range _:x .

but we can relegate that to an appendix somewhere. We also have to 
say what rdfs:lrange means if ddd is not a datatype. It could still 
mean the same as the bnode pair, or it could be vacuous. Whatever, a 
technical niggle.)

>.....
>I don't want to reduce the utility of RDF datatyping for WebOnt, but
>at the same time, don't want to see it too cumbersome and confusing
>for the metadata and content management communities also.

Fair enough, even though our priorities differ.

***
I really do not think that this proposal is cumbersome or confusing. 
Clear your minds for a second of all the debates, take a deep breath, 
and imagine, if you can, a blank sheet of paper, and then write this 
on it:

-----

aaa rdfs:range xsd:number .

just means the range of aaa is the set of numbers, ie the value space 
of the datatype (and has no special datatyping effect on any 
literals.)

-----
aaa rdfs:lrange xsd:number .

just means the range of aaa is the set of numerals, ie the lexical 
space of the datatype (and has no special datatyping effect on any 
literals.)

-----
aaa rdfs:drange xsd:number .

doesn't say ANYTHING about the rdfs:range, but it does impose 
datatype-checking on literals (used in either mode, ie with an 
rdfs:dlex triple - when the bnode is constrained to the datatype 
value of the literal - or the S-B idiom - when the literal is 
constrained to be in the lexical space of the datatype; see the 
figure in 
http://www.coginst.uwf.edu/users/phayes/simpledatatype23-02-2002.html)

Intuitively, the first is all about the value space, the second is 
all about the lexical space, and the last is all about the 
lexical-to-value mapping (and what it does to literals).

-----

So if you want to be DC-sloppy, just use rdfs:drange; you get full 
datatype checking but no range constraints. (The range could be the 
union in this case, or it could be something else.) If you want to be 
precise about your ranges, use one of the first two options. If you 
want to be precise and also use datatype-checking, use one of the 
first two plus the third (it works with either one equally well, so 
that range precision can be added later without having to re-do the 
datatyping).

If you want to be precise about ranges, do datatyping and ALSO allow 
sloppiness, all at the same time, then you have to be slightly 
clever, and use three properties such as ageAsNumber/ageAsString/age, 
with the first two being subproperties of the last one and the three 
options applied to each one (in that order.) This provides both 
'exact' options and also the 'sloppy' option, but the same datatyping 
works for them all. This is the only time you have to think about 
schemas.

Pat

PS. Just as a general plea to the WG: OK, we have to coddle our 
DC-style users. But please, guys, bear in mind that having RDF be a 
foundation for Webont is not just a sci-fi fantasy. It is really the 
only long-term reason for having RDF around. It is vitally important 
that RDF be provided with at least a minimal ability to express what 
needs to be said in a semantically precise way. It is going to have 
to be able to express, maybe indirectly, *any* content that can be 
said in *any* Web language. Already there is enormous 'layering' 
hooha going on which arises from RDF's weaknesses as a foundation. If 
we make it so dumbed-down that it can ONLY be used for DC-style apps, 
then we will have shot Webont in the foot.

PPS. It occurs to me that we could use the name rdfs:dcrange rather 
than drange, and say that it means "Datatype Check on range". That 
might make the DC users feel even more at home.
-- 
---------------------------------------------------------------------
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 Monday, 25 February 2002 13:41:35 UTC