- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Wed, 20 Feb 2002 22:01:32 +0200
- To: Pat Hayes <phayes@ai.uwf.edu>
- CC: Brian McBride <brian_mcbride@hp.com>, ext Graham Klyne <Graham.Klyne@mimesweeper.com>, ext Jos De_Roo <jos.deroo.jd@belgium.agfa.com>
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