Why are some classes declared differently than others?

[svestal]

My understanding is that all OSLC domain ontologies will contain the ‘oslc_sysml: rdf:type owl:Ontology;’ statement. Many tools recognize and handle this as an OWL model. I have been told OSLC explicitly permits meaningful but non-OWL constructs, e.g., rdf:property instead of OWL datatype, object, annotation properties, so as not to overly restrict things. I have two questions.

Is there anything in the OSLC Core or conventions that discourage or prevent use of fully standard OWL for domain ontologies?

When I opened the sysml/vocabulary ontology in a tool, only some of the classes were listed. This seems to be due to the use of different ways of declaring classes/types. For example, ‘oslc_sysml:RenderingUsage rdf:type rdfs:Class;’ is not listed, but ‘oslc_sysml:FeatureDirectionKind rdf:type rdfs:Class;’ does list FeatureDirectionKind. Is there any reason other statements might affect this?

Hmm, if I change an rdfs:Class to an owl:Class, RenderingUsage is listed. Best speculation now is that when something is used to classify an individual, that somehow entails it is an owl:Class. I’ll look into this more.

[andrew]

@svestal

My understanding is that all OSLC domain ontologies will contain the ‘oslc_sysml: rdf:type owl:Ontology;’ statement.

No, they do not. I fully understand that many tools are hard coded to pick up that triple and won’t work well without it, sorry for the inconvenience. The reason we skipped that declaration is to avoid giving a false impression that we are publishing an OWL ontology while, in fact, we are not. We might have been inconsistent with that with older specs.

@svestal

I have been told OSLC explicitly permits meaningful but non-OWL constructs, e.g., rdf:property instead of OWL datatype, object, annotation properties

OSLC allows OWL constructs, but you have to be the one to add them in line with the RDF AAA principle. If there is anything in OSLC vocabs that causes logical inconsistencies and interferes with OWL reasoning, we should consider it a bug in OSLC vocabs.

@svestal

instead of OWL datatype, object, annotation properties, so as not to overly restrict things.

Actually, it’s the opposite. OWL cardinality constraints, for example, do not sufficiently restrict anything (in the ABox of ground facts aka data that API clients send in) and because of that, OSLC opts for OSLC Shapes or SHACL cardinality restrictions instead. See https://www.bartbogaerts.eu/articles/2021/008-BNAIC-Shacl-DL/ShaclIsADL.pdf for an in-depth treatise on differences between inferrential and model-checking semantics.

We do, however, suggest not to make OSLC API responses dependent on the consumer having an OWL reasoner to interpret the said response. That’s what we would consider overly restrictive.

@svestal

When I opened the sysml/vocabulary ontology in a tool, only some of the classes were listed.

This should be certainly investigated.

[andrew]

Dear @svestal,

I pondered a bit more about your question and did some checks.

First, the only semantic implication of owl:Ontology is rdfs:subClassOf rdfs:Resource and any instance of the former would become an instance of the latter, which is OK. Therefore, we should ensure it is added to every vocabulary and shape file we release, I stand corrected.

Second, I checked out the SysML v2 vocab in the OSLC repo and it does have the declaration you were expecting, see oslc-specs/specs/sysml/SysML-Vocabulary-vocab.ttl at 6e27b40d0f77d9aebd2c722a8655198c59d65ac6 · oslc-op/oslc-specs · GitHub

RenderingUsage: oslc-specs/specs/sysml/SysML-Vocabulary-vocab.ttl at 6e27b40d0f77d9aebd2c722a8655198c59d65ac6 · oslc-op/oslc-specs · GitHub

Finally, regarding the missing classes, I dusted off my trusty Protégé installation (v5.6.3, Pellet reasoner selected) and all classes seem to be in place:

Please check on your side if you are observing the same outputs.

Regarding the TBox statement, I am actually quite interested myself in extending OSLC vocabs with ontological statements (axioms) grounded in an upper ontology like BFO (or in IDO or IOF that, in turn, align with BFO). Potentially, CASCaDE could also be used as a starting point, although UO alignment is pending. The main issue from my side is a non-negligible number of ontology designers think that OWL constraints actually constrain ABox to correct/permissible ground facts, which is not correct and instead is a job for shapes, for example. I would be interested to hear your proposals.

Best regards,
Andrew

[svestal]

Here is what I found. The core.owl file does have an owl:Ontology statement, which causes many tools to treat it as an OWL document. Here is a statement in the core.owl ontology:

oslc:Error a rdfs:Class ;

When an RDF file is loaded in Protege, it is filtered through OWLAPI. This can modify the input to better align with the OWL standard. Here is a modified version of that statement used within, and was saved from, Protege:

oslc:Error rdf:type owl:Class ;

Our tool infrastructure can apply the OWLAPI filter, but the default is to use a Jena OntModel whenever a model declares an owl:Ontology. It appears Jena OntModel more strictly conforms to the OWL standard. I did a find/replace of rdfs:Class to owl:Class in the original core.owl file, and now all the classes are listed as they are in Protege. I’m confident an analogous behavior applies to properties.

I don’t know why asserting an rdfs:Class to have known individuals causes it to be treated as equivalent to owl:Class. I turned off the Jena reasoner and still got that behavior.

Is there a statement that appears in every OSLC domain ontology that flags it as an OSLC domain ontology rather than an OWL domain ontology despite the owl:Ontology statement? Jena has some machinery that can help a tool to manage different subsets of full RDF as different languages.

If a user wanted to use an OWL domain ontology (widely-done, including MBE domains), will tools that work with an OSLC domain ontology also work with an OWL domain ontology?

[andrew]

@svestal

I don’t know why asserting an rdfs:Class to have known individuals causes it to be treated as equivalent to owl:Class.

In OWL 2 Web Ontology Language RDF-Based Semantics (Second Edition) , section §6.4, you can see the set of triples implicitly presumed to be true by a reasoner. A relevant excerpt:

owl:Thing rdf:type owl:Class . # table 6.1
rdfs:Class rdfs:subClassOf owl:Class . # table 6.3
rdfs:Resource rdfs:subClassOf owl:Thing . # table 6.3

Therefore, it is completely legal for the OWL reasoner to infer oslc:Error rdf:type owl:Class in addition to oslc:Error rdf:type rdfs:Class.

Again, the semantics of OWL are inferrential. The range constraint rdfs:Class rdfs:subClassOf owl:Class . means “anything you see that happens to be rdfs:Class can also be assumed to be an owl:Class”. Contrast that to this SHACL shape:

ex:OslcErrorShape
	a sh:NodeShape ;
	sh:targetClass oslc:Error ;
        sh:property [
		sh:path rdf:type ;
		sh:class rdfs:Class ;
	] .

Which means “for an RDF resource that has a type oslc:Error to be valid, it must be an instance of rdfs:Class to begin with”. These are, as you see, are model-checking semantics.

If a user wanted to use an OWL domain ontology (widely-done, including MBE domains), will tools that work with an OSLC domain ontology also work with an OWL domain ontology?

OSLC clients and servers typically know nothing about inference. Therefore, if you want to use ontologies and reasoning in an OSLC ecosystem, my suggestion is to set up an RDFS/OWL reasoner on your server (like the in-mem OWLAPI you mentioned) and set the marshaller to produce output with full entailments. Here is a small example how I can produce a Turtle file with entailments on the command line (you may find ldsw-scraper/data at main · berezovskyi/ldsw-scraper · GitHub moderately useful for manually combining various vocabularies and ontologies for reasoning over their union; riot is a tool from the Jena toolkit):

riot --formatted=turtle --check --strict requirements-management-vocab.ttl \
  ./ldsw-scraper/data/d/dc/terms/dcterms.ttl \ 
  ./ldsw-scraper/data/d/dc/elements/dc.ttl \
  ./oslc-op/oslc-specs/specs/core/core-vocab.ttl \
  ./ldsw-scraper/data/w/w3c/rdf/rdf.ttl \
  owl.ttl \ 
  ./ldsw-scraper/data/v/vann/vann-vocab.rdf .\
  /ldsw-scraper/data/w/w3c/w3c-ldp.ttl > OWL_RM.ttl
riot --check --strict --rdfs=OWL_RM.ttl \
   --formatted=turtle --verbose \
   requirements-management-vocab.ttl > requirements-management-vocab_RIOT_OWL.ttl

Then you can compare two resource definitions. One from the published vocabulary:

oslc_rm:Requirement  a      rdfs:Class ;
        rdfs:comment        "Statement of need." ;
        rdfs:isDefinedBy    oslc_rm: ;
        rdfs:label          "Requirement" .

One with all RDFS entailments:

oslc_rm:Requirement  rdf:type  rdfs:Resource , rdfs:Class;
        rdfs:comment      "Statement of need.";
        rdfs:isDefinedBy  oslc_rm:;
        rdfs:label        "Requirement" .

This allows the consumer to interpret the RDF graph response without a need for OWL tooling (though it is somewhat inefficient and a tad bit verbose).

P.S. Apologies, I hit enter too soon.

[andrew]

I also tried on my Jena Fuseki server. Without reasoning, the response for the DESCRIBE query looks just like the declaration:

With reasoning (Mini OWL reasoner as per Apache Jena - Fuseki: Configuring Fuseki), you see all the entailments:

[svestal]

This turned out to be an issue of how our tool displays and queries a set of ontologies and models in our UI views. Thank you for all your help, I learned a lot about OSLC domains.

The topic of upper ontologies is interesting, so I’ll say a bit more.

Our issue was, in our tool, one view lists a user-selected set of models and ontologies. A user can ask for classes, individuals, properties, property instances defined or used in a specific document. Other views treat that set of documents as a single body of information. Reasoning and queries apply to the set as a whole so users can explore relationships between the different models and ontologies. Reasoning is not applied to an individual document, only to the set of documents as a whole. If I filter an OSLC document through OWLAPI the classes are all listed, but I suspect we will end up querying the umbrella reasoner rather than individual documents.

When we prototyped a tool to convert AADL models to OWL, we ended up with three tiers: an AADL domain ontology based on the language standard (a T-Box), a domain ontology generated from a bundle of AADL packages (modeling languages can define new types) (a T-Box), and models generated for an instantiation of a specific system configuration (A-Box). An instantiated model imports a bundle of packages, and a bundle of packages imports the language ontology.

A possibly interesting curio: PubChemRDF has a vocabulary ontology, which imports a few other ontologies, which import… A full import closure fetches about 50 documents from various sources.

I asked the protege email group if there is any relationship between OWLAPI and the OWL 2 RDF-Based Semantics standard. They vectored me to the OWLAPI email group. If I find something interesting, I’ll let you know.

Is the following right?

The RDF statement ‘owl:Class rdf:type rdfs:Class’ (table 6.1) means owl:Class is a member of the set rdfs:Class.

The RDF statement ‘rdfs:Class rdfs:subClassOf owl:Class’ (table 6.5) means that all members of the set rdfs:Class are also members of the set owl:Class.

A consequence of these statements is that owl:Class is indirectly a member of itself.

I know very little about non-well-founded set theory. Is punning involved here? We do make use of that in some cases.

[svestal]

I experimented with our tool and the core and sysml ontologies. We listed classes using OWLAPI with one parameter setting and properties using Jena with another. We want our software to work with OWL RDF and OWL Direct and multiple syntaxes. With some work I think we could support all, but I think we would need to distinguish which is which. I see that both oslc_core and sysml_vocabulary use a dcterms:hasVersion property (e.g., dcterms:hasVersionOS</dcterms:hasVersion> and dcterms:hasVersionV2</dcterms:hasVersion>) while OWL Direct uses an owl:versionIRI (e.g., <owl:versionIRI rdf:resource=“co-ode.org - This website is for sale! - co ode Resources and Information.”/>). OWL Direct does not require that a versionIRI be present, and often one is not. Will every OSLC domain ontology always include a dcterms:hasVersion property?

Here’s a response from the owlapi list:

Note that this ontology has both an “allowedValue” and “allowedValues”, the second is recognised by Protege to be implied object propertyl as it has a range of AllowedValues which is defined as a class. However the first singular form, has no defined domain or range, and is not used on any other statements.

So by the open world assumption and OWL2-RDF specification there is no way to say what kind of property it is meant to be. You could argue it should then be recognised as an Individual, but i think that is avoided by the OWL API code for good reason.

What I would recommend, if you can’t convince the OASIS/OCLS maintainers to declare their OWL ontology in OWL, then use a quotation to define the property in OWL yourself. Use rdfs;isDefinedBy to define the original source, and owl:import to get the rest (e.g. label, range).

http://www.semanticweb.org/stain/ontologies/2025/0/untitled-ontology-21 rdf:type owl:Ontology ;
owl:imports http://open-services.net/ns/core# .

http://open-services.net/ns/core#allowedValue rdf:type owl:AnnotationProperty ;
rdfs:isDefinedBy http://open-services.net/ns/core# .

After reloading in protege, you get the remaining annotations (rdfs:label, rdfs:comment) loaded from the OWL import (label, comment) and the property is listed under Annotation properties.

Note that if the owl import brings in lots of things you don’t want, just expand the quotation to include just enough.