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

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.

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.

And you can also constrain the property values to one or the other
by adding additional range constraints for rdfs:Literal and
rdfs:Resource, 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.

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.

The ability to interpret rdfs:drange as the union of lexical
and value spaces allows us, I think, to have our cake and eat
it too.

Folks who don't want to do datatyping at all, use the inline
idiom sans any range constraints, or ignore range constraints
entirely.

Folks who want to provide a datatyping interpretation for literals
use the local idioms and/or the long-range global idioms with
rdfs:drange, and are free to use either the inline or value triple
idiom in that case.

Folks who want to do datatyping, but restrict usage for particular
properties only to the inline idiom (e.g. PRISM, DC) can
combine the rdfs:drange constraint with an rdfs:range rdfs:Literal
constraint and that precludes any of the bNode idioms. E.g.

Case 1: All idioms allowed

   dc:date rdfs:drange xsd:date .

   xxx dc:date "2002-02-20" .  (ok)

   yyy dc:date _:1 .
   _:1 rdfs:dlex "2002-02-20" . (ok)

   zzz dc:date _:2 .
   _:2 xsd:date "2002-02-20" . (ok)

Case 2: Only inline/lexical form idiom

   dc:date rdfs:drange xsd:date .
   dc:date rdfs:range rdfs:Literal .

   xxx dc:date "2002-02-20" .  (ok)

   yyy dc:date _:1 .
   _:1 rdfs:dlex "2002-02-20" . (not ok)

   zzz dc:date _:2 .
   _:2 xsd:date "2002-02-20" . (not ok)

Case 3: Only bNode/value idioms

   dc:date rdfs:drange xsd:date .
   dc:date rdfs:range rdfs:Resource .

   xxx dc:date "2002-02-20" .  (not ok)

   yyy dc:date _:1 .
   _:1 rdfs:dlex "2002-02-20" . (ok)

   zzz dc:date _:2 .
   _:2 xsd:date "2002-02-20" . (ok)


In this way, a specific ontology can choose which idioms
users may or may not use, yet for all allowed idioms
(possibly all of them) the interpretation is the same.

Before we close the books on datatyping, I think we
should give such a treatment serious consideration.

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Wednesday, 20 February 2002 07:33:11 UTC