- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Fri, 12 Jul 2002 12:06:23 +0300
- To: Pat Hayes <phayes@ai.uwf.edu>
- CC: RDF Core <w3c-rdfcore-wg@w3.org>
On 2002-07-09 2:42, "ext pat hayes" <phayes@ai.uwf.edu> wrote: >> , there is the additional >> constraint that the value denoted by the literal node is the >> specific value to which the lexical form embodied in the label >> maps, according to the lexical to value mapping of that datatype. > > But there is in general no way to connect the literal to the > particular datatype 'through' the value, that is the (your) point. So > just knowing that something has the rdf:type of a certain datatype > class is no longer sufficient to tell us how to interpret a literal > connected to that thing. Yes there is. This is defined by the very nature of datatypes. A datatype has a value space, a lexical space, and an N:1 mapping from the lexical space to the value space. If we have a member of a value space, i.e. a value of rdf:type D where D is rdf:type rdfs:Datatype, then if there is a lexical form (literal) associated with that value, the semantics of the *datatype*, not rdf:type, require there to be a mapping defined from that lexical form to that value, or else the graph is ill-formed according to the datatyping. The point of connection between the value and the literal is the fact that the rdf:type D of the value is rdf:type rdfs:Datatype. I.e., because we're dealing with a datatype, not some arbitrary RDF Class, and datatypes define precisely such connections between literals and values. >> The rdfs:range semantics tells us the literal node denotes the value. >> The rdfs:Datatype semantics tells us the label is the lexical >> representation of the value. >> >> The fact that the class extension of the datatype is only its value >> space is only a problem for query engines or similar applications >> which might separate a lexical form from its original datatype >> context, > > Any engine might do that, since there is no such thing in as this > 'context' in an RDF graph, right? Sigh. Again you're misunderstanding "context". I've explained it dozens of times to you Pat. By context here, I mean that the datatype itself provides a scope of interpretation for the literal. You use the word 'context' yourself in your latest edited version of the stake-in-the-ground proposal. Go see how the word is used there. I'm using it here in the same way. >> based on the original triple in which it occurs (by e.g. >> applying subPropertyOf relations, etc.) >> >> As long as implementers are aware that subPropertyOf and subClassOf >> relations are valid for datatype values but not mappings, and >> that the original context must be preserved, then we're fine. > > But what does it even *mean* to preserve this 'context' ? And if > datatype mappings are properties, then why is subPropertyOf not valid > on them? You yourself just answered this question to Brian. Because inheritance in RDF/S is downwards, not upwards. If a given property X has an rdfs:range of datatype D, and X rdfs:subPropertyOf Y, then Y does not have an rdfs:range of datatype D, insofar as the subproperty relation is concerned, and thus, if one separates the literal from datatype D per the original statement using property X, then it may not be possible to get the same interpretation, or any interpretation at all if in fact property Y has no datatype associated with it. Thus, John age "10" . age rdfs:range xsd:integer . age rdfs:subPropertyOf personProperty . implies John personProperty "10" . but does *not* imply personProperty rdfs:range xsd:integer . and thus, when trying to interpret the latter implied statement John personProperty "10" . since personProperty has no defined range (in this example), the pairing ("10", ?) is incomplete and has no datatyping interpretation. Alternate, the property personProperty could have as its range a datatype other than D where the value space subsumes that of D but has a different lexical space and/or lexical to value mapping. So, to separate a literal from the "datatyping context" of the original statement may preclude or corrupt the correct datatyping interpretation expressed by the original statement. Eh? 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 Friday, 12 July 2002 05:12:44 UTC