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]

No description provided.

[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).

[ignazio1977]

Wait - I'm missing something. Is the violation you're seeing for a non OWL2 datatype, or an /undeclared/ non OWL2 datatype?

A new, declared datatype should be no problem. An undeclared datatype is the same kind of issue as an undeclared anything else - can be a problem at parsing time. For annotation values, I feel it's probably irrelevant and could be skipped during validation, but I suspect it might be a mistake the author has not realised they've made.

[matentzn]

The issue was using xsd:date in an ontology annotation (I think like an annotation that said when ther version was created).

[ignazio1977]

Right, so I think the problem is a lack of declarations. Can be fixed easily enough.

[matentzn]

<dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2002-05-30T09:00:00</dc:date>

[matentzn]

That caused the violation.. I am not certain. If I understand the spec correctly, the object of an assertion is interpreted as an IRI and does not need any kind of declaration...

[ignazio1977]

the object of an assertion is interpreted as an IRI and does not need any kind of declaration

An IRI as object is interpreted as IRI. A literal is interpreted as such. I believe annotations used to be skipped but someone raised that as a bug - ironically enough.

[alanruttenberg]

However, at parsing time, undeclared properties need to be done something of with - the most conformant behaviour here being to throw a parsing error.

Just to be clear, something needs to be done for undeclared properties in annotations only in the RDF serializations, right? In the other syntaxes you could very well simply ignore the annotations when it comes to profile checking because they are unambiguously annotations.

[ignazio1977]

only in the RDF serializations

Indeed, the other parsers are mostly not affected.

[alanruttenberg]

But the profile checks happen after the parsing, right? If a property is used in an ontology annotation, but not declared, would that not currently trigger a profile violation even if the ontology was written in functional syntax?

Ontology(<http://example.com/ont> Annotation(<http://example.com/p> <http://example.com/o>))