- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Fri, 22 Feb 2002 11:00:54 +0200
- To: Pat Hayes <phayes@ai.uwf.edu>
- CC: RDF Core <w3c-rdfcore-wg@w3.org>
On 2002-02-22 1:53, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote: >> What the rdfs:drange is really saying is that the property >> value can be *either* a value bNode or a literal > > No, its saying that the property value is in the value space of the > datatype (just as if it were rdfs:range) but *in addition* it is > imposing some interpretation conditions on literals that occur at or > 'near' the object nodes of triples using the property. This makes no sense to me. If xsd:integer is the value space alone and ppp rdfs:range xsd:integer . restricts values of ppp to values of xsd:integer, then xxx ppp "15" . is an error. >> -- i.e the >> datatype class contains the members of both spaces, i.e the >> datatype class is the union of the value space and lexical >> space of the datatype. > > No, its definitely not saying that. Then I don't see how the above range constraint can be valid. >> Why not then, for the sake of the users (and us too ;-) toss >> out all the extra d* vocabulary, and both the value triple >> and doublet idioms (which were desparate measures before >> considering datatype classes as unions) and say exactly the >> same thing using the present RDF/S vocabulary using a treatment >> of datatype classes as unions of lexical and value spaces? > > Because not everyone might want to invoke datatyping by using > rdfs:range, so I thought it should be an option. They don't have to. An rdfs:Datatype is an RDFS class just like any other. It has members. And rdfs:range constrains the values of a property to the members of that RDFS class. If an rdfs:Datatype is treated as a union of the value space and lexical space of some extra-RDF datatype, then rdfs:range works as it always has, and should work. Folks who use rdfs:range on non-datatype classes do not invoke datatyping. Only folks who use rdfs:range on rdfs:Datatype's invoke datatyping. > If people are willing to make this non-optional then we could attach > the condition to rdfs:range, it is true. I guess this would be OK, > since then one could assert range information about a sub/super class > of the datatype class, and that would not invoke the datyping > conditions on literals. OK, yes, that would be an option. Good point, > I hadnt thought of that. Thanks. Sorry for taking so many words to make it clear. I guess I need to go take a remedial writing class (or a math class ;-) > We should still have something like rdfs:dlex around, though, in > order to record value-lexical links when datatype information isn't > available for some reason. Seems that the good old meaningless rdf:value would work. The datatype interpretation is provided by the fact that the range is an rdfs:Datatype. Thus, given ddd rdf:type rdfs:Datatype . ppp rdfs:range ddd . all the following are "equivalent" insofar as datatyping interpretation (extra-RDF ;-) is concerned: xxx ppp "zzz" . yyy ppp _:1 . _:1 rdf:value "zzz" . zzz ppp _:2 . _:2 ddd "zzz" . (ooooh... deja vu ;-) >> And that the statement >> >> xxx ppp "34" . >> >> in isolation of any datatyping knowledge has no datatyping >> interpretation. > > Well, it has to have SOME interpretation, since it is legal RDF. So > we should have it be satisfied by any interpretation, ie an > undatatyped literal can mean anything at all, like a bnode. The RDF MT interpretation is that it is a literal. It has no datatyping-specific interpretation either in the MT or based on the set rules for application (extra-RDF) interpretation of datatyping based on the datatyping idioms and the rdfs:Datatype class. >> It might get some later, but that's the risk >> of the inline, implicit idiom. >> >> But, insofar as the graph syntax and MT is concerned: >> >> The literal "34" in all cases above, in the graph itself, >> denotes the literal "34". It *never* denotes 34, ever. > > NO no no. You just contradicted yourself. Stop while you were ahead. No no no, I didn't ;-) I'm not talking about it denoting 34 in the MT. To an extra-RDF application that *knows* what xsd:integer is, the pairing ("34",xsd:integer) *means* 34, but that meaning can *not* be captured in the RDF graph or MT, not until all and every bit of relevant knowledge about xsd:integer is expressed in RDF, which it likely never will be. >> >> The URI xsd:integer denotes the RDF datatype class, > > Yes > >> which >> contains both values and lexical forms of the xsd:integer >> datatype (is the union of the value and lexical spaces). > > No I'm saying it does. That's a premise of the solution. That we treat rdfs:Datatypes as representing some extra-RDF datatype DDD and having as its members the members of both the value and lexical spaces of DDD. >> >> The bNode _:1 denotes the value but *NOT* 34 > > ??? What is the value, if not 34?? It has to denote SOMETHING. See above. It can never be made explicit in the MT that the value actually *is* 34. Only that the bNode denotes a single, specific value, whatever the datatype mapping says it is. > Better to say: In a simple RDF interpretation, it can denote > anything; It can't denote anything. It denotes a single value, we just can't know which value exactly since RDF doesn't grok the datatype. > in a datatyped RDF interpretation, it denotes 34. No. It doesn't. Only with special extra-RDF knowledge about the datatype can we determine that 34 is the actual value it denotes. This is really, really important, and really, definitely true, so *please* try to work through my non-mathematical mumblings to understand it. Based on RDF knowledge, and any MT you might be able to craft, one can never, ever know what the actual value is -- only that there is a single, consistently determinable value, based on the N:1 mapping from lexical to value space defined for all extra-RDF datatypes represented by instances of rdfs:Datatype. > Adding > the datatyping restricts the set of satisfying interpretations. Yes. It does. But the nature of that restriction cannot be expressed or captured in the MT (at least not without being able to actually *define* datatypes a'la XML Schema in RDF). >> (you need >> an application that knows about xsd:integer to *know* >> that the value is 34! Apart from the actual extra-RDF >> interpretation you can *never* know what value the bNode >> actually denotes! only that it denotes a single determinable >> value obtainable from the datatyping interpretation) > > There are two different notions of satisfiability and hence two > notions of entailment. The one with datatyping added is 'stricter' > than the other. But the strictness is opaque to the MT. >> And with the additional assertions that: >> >> Everything denoted by a literal node has an rdf:type of >> rdfs:Literal. >> >> Everything denoted by a URIref node or bNode has an rdf:type >> of rdfs:Resource. >> >> rdfs:Literal is not a subclass of rdfs:Resource > > I don't see why not. We can leave this extra bit for now. It's not central to the "Dummies" solution. And it may not be absolutely needed (we may not care to restrict idioms, only achieve consistent constraints on lexical forms, which is already provided). >> Surely if you can make the MT work for your latest treatment of >> the inline idiom, which really does assume a union treatment of >> datatype classes, it can be made to work for the above minimalist >> solution and we can achieve a solution that users will *enjoy* >> using and not flail about over with moaning and gnashing of teeth. > > Well, let us hope so. I certainly do. I hope my ramblings above have helped to clarify how we might realize that hope. 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 Friday, 22 February 2002 03:59:20 UTC