Re: Proposal to resolve ISSUE-86

If we do this (not that I am advocating it per se) then I suggest that
the generate the names as something like
	owl11aip:xxx
where xxx is a fresh name and owl11aip expands into something in the
owl11 namespace, and also have an axiom of the form 
	InverseObjectProperties(owl11aip:xxx P)

Note that it is not the case that aiP is guaranteed to not collide with
another URI.  An OWL FULL ontology may (stupidly) decide to use URIs in
the owl11 namespace, and may even use a name of the form owl11:aip_xxx
for some xxx that is the encoding of a URI that is also in the
ontology.  This is rather a remote chance, but it is not non-zero.

peter
 

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Subject: Proposal to resolve ISSUE-86 
Date: Sun, 16 Mar 2008 21:30:28 -0400

> 
> 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 Wednesday, 26 March 2008 17:05:04 UTC