Proposal to resolve ISSUE-86

RDF/XML serialization for anonymous inverse properties
To remind:
> Anonymous inverse properties can be used in ObjectPropertyAssertion  
> axioms like
>
>    ObjectPropertyAssertion(InverseObjectProperty(property) subject  
> object )
>
> According to [1], the RDF/XML serialization of this assertion will be
>
>    subject _:p object .
>    _:p owl11:inverseObjectPropertyExpression property .
>
> which is not valid RDF because RDF does not allow bnodes in the  
> predicate position [2]. AFAICT this is the only place where  
> anonymous inverse properties appear in the predicate position (all  
> other uses get serialized into subject or object position).  
> Disallowing anonymous inverses in ObjectPropertyAssertion would  
> solve the problem (and would not affect the expressivity).

I think it is beneficial to allow for anonymous inverses in  
ObjectPropertyAssertion. Note that this is not an issue with RDF/XML  
specifically, but rather of RDF proper.
The proposal is as follows.
1) InverseObjectProperty can currently be nested. Thus we can have  
InverseObjectProperty[1](InverseObjectProperty[2]...  
InverseObjectProperty[N](P) closed with an appropriate number of  
parentheses. If N is even, rewrite the expression to "P", otherwise  
rewrite the expression to "InverseObjectProperty(P)".
If the expression is now P we're done.
[Alternatively, change the grammar so that the nesting is not possible  
- this is my personal preference, btw]
2) Change the production "inverseObjectProperties :=  
'InverseObjectProperties' '(' { annotation } objectPropertyExpression  
objectPropertyExpression ')'"
to "inverseObjectProperties := 'InverseObjectProperties'  
'(' { annotation } objectPropertyURI objectPropertyURI ')'"
I don't see the need for using objectPropertyExpression here, and it  
simplifies the below.
3) Consider that there may already be an axiom  
InverseObjectProperties(P IP) in which case I'll say IP exists.
If IP exists, on serialization, an implementation MAY substitute IP  
for InverseObjectPropery(P) and we're done. (I'm mixed on this one  -  
I could take it or leave it)
4) If IP exists an implementation may and if not it must create a new  
URI to name the inverse property, in a canonical way  -  the URI that  
results from the concatenation of unabbreviated form of "owl11:aip_"  
and the % encoded objectPropertyURI - call this aiP. Note that this is  
guaranteed to not collide with another URI.
if this choice is made, then add another triple - aiP owl:inverseOf P
-Alan

Received on Monday, 17 March 2008 01:31:10 UTC