- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Mon, 29 Apr 2002 11:31:29 +0300
- To: ext Brian McBride <bwm@hplb.hpl.hp.com>, RDF Core <w3c-rdfcore-wg@w3.org>
On 2002-04-29 10:41, "ext Brian McBride" <bwm@hplb.hpl.hp.com> wrote: > At 08:45 29/04/2002 +0300, Patrick Stickler wrote: >> On 2002-04-28 19:18, "ext Brian McBride" <bwm@hplb.hpl.hp.com> wrote: >> >>> The know fix >>> ============ >>> >>> In the know fix, we assume that the knowledge that >>> >>> <jenny> <age> "10" . >>> >>> really means >>> >>> <jenny> <age> _:a . >>> _:a <xsd:decimal> "10" . >>> >>> is defined elsewhere >> >> This is almost but not quite correct. Unless you intended >> to specify explicitly somewhere in the graph that >> >> age rdfd:datatype xsd:decimal . > > Fair enough, I'm happy to add that as a precondition, though I don't think > its really necessary in this case. Well, it's necessary if the entailment is going to hold (IMMHO). > [...] >>> >>> The Rule Fix >>> ============ >>> >>> We build a rule mechanism, as in the know fix, into RDF. I think Jos has >>> claimed that he has proved something similar, if not the same as this, >>> works. No one I have suggested this to has like it, usually for different >>> reasons. >>> >>> <jenny> <ageA> "10" . >>> <ageA> <rdfd:datatype> <integer> . >>> <ageA> <rdfd:valueProp> <ageB> . >>> >>> entails: >>> >>> <jenny> <ageB> _:a . >>> _:a <integer> "10". >> >> There is an alternate way to fix this by rule without introducing >> any variant properties. Namely the following closure rule: >> >> ?s ?p ?l . >> ?l rdf:type rdfs:Literal . >> ?p rdfd:datatype ?d . >> >> entails >> >> ?s ?p ?x . >> ?x ?d ?l . >> >> or >> >> ?s ?p _:a . >> _:a rdfd:lex ?l . > > I was under the impression this one was subject to some criticism: > > a) Pat proposed it did not work (supported by Jeremy) > > http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Apr/0341.html I'm still not convinced of that, based on a lack of clarity about rdfs:Literal. See recent posts. > b) it has unfortunate interactions with things like > daml:uniqueProperty. What if ?p is unique? This problem exists regardless of the closure rule. Even if the closure rule doesn't entail it automatically, you can still have explicitly asserted in the graph both Jenny ex:age "10" . and Jenny ex:age _:x . _:x xsd:integer "10" . which will result in exactly the same problem with either daml:uniqueProperty or owl:UniqueProperty. The problem is not with the closure rule. The problem is that literals cannot denote a datatype value, and hence, one can *never* use both the inline idiom and a bnode based idiom in the same graph with a daml:uniqueProperty. >> Why xsi:type? > > Because that is what xml schema uses. But then we have to adopt a good portion of XML Schema semantics to define how it works. >> And why for every occurrence? > > Every occurrence? Well, I presume you'd have to put that attribute on every property element to indicate the datatype of its object, no? > >> The point of the inline idiom is that the datatyping is implicit >> (global, not local). The above is just as local, and more verbose, >> than the datatype property idiom: >> >> <rdf:Description rdf:about="#jenny"> >> <age xsd:decimal="10"/> >> </rdf:Description> > > True. But the xsi mechanism may allow us to use DTD's and schemas to > override the interpretation of existing RDF. I don't see how the xsi mechanism works any differently from the datatype property idiom, and it does so with a more verbose serialization and requires additional definition/specification. The only way it differs from the datatype property idiom is that it doesn't introduce a blank node, which I guess would give us a symmetrical set of four idioms: Blank Node No Blank Node Global rdfd:lex inline Local datatype xsi:type But do we want another idiom, and does not introducing a new idiom also touch the stake in the ground? 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 Monday, 29 April 2002 04:28:21 UTC