Re: Disjointnesses in OWL-S

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