- From: Paul Gearon <gearon@itee.uq.edu.au>
- Date: Sat, 9 Apr 2005 16:20:37 +1000
- To: Bijan Parsia <bparsia@isr.umd.edu>
- Cc: www-rdf-logic@w3.org
I should point out that I'm very grateful for the detailed responses I've been getting. Thank you Bijan... On 09/04/2005, at 1:54 PM, Bijan Parsia wrote: > I'm going to presume throughout that we're talking OWL DL. I don't > believe there are any difficulties with transferring it to OWL Full, > but hey. Actually, I'm not considering OWL DL at all. At least, I'm trying not to be. In places where there is a difference I'll be trying to discuss things in terms of OWL Full. >> Now that I've finished being flippant, I still don't accept a "type" >> of "minCardinality(1)", at least in this system (OWL) > > This is an insignificant syntactic/notational variant. OK, I'll work with this. >> I do however, accept a type of "Restriction" which "has a" minimum >> cardinality of 1. > > What's the difference. If the syntactic form you've shown has the same semantic then nothing, I agree. >> Since restrictions are used to describe the class, > > What class? The class that the restriction applies to. As in: http://www.w3.org/TR/owl-ref/#Restriction "It describes an anonymous class, namely a class of all individuals that satisfy the restriction" >> then I took this to be TBox. > > You're still wrong here. > > http://www.w3.org/TR/2004/REC-owl-semantics-20040210/syntax.html#2.2 > > Even in owl lite: > > type ::= classID > | restriction > > So an individual can be of type restirction without an intervening > class definition. Sorry, I presumed that individuals could not have an anonymous class type. Now that I have to think about it I realise that I'm wrong. <snip/> > Thus class expressions can be part of abox assertions. > > Class expressions are also part of tbox expressions. The tbox consist > of definitions and constraints. These are all universally quantified > conditionals. OK, I'm going to have to take some time to read up and learn exactly where the boundaries lie, so I won't go into it now. > ....Ontologies incorporate information about classes, properties, and > individuals""" > > So, in OWL, the ontology is not the TBox. ??? I thought that at least some of this was TBox? <snip/> >> I do concede that the OWL statement asserts a property >> (minCardinality) on the restriction, > > You conflate syntax with significance. In OWL DL that "asserting a > property" has no assertional significance. In owl full, of course, it > does. Actually, no. I thought you were conflating the two, and I didn't want to get bogged down in the syntax when I wanted to discuss the semantic. I thought if I conceded that the syntax was done with an assertion, then we might be able to put it behind us as a syntactic issue and continue discussing the meaning. Sorry for the misunderstanding. >> but I was under the impression that the assertion of this property >> was just the RDF way of expressing a higher order concept. > > Er....No. OWL is first order all the way. Even owl full. Oh? I thought it was 1.5? >> Am I wrong in thinking that it is possible to express TBox >> information in RDF? > > Well, in OWL DL, the tbox *and* class expressions are *encoded* in RDF > (I wouldn't say they are *expressed*). This show up some of the problems we've had. You obviously have a different semantic for these words in this context, whereas I have the same. I expect you've often seen me say the "wrong thing" when I've meant something different. I'd improve this if I knew how. > In OWL Full, they are also so encoded, and their encoding also has > assertional force. > [snip] > >> A lot of your email takes exception to my statement that >> minCardinality is not useful. I'll confess that I intentionally use >> strongly written statements like "this is useless" to get a solid >> response. > > Perhaps not every interlocutor you enconuter enjoys being manipulated, > or enduring being presumed to require goading to produce "solid > responses", esp. when they have shown good faith with extensive > answers. While the initial statement (before you started responding) was of this form, I really haven't persisted with it, though it may have appeared that way. I've appreciated the help. I've persisted with the expression "useful" in the context of the tools I've hoped to use. Many other OWL expressions have been more evident in how to go about using them. I suppose I came into this confused, because there are a lot of people who expect that cardinality support (of some level) will involve comparing the cardinality values to the number of times a predicate gets used (for instances of the classes described). I think we've established that this is an incorrect view, though it is a very common one. All the same, I take the point. I've persisted unnecessarily and I'll back off. >> I'll explain my position. I'm interested in getting a computer to do >> with with OWL and RDF. From a computer's point of view, there are >> three simple things it can do (there may be more complex things, but >> I'll stick to this for now). The first is to store data. The second >> is to check that data is consistent according to some set of rules. >> The third is to entail new data. >> >> Storing data is easy (efficiency is another story, but that's for >> another mailing list). >> >> Consistency is important, when possible. So when is minCardinality >> able to be used as a tool here? As we've discussed, it is possible >> to see that minCardinality is being used inconsistently when it is >> used to describe unsatisfiable class, > > I really wish you'd make the "next leap". I can get inconsistency even > if all my classes are satisfiable. Take the following tbox statements: > > B disjointWith A. > > Take the following two abox statements. > > x:B. > x:A. > > There are no unsatisfiable classes in my ontology. Strangely enough my > ontology is inconsistent!!! > > How do you explain this puzzling fact? I'm sorry. Reading it, I see that I was not clear. I understand that consistency is a complex problem to solve in the general case. It can be caused by lots of cases. You just showed one. Unfortunately, I only referred to one: A subClassOf _r _r onProperty P _r minCardinality 4 _r maxCardinality 3 a:A That's unsatisfiable, by definition. Then there's something similar like: A subClassOf _r _r onProperty P _r minCardinality 4 B subClassOf _s _r onProperty P _s maxCardinality 3 a:A a:B Which, like yours, shows a pair of completely satisfiable classes which are disjoint. There are lots of other cases where minCardinality can create a situation with inconsistency due to class definitions and instances thereof. eg. Instances of a class can't exist because the class is not satisfiable. Or instances can't be of these several class types, because they are disjoint. The list goes on. There are also some subtle interactions with other classes and restrictions which make it even more complex. I know it's not simple. I'm sure it will give me many sleepless nights trying to calculate this. My point was to try to lump together all cases where class definitions and their instantiations create an inconsistency. Unfortunately, that statement is horribly unclear because the opposing case is also an inconsistency due to an instantiation of a class definition. I'll try and plough on, and see if I can clear it up... The distinction I am being so unsuccessful at conveying has to do with comparing the number of usages of a predicate with the cardinality associated with that predicate. The common presumption is this can be used as a consistency check. In a closed world I might have been clearer. If this were all closed then it may have been possible to distinguish between a consistency problem due to how class definitions interact vs. a class instance which just doesn't use a predicate the right number of times. The principle difference is that one type of check needs to explicitly count the predicate usage, while the other one does not. However, as I argue this I'm starting to wonder about this artificial line I'm drawing between the two. If I want minCardinality to interact with a oneOf class then I'd need to count there as well, even though I'm not counting the usage of the predicate on instances of any class. Perhaps if I look carefully enough then I'll discover that there really was no line between the two types of consistency check. Now that I think of all the complex cases where minCardinality can be used to create an inconsistency I think I finally get what it's for. Even as I slowly came to understand this I've been avoiding it. I was expecting to see (and had been told to look for) some kind of closed world assumption (ie. counting the usage of a predicate), even though my understanding of this said that this was wrong. >> and an instance of that class is described. It cannot be used as a >> tool to discover inconsistency in the number of times a predicate >> gets used (this is contrary to the intuition of most people who start >> using OWL). > > You do need further constraints. > > You do not have a closed world. > > It is not like XML schema or most data validation constraints. Yes, I understand this part, and have done for a while now. When I first came here I had worked this out, but didn't understand why it was different to what I'd been told to expect. This was mostly because a lot of people I know have expected the closed world view. I assumed I was wrong in thinking that I couldn't count and compare, because that's what so many people talk about with cardinality. So I think I got that part right, even though I got everything else wrong. >> I started out with an expectation that I could use minCardinality for >> consistency checking using some kind of counting mechanism. I've now >> come to understand that this was wrong. > > You can, but not like you thought. This is in fact how reasoners work > (for some value of "some kind of counting mechanism). This is interesting. Can you give an example please? The only place where I can think this could happen would be if the range of a cardinality restricted predicate were finite and countable (eg. oneOf). Is this the sort of thing you mean, or have I missed the point again? >> The final mechanism of entailment cannot use minCardinality either. > > Oh piffle. That's a very leading comment, particularly when it comes with no explanation. So what sort of thing are you referring to? Now that you've said this, I'm thinking about it, and the only thing that comes to mind is something like: minCardinality(P, x) hasRange(P, C) oneOf(C, set) If the cardinality of the set is x, then I could entail that each element of the set is distinct. Is that the sort of thing that you mean? I can't think of anything else (I know that's a poor reflection on my imagination). > minCardinality is just syntactic sugar for existentials. Even > minCardinaly greater than 1. Yes, I got that. >> That is so far beyond the scope of what I've been looking at that I >> failed to consider it. (embarrassed grin here) >> >> When you've said that if minCardinality is useless then so too is the >> rest of OWL, I have not found this to be the case at all. Other >> expressions in OWL provide some very useful tools for consistency >> checking and entailment, > > Examples? I mean, I have a reasoner that can reason with all of owl > (if not all of it at once; now that shoiq is cracked that will > change). Well there's lots of trivial stuff for a start: sameAs(b, a) :- sameAs(a, b). sameAs(a, c) := sameAs(a, b), sameAs(b, c). Or for a functional property P: sameAs(a,c) :- P(a,b), P(a,c). The list is huge, and in some places it's complex (as opposed to these simple ones). But I know you know this, so I suspect you're asking about something else. I can't tell what, sorry. >> much of which has already been defined (though I've seen different >> papers and the w3c site sometimes defining different things... I >> won't get into that today). I was just expecting to use >> minCardinality in a similar way, > > I would like to know the other way. Off the top of my head... Raphael Volz, among others, has tried to describe a lot of these in horn clauses, and sometimes predicate logic. In some cases he's re-iterated entailment tests on the W3C site, and in others he has extended on them. Similarly, the W3C site mentions entailments that he hasn't looked at. I've seen other papers, but I can't recall the authors just now. While I've yet to see anyone describe an entailment that conflict with someone else, there seem to be lots of different lists out there. In couple of cases I'm looking at entailments which are consistent, but don't appear to be deductive. That bothered me until I learnt about abduction. Still, I'm looking at deductive systems, so abductive entailments seem beyond me for the moment. >> but the more I looked at it, the less I found that I could. I could >> only do consistency checks with it when finding things like >> uninstantiable classes. > > Well since that is *still not true*, and since that was more than you > originally thought...well...you see where I'm going :) Well I *can* do consistency checks for instantiations of uninstantiable classes... but I can do more than that. I'm definitely wrong to say "could only do". > If we're still trying to get you to understand the logic, I strongly > suggest you read chapter 2 of the DL handbook, to clear up your > abox/tbox/class expression confusions. OK, I've been flicking back and forth in this book, but haven't read chapter 2 yet. Will do that over the weekend. Regards, Paul Gearon
Received on Saturday, 9 April 2005 06:21:24 UTC