W3C home > Mailing lists > Public > public-sws-ig@w3.org > September 2004

Re: Disjointnesses in OWL-S

From: Evren Sirin <evren@cs.umd.edu>
Date: Wed, 22 Sep 2004 14:06:50 -0400
Message-ID: <4151BF3A.7030506@cs.umd.edu>
To: Daniel Elenius <daele@ida.liu.se>
CC: public-sws-ig@w3.org

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. 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)


> 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 18:07:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:32:46 UTC