- From: Ian Horrocks <horrocks@cs.man.ac.uk>
- Date: Mon, 9 Jul 2001 19:39:25 +0100 (BST)
- To: David Martin <martin@ai.sri.com>
- Cc: Tim Finin <finin@cs.umbc.edu>, "'Marcelo Tallis'" <mtallis@teknowledge.com>, "'Dan Connolly'" <connolly@w3.org>, www-rdf-logic@w3.org
On July 9, David Martin writes: > > > Ian Horrocks wrote: > > > > On July 9, David Martin writes: > > > > > > > > > Tim Finin wrote: > > > > > > > > > From: www-rdf-logic-request@w3.org > > > > > [mailto:www-rdf-logic-request@w3.org] On Behalf Of Ian Horrocks > > > > > ... > > > > > Another possible interpretation is some sort of "role value > > > > > map", as it is called in description logics. i.e., we may > > > > > want to say that for all pairs of individuals (x,y) related > > > > > by some property P (or some chain of properties), the P1 > > > > > property of x and the P2 property of y must have the same > > > > > individual as their objects. I believe that we can't capture > > > > > this in DAML+OIL - if we can then we made some mistake > > > > > somewhere as the language would certainly be undecidable. > > > > > > > > I understood that this was what David needs, or something close to it. > > > > > > Yes, as I replied earlier, that is what I need. And I appreciate, of > > > course, the concern about decideability, with respect to the general way > > > this has been framed above. > > > > > > But what about 2 simpler alternatives: > > > > > > (1) What about if we could say <P1 sameValuesAs P2> - meaning simply > > > that the set of values of all the instances of property P1 is precisely > > > the same as the set of values all the instances of property P2 (and > > > again, there's no assumption that P1 and P2 have the same domain)? (I'm > > > asking, not so much how this might be useful, but whether it would be a > > > reasonable addition to DAML+OIL.) > > > > An instance of a property P is a tuple (x,y) s.t. P(x,y) is true. I > > presume that you mean y to be the "value" of such a tuple, > > Yes. > > > and that > > what you want to state is that P1 and P2 have the same range. > > No. I'm distinguishing between 2 things: (A) the set of possible values > that can be used in instances of P (which I take to be the range), and > (B) the set of values that *actually appear* in instances of P (that is, > instances that actually appear on the Web somewhere, or perhaps on some > delimited part of the Web, if that makes it easier to think about). And > I want to make an assertion about (B). > > Here's an (admittedly contrived :-) example: Suppose, for simplicity, > that every person on earth has a unique Personal Identity Number (PIN), > which is an integer. Suppose parentedBy is a property declared with > domain integer and range integer (so that <parentedBy PIN1 PIN2> is used > to indicate the the person with PIN2 is parent of the person with > PIN1). I know that this is only an example, but this kind of modeling (viewing a unique identifier of an object as being the same thing as the object itself) is not a good idea and inevitably leads to problems. I will ignore this for now. > Now suppose some marketing firm wants to track who buys > different brands of diapers. They have a class DiaperBrand (with > instances such as Huggies and Pampers) and they use a property > DiapersBoughtBy, which has domain DiaperBrand and range integer (so that > <Pampers DiapersBoughtBy 1234> indicates that on some occasion, person > 1234 made a purchase of some Pampers). Point of interest. This example may not play well in the international community, as diaper is strictly US English - in the UK we call them nappies (although most people probably know what a diaper is through watching films and TV from the US). > Now suppose that our marketing firm wants to assert that every parent > has bought diapers, and that diapers have only been bought by parents; > that is, the set of values of all the existing instances of parentedBy > is identical to the set of values of all the existing instances of > DiapersBoughtBy. These two things are NOT the same. The first is saying something about the structure of the world (the SCHEMA), while the second is saying something about some particular instantiation of that structure (the DATA). The first is monotonic - if we say that all parents have bought diapers, then we can never have a non diaper-buying parent. The second is non-monotonic - all we know is that we aren't aware of a non diaper-buying parent at this moment, and we may become aware of one at any time. Most KR languages, including DAML+OIL, are designed to describe the structure of the world - they make an open world assumption, and don't allow classes to be defined based on the current (non)existence of some particular data. In this case, the marketing firm can assert that every parent has bought diapers, and that diapers have only been bought by parents, but what this means is that this must be true for all parents, not just the ones we know about at this particular moment. This is one of the key aspects that differentiates a KR system from a database. > (Surely this is not the same thing as saying that the > 2 relations have the same range; after all to say that the 2 relations > have the same range is just to make the trivial statement that integer > is integer.) This is where equating the identifiers with the individuals comes back to bite you. If the parentedBy property had a range Person, then saying that DiapersBoughtBy has the same range as parentedBy gets you closer to where you want to be (at least w.r.t. open world semantics). Actually, there is another problem here in that range is a one way implication w.r.t. properties, i.e., if the range of P is C, then P(x,y) -> C(y), but it is NOT the case that C(y) -> (exists y . P(x,y)). So you can't say what you want to say by using ranges (one of my general criticisms of the swws paper was that you seemed to be trying to do everything with range and domain - presumably because that is all that was provided by rdfs - and ignoring the rest of the language). What you really want to say is that that the class of persons who buy diapers is exactly the same as the class of persons who parented some other person. To do this you should use a sameClassAs assertion along the lines of (using a pseudo-syntax): parented inverseOf parentedBy DiapersBought inverseOf DiapersBoughtBy sameClassAs intersectionOf Person Restriction onProperty parented hasClass Person /Restriction /intersectionOf intersectionOf Person Restriction onProperty DiapersBought hasClass DiaperBrand /Restriction /intersectionOf /sameClassAs > I'm suggesting that one might want to assert this by saying something > like <parentedBy sameValuesAs diapersBoughtBy>. > > I'm out of time for now, but - for those who have never been in the > business of marketing diapers - I'll try to say more about why I think > this might be useful in another message. > > So I guess the questions are - (1) is there any way at present to say > something like <parentedBy sameValuesAs diapersBoughtBy>; (2) if not, > would it be reasonable to add sameValuesAs into the language? I don't think so. We can already state class equivalence, and classes can be defined by the existence of (inverse) properties etc. Regards, Ian > > Thanks, > > - David > > > > This is > > easy: just specify the range of P1 and P2 as RangeP1 and RangeP2 > > respectively and say (sameClassAs RangeP1 RangeP2). I can't see how > > this helps you though as what you want to say (I think) is that the > > range of P1 and P2 are the same w.r.t. certain individuals. > > > > > (2) And if (1) seems reasonable, what about if we could then say <P1 > > > sameValuesWithinNamespaceAs P2> - meaning that the set of values of all > > > the instances of property P1, for which the domain object is in any > > > particular namespace N, is precisely the same as the set of values all > > > the instances of property P2, for which the domain object is in that > > > same namespace N? Would something like that be reasonable (because I > > > can imagine it being very useful)? > > > > You could also do this for explicit namespaces simply by using named > > subProperties in each namespace. E.g., in namespace N1 use P1N1 and > > P2N2 s.t. (subPropertyOf P1N1 P1) and (subPropertyOf P2N1 P2) and the > > ranges of P1N1 P2N1 are made equal as above. Stating this more > > generally (e.g., that such a relationship holds for arbitrary > > namespaces) would be tricky I think as it would be giving some sort of > > semantic significance to namespaces which they don't really have. > > > > Again, I am not at all sure that this mechanism would address your > > problem. > > > > Regards, Ian > > > > > > > > - David > > > > > > > We want to be able to say, for example, that a Process has two > > > > steps and that the output of step one must be the same individual > > > > as the input of step two. If we don't have this in our language then it > > > > may be very hard to model complex processes which have sub-processes > > > > that have constraints between them. For that matter, it will be hard to > > > > model complex things composed of parts which have constraints among > > > > them. > > > > > > > > Tim
Received on Monday, 9 July 2001 14:47:00 UTC