- From: Daniel Elenius <daele@ida.liu.se>
- Date: Wed, 22 Sep 2004 22:40:28 +0200
- To: Evren Sirin <evren@cs.umd.edu>, public-sws-ig@w3.org
Evren Sirin wrote: > Daniel Elenius wrote: > >> >> I think the OWL-S ontology needs some more disjointness axioms on a >> lot of its subclasses. This would help the reasoner a lot. For >> example, if an instance of InputBinding is used as the filler for a >> withOutput property, which has OutputBinding as range, no >> inconsistency will be detected, unless InputBinding and OutputBinding >> are declared to be disjoint. Instead, the instance will be forced >> into the OutputBinding class, now being an instance of both >> OutputBinding and InputBinding. This causes much more subtle and >> hard-to-detect bugs. > > > > I completely agree with your obeservation but the example you give is > not exactly right. Since Input and Output is defined to be disjoint in > Process.owl this forces InputBinding and OutputBinding to be disjoint > also. So a reasoner would be able to detect that inconsistency. I > guess most of the examples you give above would also be solved if > correct value restrictions are put, for example > subClassOf(WsdlInputMessageMap restriction(owlsParameter > allValuesFrom(process:Input)) . > >> >> Since everything is assumed to be non-disjoint by default, I think we >> should declare things to be disjoint wherever they are meant to be. >> Also, if I have understood things correctly, disjointness does not >> complicate reasoning much (unlike subclassing or number restrictions >> for example) so there is really no reason not to put these things in >> there. > > > I agree that dosjintness does not complicate reasoning much. Statement > (a disjointWith b) is equivalent to (a subClassOf complementOf(b)) but > this subclass expression (generally) does not result in adding new > individuals as a minCardinality would do. Actually, I can argue that > they improve reasoning because when an ontology is being classified > those disjointness axioms would help to prune unnecessary subsumption > tests. > > On the other hand, I must also express my skepticism about using a > reasoner to detect such inconsistencies in OWL-S files. We would need > to add a whole lot of other disjointness statements to be complete. > For example, to catch some other errors you need (Process disjointWith > Profile), (Process disjointWith Paramater), (Parameter disjointWith > Binding) and I don't know how many more. There may be a few of them, but at least the disjointness is inherited, so if A is disjoint with B, we don't have to also say that all subclasses of A are disjoint with all subclasses of B. I agree that more checking than normal DL reasoning is needed for OWL-S instances, but it's a good starting point to check DL consistency (and it's already well integrated with e.g. Protege). So as long as no major changes are required, I don't see why not put this extra stuff in there. > The main problem is that OWL is not meant to be a schema language and > it would be really hard to use it for validating structure of OWL-S > files. That is why in OWL-S API, I chose to implement a syntactic > validator not a reasoner-based one. I'm not saying that we shouldn't > add these disjointness axioms but I want to point out the challenges > of using a reasoner to validate OWL-S files (not to mention the > problems related to Open World Assumption) > > Regards, > Evren > >> >> In Expression.owl: >> DRS-Expression, KIF-Expression, SWRL-Expression - these should be >> disjoint. >> >> In Grounding.owl: >> WsdlInputMessageMap, WsdlOutputMessageMap >> >> subclasses of List: >> WsdlInputMessageMapList, WsdlOutputMessageMapList, >> ControlConstructList, ControlConstructBag >> >> Process.owl: >> InputBinding, OutputBinding >> >> All the control constructs should be disjoint (this requires the now >> deprecated ProcessComponent to be removed in order to work I think). >> >> >> Less important ones: >> >> ProfileAdditionalParameters: >> NAICS and UNSPC should be disjoint >> >> the subclasses of ServiceParameter (AverageResponseTime, >> GeographicRadius, MasResponseTime) should be disjoint >> >> time-entry.owl: >> InstantEvent and IntervalEvent should probably be disjoint. Same with >> Instant and Interval. >> >> >> >> >> >
Received on Wednesday, 22 September 2004 20:40:35 UTC