#56 object property domain turns into annotation property domain

[Timothy Redmond]

This is a marginal bug report for a couple of reasons. First, according to the specifications, an attempt to parse the attached file should fail. Second - this issue is indirectly mentioned in a different bug report.

Almost all of the content of the owl ontology is contained in the following two triples:

<owl:ObjectProperty rdf:about="http://protege.org/annotationDomain#p">
<rdfs:domain rdf:resource="http://protege.org/annotationDomain#A"/>
</owl:ObjectProperty>

In particular there is no declaration of A as being a class which is why the ontology is bad. A human reading this file knows that the property domain axiom is an object property domain axiom. But the OWL api - presumably because the domain triple doesn't match the specification the triples that should be translated to an object property domain axiom - decides that this is a annotation property domain axiom.

It would be nice if the OWL api came to the obvious conclusion in this case.

I would completely understand if you marked this bug as invalid. I am looking into the possibility of making a tool that will detect these types of situations and offer to fix them.

[Timothy Redmond]

a bad owl file

[Ignazio Palmisano]

I see the point here but I don't think we can devise a proper and acceptable solution.

We could infer that A is a class due to it being the domain of an object property, but what if A is declared elsewhere as something else? Then problems would arise if the two definitions, the right one and the inferred one, came together - we tried not to do that, because it's unwarranted by the specs and we would get an earache from all the complainers in the mailing list </joke>.

We could, on the other hand, not default to annotations and throw an exception; but then we would be discriminating between this specific noncompliance to the specs in the input and all the other noncompliances that we allow, such as disjoint axioms with only one operand. To be consistent, we should throw exceptions on all these, and again, due to the number of ontologies that are malformed this way, we would get an earache about making this kind of change.

I would like to enforce syntax constraints properly, but this is not going to happen in any incremental work, and I'm afraid it will be met with resistance or require a lot of adapter work to support the transition. Looks like a big feature request more than a bug fix.