Re: some minor issues in the 2nd edition documents

Hi Boris!

I'm happy with your explanation! And also, I have to say, a really a 
good catch! It seems that we are lucky that the non-determinism in your 
example still leads to two semantically equivalent results. Just let's 
hope that this is the case for all other possible examples as well.

Cheers,
Michael

Am 27.09.2012 12:44, schrieb Boris Motik:
> Hello,
>
> I'm sorry that my answer was incomplete (and it took me some time to remember what the exact reason was).
>
> In the example you mention, condition CE(_:x) = ε is not needed because there is a general requirement saying that, if at any point in time CE(_:x) (or OPE or any other such function) gets redefined, then parsing fails. This is OK in the case of, say, owl:complementOf, since in any OWL 2 DL ontology owl:complementOf will occur only in tree-shaped substructures (i.e., you shouldn't have _:x be defined using owl:complementOf as well as, say, owl:intersectionOf).
>
> As I've already mentioned, the same holds for OPE: if it gets redefined, parsing fails. However, owl:inverseOf does not occur only in such well-behaved patterns. Consider the following OWL 2 DL ontology:
>
> (1)  InverseObjectProperties( ObjectInverseOf( A )  ObjectInverseOf( B ) )
>
> When serialised to RDF, you get the following triples:
>
> (2)  _:x owl:inverseOf A
> (3)  _:x owl:inverseOf _:y
> (4)  _:y owl:inverseOf B
>
> Note that _:x now occurs as subject in two triples, (2) and (3). Because of that, when you apply the pattern in Table 11, if the pattern didn't have OPE(_:x) = ε, you'll get a redefinition of OPE(_:x) and parsing would fail. Condition OPE(_:x) = ε prevents that: after the first application o the pattern, the pattern is not applicable any more. Thus, your parser will define OPE(_:x) as either ObjectInverseOf( A ) or ObjectInverseOf( ObjectInverseOf( B ) ), depending on which pattern is processed first. Consequently, the result of your parsing process will be either
>
> (5)  InverseObjectProperties( ObjectInverseOf( A )  ObjectInverseOf( B ) )
>
> or
>
> (6)  InverseObjectProperties( A  ObjectInverseOf( ObjectInverseOf( B ) )
>
> The result of parsing is thus nondeterminstic, but all the possible results are logically equivalent. I hope this helps in answering your question.
>
> Regards,
>
> Boris
>
> On 27 Sep 2012, at 00:23, Michael Schneider <schneid@fzi.de> wrote:
>
>> Hi Boris!
>>
>> Am 27.09.2012 00:51, schrieb Boris Motik:
>>
>>>> 01) RDF Mapping: Table 11 on parsing object property expressions has now an extended condition: "OPE(_:x) = \epsilon". While I don't see an immediate problem with this condition, I don't understand why it has been introduced. In comparison, for class expressions, AFAICT, there are never any conditions on the root blank nodes. I believe it is stated elsewhere, that blank nodes for expressions must not be reused, so this condition seems redundant to me. But there may well be a reason for it.
>>>>
>>>
>>> If OPE(_:x) is not equal to \epsilon, then matching this pattern would redefine OPE(_:x) and we certainly don't want that.
>>
>> But then, why isn't there a similar condition for the mappings of /class/ expressions? For example, the mapping rule for class complement expressions in Table 13 states
>>
>>     If G contains this pattern...
>>
>>         _:x rdf:type owl:Class .
>>         _:x owl:complementOf y .
>> (*)    { CE(y) ≠ ε }
>>
>>     ...then CE(_:x) is set to this class expression.
>>
>>         ObjectComplementOf( CE(y) )
>>
>> Why isn't the condition at (*) not replaced by
>>
>> (**)   { CE(_:x) = ε and CE(y) ≠ ε }
>>
>> ? Looks to me like being basically the same problem, or do I miss something?
>>
>> Cheers,
>> Michael
>>
>

Received on Friday, 28 September 2012 20:16:09 UTC