From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>

Date: Tue, 16 Jul 2002 12:47:01 -0400

To: jonathan@openhealth.org

Cc: drew.mcdermott@yale.edu, www-rdf-logic@w3.org, www-rdf-comments@w3.org

Message-Id: <20020716124701A.pfps@research.bell-labs.com>

Date: Tue, 16 Jul 2002 12:47:01 -0400

To: jonathan@openhealth.org

Cc: drew.mcdermott@yale.edu, www-rdf-logic@w3.org, www-rdf-comments@w3.org

Message-Id: <20020716124701A.pfps@research.bell-labs.com>

From: "Jonathan Borden" <jonathan@openhealth.org> Subject: Re: Strange behaviour of datatypes test A1 with answer yes and literals untidy Date: Tue, 16 Jul 2002 11:13:38 -0400 > > Drew McDermott wrote: > > > > > We have: > > > > <bag1> rdf:_1 "10" . (1) > > <bag2> rdf:_1 "10" . (2) > > |= > > <bag1> rdf:_1 _:l . (3) > > <bag2> rdf:_1 _:l . (4) > > > > I don't see why (1) and (2) entail (3) and (4). We've agreed that > > literals without datatyping information could mean anything at all. > > So how can we conclude that the first "10" denotes the same thing as > > the second "10"? > > Suppose we define the infinite set of things denote[d] by "10" as _:1 How? Perhaps "10" does not have a unique denotation. Perhaps "10" and _:1 have different kinds of denotatation. For example, "10" may denote a set and _:1 may not. Perhaps things like _:1 do not have a unique denotation. > then (3)+(4) follow from (1)+(2) Only if your premise is possible in the model theory. > > We have a cardinality constraint of max 1 on rdf:_1. > > > > Now add some new triples: > > > > <bag1> rdf:_1 _:a1 . > > _:a1 <foo:decimal> "10" . > > and so the formerly infinite set of things denoted by "10" becomes the > singleton set which is "10" interpreted as a decimal number according to > foo:decimal (if that is what foo:decimal means of course). Again, only if (some of) the implicit premises above hold. > > > > This is consistent with (1) above and the cardinality constraint, and > also add: > > > > <bag2> rdf:_1 _:a2 . > > _:a2 <foo:binary> "10" . > > > > This is consistent with (2) above and the cardinality constraint. > > > > All together the added statements are consistent with (1) and (2) > above, > > but not with with (3) and (4) above. > > Yes so this is nonmonotonic. No, this is not nonmonotonicity, even if (3) and (4) follow from (1) and (2). All that happens if this is the case is that you have a bad formalism. > The nonmonotonicity is not intrinsic to > datatyping, particularly datatyping done at parse time or at XML Schema > validation time, rather it appears a characteristic of the desire to use RDF > triples to carry both syntax (i.e. the syntax necessary for datatyping) and > semantics. Nope. > Jonathan One way of doing datatyping, which you seem to advocate above, is that a literal denotes an infinite set of things. Then the presence of a literal in a triple means that one (or more) of the things denoted by the literal participates in an instance of the predicate of the triple. So an interpretation is an interpretation of <bag1> rdf:_1 "10" . (1) provided that the extension of the denotation of rdf:_1 in the interpretation contains a pair whose first element is the denotation of <bag1> in the interpretation and whose second element belongs to the denotation of "10", i.e., is some data value that has a lexical represention of "10". This implies that <bag1> rdf:_1 _:l . (3) provided that blank nodes can denote data values, and do not denote sets. However even if the interpretation is an interpretation of <bag2> rdf:_1 "10" . (2) it is not constrained to have the data value above be the second element of a pair in the extension of the denotation of rdf:_1 whose first element is the denotation of <bag2>. Instead the interpretation can pick another element of the denotation of "10" for the purposes of satisfying (2). Now if blank nodes can denote sets (not denote classes, but instead denote sets directly) with the same interpretation of literals as above, you can get (1) and (2) entailing (3) and (4). What happens in this case is that everything coexists nicely. peterReceived on Tuesday, 16 July 2002 12:47:11 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 22:44:00 UTC
*