Clarifying the minimal union-based proposal

On 2002-02-20 20:34, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:

> Patrick, I cannot see how to make sense of this 'union range' idea.

The latest proposal, the one that axes all the new rdfs:d* vocabulary,
simply treats datatype classes as containing both the members of the
value space and lexical space, so the understood semantics of rdfs:range
applies.

I.e, I'm specifically talking about the recent message named "Even
more simplified datatyping proposal".

Perhaps the difficulty earlier was in trying to restrict the union treatment
only to the range contraint rather than globally as a property of the
actual datatype class. Or maybe not. But read on...

> .. if you feel that this can somehow
> solve the problem, then please show me how to state the  model theory
> for it. I don't see how to make it work, and Ive now tried several
> times. So until you or someone shows me how it can work, I have to
> treat it as a non-option.

I'll try. If any of the following points are not clear, say so, and
I'll do my best to restate them. I'm going to try to err on the side
of terseness rather than verbosity. I'm sure you can appreciate that ;-)

I can't offer an MT for it, but perhaps the following statements will
suffice as a move in that direction:

1. A datatype, as defined by XML Schema, consists of a value space, a
   lexical space, and an N:1 mapping from the lexical to value space.

2. RDF views a datatype as an RDF class, the members of which are the
   union of the value space and lexical space of the datatype.

3. RDF provides no representation whatsoever for datatype values, only
   for lexical forms.

4. The rdfs:range property constrains a property to the members of an
   RDF class. In the case of a datatype class, this includes both values
   and lexical forms. Since RDF provides no representation for values,
   if the property value is a literal, that literal represents a lexical
   form for the datatype specified in the range constraint.

[Note that I say 'represents' a lexical form rather than 'denotes'. I
 want to make it clear that the significance of the literal string as
 a lexical form of some datatype is part of the datatype interpretation,
 not part of the graph syntax or semantics.]

5. If multiple range constraints are defined for a property, the property
   value must be a member of all of the specified classes, and if any
   of those classes are datatype classes, then there is the further
   constraint that the lexical form represented by the literal must map
   to the same value in all of the datatype classes.

6. All literal nodes are of type rdfs:Literal

7. All URIref and Blank Nodes are of type rdfs:Resource

8. If both a datatype class and rdfs:Literal are defined as ranges of a
   given property, that property is constrained only to members of the
   lexical space of the datatype. This follows because only lexical forms
   may have representation in the RDF graph as literals.

9. If both a datatype class and rdfs:Resource are defined as ranges of a
   given property, that property is constrained only to members of the
   value space of the datatype. This follows because only values may
   have representations in the RDF graph as URIref or Blank Nodes.

10. A datatype property has an implicit, fixed, and understood range
    of rdfs:Literal which is semantically constrained to correspond
    to the lexical space of the datatype.

11. A datatype property has an implicit, fixed, and understood domain
    of rdfs:Resource which is semantically constrained to correspond
    to the value space of the datatype.

Some specific examples (modeled on and expanded from earlier), with
explanation and interpretations given in square brackets:

Case 0: No datatyping

   xxx ex:age "15" .   [age = "15", "15" denotes "15"]

Case 1: Both inline/bnode idioms allowed

   ex:age rdfs:range xsd:integer .

   xxx ex:age "15" .  (ok)   [age = 15, "15" denotes "15"]

   zzz ex:age _:2 .
   _:2 xsd:integer "15" . (ok)  [age = 15, _:2 denotes 15]

   Because xsd:integer is a datatype class, the range of ex:age is
   constrained to either values or lexical forms of xsd:integer. Since
   only lexical forms can be represented by literals, we know that
   in the first, inline idiom, the property value represents a lexical
   form, and the value has no explicit denotation in the graph, though
   it is clear from the literal-in-context interpretation which value
   it is. In the second idiom, we know that the property must denote
   a datatype value because of the semantic constraints defined for
   the domain of the datatype property xsd:integer and we know that
   the object of xsd:integer represents a lexical form of that datatype
   both because of the range constraint of rdfs:Literal and because of
   the semantic constraint that the range correspond to the lexical
   space of the datatype.

Case 2: Only inline idiom allowed

   ex:age rdfs:range xsd:integer .
   ex:age rdfs:range rdfs:Literal .

   xxx ex:age "15" .  (ok)  [age = 15, "15" denotes "15"]

   zzz ex:age _:2 .
   _:2 xsd:integer "15" . (not ok)  [n/a]

   This case is identitical to case 1 except there is the extra
   range constraint for ex:age that the property values be
   of type rdfs:Literal, and hence literals, so the bNode idiom
   is disallowed.

Case 3: Only datatype triple idiom allowed

   ex:age rdfs:range xsd:integer .
   ex:age rdfs:range rdfs:Resource .

   xxx ex:age "15" .  (not ok)  [n/a]

   zzz ex:age _:2 .
   _:2 xsd:integer "15" . (ok)  [age = 15, _:2 denotes 15]

   This case is identical to case 1 except that there is the
   extra range constraint for ex:age that the property values
   be of type rdfs:Resource and since literals are not of that
   type, the inline idiom is disallowed.


> Bear in mind that the MT (the basic RDFS MT, I mean) does not assume
> that literals denote anything in particular, or that the things they
> denote are not resources, or that rdfs:Literal is a set of literals.
> If you want to use assumptions like this, you need to impose them as
> additional 'datatying' assumptions explicitly.

The assumptions that I am making are that

1. all literal nodes are of rdf:type rdfs:Literal
2. all URIref and bNodes are of rdf:type rdfs:Resource
3. rdfs:Literal is *not* an rdfs:subClassOf rdfs:Resource

I appreciate your efforts in trying to make sense of my ramblings. I
honestly do think there's a solution somewhere in there waiting to
come out... and I hope it is easily and quickly visible since we
need to get this stuff wrapped up...

Regards,

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 15:00:13 UTC