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: Thu, 23 Sep 2004 00:44:29 -0400
Message-ID: <415254AD.4080804@cs.umd.edu>
To: Daniel Elenius <daele@ida.liu.se>
CC: public-sws-ig@w3.org

Daniel Elenius wrote:

>
> 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's what I was trying to point out in OutputBinding and 
InputBinding example.

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


As I said I don't object adding these axioms. It would definitely be 
useful to add them. It is just not clear how many of them needs to be 
added. I would prefer adding all the necessary ones, i.e. without the 
ones inferred by inheritance, because selecting just a subset looks like 
a random choice. This could of course result in too many axioms, 10 
control constructs requires 45 axioms and I don't know how many more 
would be needed for the rest. Then it might be a good idea to consider 
using alternative methods of defining disjointness as explained here 
(http://www.w3.org/TR/2004/REC-owl-guide-20040210/#DisjointClasses)

Evren.

>
>
>
>> 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 Thursday, 23 September 2004 04:45:09 UTC

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