Re: Representation of SWRL expressions in OWL-S

a question .. at the bottom ...

Bijan Parsia wrote:

> 
> On Feb 4, 2005, at 1:35 AM, Evren Sirin wrote:
> 
>> Daniel Elenius wrote:
> 
> [snip]
> 
>>>
>> I have two concerns about this format:
>>
>>>
>>> 1) Aren't all SWRL expressions supposed to be instances of the 
>>> http://www.daml.org/rules/proposal/swrl.owl#Imp class?
>>
>>
>> No, a SWRL expression body is supposed to be an AtomList which is 
>> simply the conjunction of atoms in the list.
> 
> 
> By design.
> 
>>> I know that this was the case in an intermediate
>>> version of OWL-S, but this version does not seem to be available 
>>> anymore. Expressions were rules with
>>> empty heads (bodies?).
>>
>>
>> I think at some point it was considered to use rules with empty 
>> bodies. Then the expression would be written as the head of the rule. 
>> SWRL defines empty body to be trivially true so the implication is 
>> true whenever the head is true. But using rules in this way would be 
>> more confusing so it was decided to use AtomList's directly.
> 
> 
> It's not just confusing, it's the wrong semantics, right? Precondtions 
> *aren't* always true!
> 
>>> 2) If this is not the case, i.e. we can use constructs from SWRL as 
>>> we feel like it,
>>
>>
>> No, we can not.
> 
> [snip]
> 
> Definitely not. The intention was that you'd use SWRL constructs in the 
> relevant *ontologies*. So *outside* and expression, you can use SWRL 
> rules as you see fit.

I can't quite make sense of the last sentence above - is that "outside an 
expression"?  If so, I'm not following - we talk about SWRL as the language in which 
expressions are written - so how can you use SWRL outside an expression?

Apart from that, this general point (that we cannot "use constructs .. as we feel 
like") still seems in need of clarification.  Daniel wasn't suggesting that 
arbitrary inappropriate uses of SWRL constructs should be allowed anywhere.  His 
point was simply that we relaxed SWRL conventions a little to allow for a standalone 
AtomList, so why can't we extend the relaxation a little further and allow for a 
standalone IndividualPropertyAtom (instead of writing an AtomList containing that 
IndividualPropertyAtom)?  I can't see anything wrong with that.

- David

Received on Friday, 4 February 2005 16:41:35 UTC