Add an option to round trip rdf:type rdfs:Class

[matthewhorridge]

The OWL API is capable of parsing

:A rdf:type rdfs:Class

as a class declaration. On saving (in an RDF format) this will be saved as

:A rdf:type owl:Class

Some members of the SHACL working group have asked that the typing to rdfs:Class be preserved on round trip. I think this is a reasonable request (they are also not the first to ask for it).

We should consider adding information to the format object to preserve things like this.

[ignazio1977]

Do we want to cater for mixed files, where both rdfs:Class and owl:Class are used?

[matthewhorridge]

Yes I would say so.

[sesuncedu]

Since this is SHACL I won't ask why :)

Is this for RDFS or for OWL 2? There is no provision in the specifications for generating the owl:Class (just the clause in table 5 removing a redundant OWL 1 rdfs:Class.

The parsing of the original construct is thus a lax feature.

I can't remember if there is type inference run on rdfs:Class when determining the OWL metaclass (it would be unusual to bother to declare a datatype in this scenario so just guessing it's a class seems likely).

It would not be unreasonable to add an option to generate an rdfs:Class triple when generating a class. It's not strictly authorized, but the parsing is defined, so the generated files would be barely legal.

It would seem poor form to only generate the rdfs triple, as that would be generating illegal OWL output (accept like Mills, generate like Burkes, and all that).

If the rdfs:Class type is only to be preserved for the ontology document as parsed, then implementation is fairly easy, since it's just another kludge in the format object to record the parsed autocorrect.

An alternative would be to generate an internal annotation on a Declaration for the Class, which would be specially handled when rendering the declaration to RDF. This would allow for the triple to be preserved through non RDF formats.

Which versions of owlapi would this need to target?

[matthewhorridge]

If the rdfs:Class type is only to be preserved for the ontology document as parsed, then implementation is fairly easy, since it's just another kludge in the format object to record the parsed autocorrect.

This is what I was thinking too.

Which versions of owlapi would this need to target?

Version 4 upwards.

[HolgerKnublauch]

Thanks for looking into this. Just to be clear, the issue does not only apply to rdfs:Class, but any other metaclass too. I tried to round-trip an instance of a subclass of rdfs:Class and it appears to work in principle, only that it (Protege5) adds the rdf:type triples owl:Class and owl:NamedIndividual. These two triples are unnecessary as they could be recreated (temporarily) the next time the file is opened, yet they certainly shouldn't be persisted.

[ansell]

An alternative would be to generate an internal annotation on a Declaration for the Class, 
which would be specially handled when rendering the declaration to RDF. This would allow 
for the triple to be preserved through non RDF formats.

Just to clarify, you mean "preserved through non RDF formats in memory only"? I would imagine that we would not actually support round-tripping through the native OWL formats by adding a proprietary Declaration to their concrete documents. That would just create a new round-tripping problem.

[sesuncedu]

The idea:

1. Define an Annotation Property http://owlapi.semanticweb.org/meta/wasRDFSClass
2. If an RDF Parser encounters an rdfs:Class for class :A, create the DeclarationAxiom with an annotation Annotation(owlapi-meta:wasRDFSClass "true"^^xsd:boolean)
3. When rendering to RDF, if a Declaration axiom has this annotation, remove it, and generate a *:x a rdfs:Class triple in addition to the *:x a owl:Class triple.
4. When rendering to a non RDF format, treat the annotation as usual. The generated output will include this annotation, but it can safely be ignored.
5. I am working on some meta-meta-annotations designed to mark extensions that can/cannot be ignored if not recognized; there are existing systems that use annotations in ways that change the semantics (e.g. locally closed classes in TrOWL). It would make it easier to experiment with extensions if required/requested features could be indicated in ontology documents, and plugins such as reasoners could declare supported features (e.g. profile variants, data types,etc.).

Since virtually every single reasoner has some random difference from the standard profiles (otherwise the SPARQL regimes might be usable), it would be nice to be able to handle this using some sort of explicit specification of a conceptualization.

Why is there no ontology of OWL axioms?

Hmm - unless one was created for the test cases?

[ignazio1977]

The idea looks ok for RDF formats, but for non-RDF I see an issue: if the non RDF output is loaded into a non OWLAPI tool, and saved back to RDF by this tool, it will now have an annotation property it did not have before, that all other tools will think is a 'real' property.

I think non RDF output should just ignore it - either declare the class as a rdfs:Class, where applicable, or just as a class. If it's not possible to distinguish between rdfs:Class and owl:Class in a format, then roundtripping through that format will be lossy anyway.

[ignazio1977]

As for an ontology of OWL axioms, there is one, and it has a big comment saying: DO NOT INCLUDE in your ontologies, it will make them OWL Full and bad things will happen.

So, there's that.

[sesuncedu]

"other unexpected consequences" I was surprised- were you surprised? I was surprised.

And it doesn't even give a structural model of the owl axioms ; there's the UML ODM diagrams, which are... unhelpful....

Really need to just do something good enough to be able to represent the standard profiles (and the ones that exist in the wild).

As for the annotation property being loaded from (e.g. FSS , then saved into RDF by a tool that doesn't handle it; it should not break the other tools, and would regenerate the rdfs:Class triple if the file is loaded and saved with OWLAPI.

Since I'm not 100% sure what the intended use case is, adding more magic to the Format object may be what is wanted. Still going to be an owl:Class triple though. I'll try that version and see if it upsets my stomach

[sesuncedu]

Grrr.. Test case bugs.

[sesuncedu]

Trial balloon (which doesn't float) https://github.com/owlcs/owlapi/pull/459

[sesuncedu]

Additional note: SHACL is a square peg, and someone lost all the holes.

[sesuncedu]

And it's all the fault of @pfps . :smirk_cat:

[HolgerKnublauch]

The issues with the OWL API are not limited to SHACL, but apply to RDFS in general. The question that brought me here is that people in the SHACL WG want to use Protege (for better or worse).