SWRL rules saved by older versions of OWLAPI/Protege lose annotations

[ignazio1977]

SWRL rules serialized with old versions of OWLAPI (pre 3.1) and old versions of Protege (3.5, for example) have IRIs. When parsed with recent OWLAPI versions (up to and including 4.0) annotations on such rules are parsed as annotation assertions on the IRI, but the IRI is no longer associated to the rule.

For correct parsing it is necessary to discard the IRI and map the annotations to the rule axiom instead.

[ignazio1977]

Note: This issue cannot be replicated by serializing a rule with the current code base and parsing it again. @matentzn I think that's the issue you met a few months back, in which some files would obstinately fail roundtripping.

[ignazio1977]

Example of a rule that is parsed incorrectly:

<swrl:Imp rdf:ID="test-table5-prp-inv2-rule">
    <swrl:body><swrl:AtomList/></swrl:body>
    <swrl:head><swrl:AtomList/></swrl:head>
    <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">:i62, :i61</rdfs:comment>
</swrl:Imp>

[sesuncedu]

This partially overlaps with the AnnotationAssertion musings I brought up earlier (but only partially).

SWRL rules appear to be a special case of an axiom (which can include internal annotations) that is also an entity (which can have a name).

The regular entity types are not axioms, and regular axioms don't have names (always _:x in the mapping).

There could be a special post-pass for annotations on SWRL rules when parsing, with annotation assertions absorbed into the axiom - SWRL predates punning, so it's legit.

There's a different issue that comes from having a named axiom, which is that annotations could theoretically be made in other ontology documents.

I would suggest absorbing property assertions made on the axiom name in the same document into the internal axiom set, and only generating the long form " type owl:Axiom" (like regular axiom annotations).

The test may not be pure round trippage.

The main implementation hassle is efficiency for documents with a large number of annotation assertions on rules, as the easiest time to do the fix up is when the Internals are built. Since this is a special case, and the check is fast, it's not too big a deal.

It's also important to make sure that no NamedIndividual declarations are generated if we are going to be treating rules as axioms. On Sep 27, 2014 10:13 AM, "Ignazio Palmisano" notifications@github.com wrote:

Example of a rule that is parsed incorrectly:

swrl:bodyswrl:AtomList//swrl:body swrl:headswrl:AtomList//swrl:head :i62, :i61/rdfs:comment /swrl:Imp — Reply to this email directly or view it on GitHub https://github.com/owlcs/owlapi/issues/292#issuecomment-57053875.

[ignazio1977]

The problem is not that rules are axioms, it is that in old implementations they were also named - this makes for strange effects when parsing output from "really old" code (I use quotes there because it's not that the software is obsolete, but it uses OLD OWL API code and SWRL implementations).

SWRL rules are supposed to be a special kind of axiom, but still without names - I have wondered what advantages and problems would come up from having names for axioms. Some users have expressed time and again the desire to identify axioms univocally across ontologies and through roundtrips, and mostly they have to make do with axiom annotations, which is verbose in many cases. We can't stick an IRI on OWLAxiom without having to do a lot more work and take into account things like annotations across ontologies, like you mention above: potentially, things like open world assumption for axiom annotations would start to come out of the woodwork. (Annotations are not supposed to have semantics, but then there are annotation property hierarchies, domains and ranges - I puzzle a lot about the intended purpose)

[sesuncedu]

Adding "name" metadata to axioms using annotations does have the advantage of not exposing axioms as visible entities under DL or less. The names need not be IRIs; they could be data values (even xsd:anyURI).

(Under OWL 2 Full, HasKey() punning on the unique names could infer identity for axioms, but that's a different kettle of ballgames).

Annotations generate inferences under the OWL RDF Semantics, including OWL 2 RL.

Oh, and don't forget about annotations that do more than just add semantics; they change the semantics - ICV import annotations import a set of OWL axioms with CWA and minimized non-UNA ; TrOWL REL:NBox annotations on classes and properties declare the class/property to be closed.

So not all annotations can be safely ignored (maybe these annotation properties need an annotation to say that they must be understood).

As for the purpose of Annotation Axioms ; if you look at something like SKOS labels, you find all sorts of problems (skos-xl label properties end up being data properties ; skos label properties are annotation properties (and sub properties of rdfs:label). This use of annotation properties makes it impossible to express the constraint that there can only be one Concept with a particular preferred label in a given concept scheme (which is a defining characteristic of controlled vocabularies; grrrrr).

[hankiz]

Hi all: I have some problems when create rules, and how I can save the rules file(.rule) in protege4.3 version,

[ignazio1977]

Hi @hankiz, can you provide more details? If you wish you can create a new issue.

[hankiz]

Hi @ignazio1977 ,I first have createde Ontology for one domain use protege4.3,then have write the rules in Rules plug-in in protege4.3.Now how I can save the rules as rules file(X.rules) for ues in jena, after then I can appilication this ontology for semantic retriveling.whish your answer.thanks a lot. I cant past this screenshot here.

[ignazio1977]

I'm not an expert about Jena rules. I've found this StackOverflow question that sounds similar to your issue: http://stackoverflow.com/questions/17357836/using-swrl-with-jena-and-pellet

[hankiz]

Thank you very much,let me see first this page,if you have another sollution please connact me. thanks again.