Should a reference to a non OWL 2 datatype in an annotation cause an unknown datatype violation that catapults O out of OWL 2 DL?

[matentzn]

[matentzn]

I send a message to Bijan Parsia, one of the OWL 2 main editors, and he said, to exactly the question above:

Nope.

There's no point in that. The only called out reasoning is over axioms without annotations. The core constraint on a profile is that we know how to handle reasoning over axioms without annotations.

Now an application might reason over the annotations. So it would be helpful for those applications to know what's in the annotations. But the normal mechanism is to extract them to their own ontology.

[alanruttenberg]

https://lists.w3.org/Archives/Public/public-owl-dev/2017JanMar/0023.html

So far 3 working group members concur that the data type map does not constrain annotations (myself, Horrocks, Parsia)

[matentzn]

I agree. I think that is enough for @ignazio1977 to justify excluding annotations from the profile checks. What about Having to declare OWL entities such as classes when they appear only in comments? @alanruttenberg @ignazio1977

[ignazio1977]

I like the idea of distinct violations and warnings more and more. Repairs can be provided either way.

[matentzn]

I will also lobby for grouping "safe" repairs in the OWL API, once I finished suggesting the ones I have found here. What we really need is a bunch of community-driven repairs that change the ontology in the least possible way while enabling OWL 2 DL profile adherence.

[ignazio1977]

+1

[alanruttenberg]

@ignazio1977 I'm not sure what would be a warning. Either somethings a violation or it is not. If you concur with the emerging consensus, there is nothing wrong with a non OWL 2 datatype as an annotation value.

[alanruttenberg]

I think we should tread carefully with "repairs". I think the OWLAPI used to make silent repairs and I've been bitten by it making a wrong choice - e.g. the whole axiom was wrong and needed to be replaced, not repaired.

So for an API, consider a two-phase thing. 1) Ask what repairs are possible, ideally with easily accessible documentation about why its good and what the consequences are if not doing it
2) User then iterates over possible repairs, deciding which to commit to.

With (1) interface tools would have an easy way to display the proposed repairs for user approval.

But no magic "we will repair obvious mistakes"

[ignazio1977]

I'm not sure what would be a warning

Undeclared annotation properties are a violation, but at the same time the consensus seems to be that, since annotation axioms are not significant for reasoners, there is no need to insist that an ontology missing annotation property declarations is OWL Full rather than, e.g, EL.

However, at parsing time, undeclared properties need to be done something of with - the most conformant behaviour here being to throw a parsing error. Ideally, this would then become a non issue. Trouble is, many ontologies have this kind of problem, and even worse - a few miss data and object property declarations. Default parsing behaviour, to avoid throwing errors, is to consider undeclared properties as annotation properties. But then, silently ignoring the problem means that the reasoners are fed with annotation assertions where the original intent was to create data or object property assertions.

I'm proposing something between silent acceptance of incorrect axioms and profile violations, so that these errors can be reported without having to fail hard in parsing - because that complicates the life of developers who want to use ontologies which are not completely valid OWL 2 ontologies.

[ignazio1977]

I think the OWLAPI used to make silent repairs and I've been bitten by it making a wrong choice

Repairs as the ones defined in the OWLProfileViolation::repair() methods are not applied silently.

anything else happens at the parsing level - trying to resolve ambiguities without throwing parsing errors is the main reason for these to exist. There's a strict parsing option to avoid such attempts and throw errors instead.

[matentzn]

@ignazio1977 Wrt. the issue at hand, is there any resistance to dropping this violation from the OWL API? (non-OWL datatypes in annotations?) Or do we need any more input to make this decision?

[ignazio1977]

I agree it does not need to be a profile breaking violation. I'm looking for a good name for what this, ideally something that would cover everything that is not a significant reasoning issue but does not fall in line with what's expected in the specs.

[matentzn]

Can we simply make the OWL2ProfileChecker derivates configurable so that it ignore violations of non-logical violations for the profile verdict? I do agree with @alanruttenberg that violations are violations. If the spec says it is a violation, the OWL API should treat it as such. But my understanding is that the spec does NOT say that this issue is a violation. So it shouldnt be a warning either. Perhaps it should just be dropped? Or am I missing something. (The same does not go for non declared annotation properties. There what you are saying makes of course sense).