[Task] Investigate re-use of RDF Schema and OWL vocabulary

[kenwenzel]

Is your task related to a problem? Please describe. BAMM introduces many modeling constructs that already exist in RDF Schema and OWL. This makes it almost possible to create BAMM models with existing tools like Protègè, TopBraid Composer and others. It also prevents the application of existing RDFS and OWL reasoners, e.g., for subClass reasoning.

It should be investigated how BAMM could complement existing standards and just add additional features that are required to express digital twin models.

The BAMM example

:Student a bamm:Entity ;
  bamm:extends :Person ;
  bamm:properties ( :studentNumber ) .

:Teacher a bamm:Entity ;
  bamm:extends :Person ;
  bamm:properties ( :employeeNumber ) .

:Person a bamm:Entity ;
  bamm:properties ( :name :surname ) .

could also be expressed as

:Student a owl:Class ;
  rdfs:subClassOf :Person, [ owl:onProperty :studentNumber; owl:cardinality 1 ] .

:Teacher a owl:Class ;
  rdfs:subClassOf :Person, [ owl:onProperty :employeeNumber; owl:cardinality 1 ] 

:Teacher a owl:Class ;
  rdfs:subClassOf [ owl:onProperty :surname; owl:cardinality 1 ]  .

Enumerated types are also possible with OWL. So this BAMM example

:ToggleResult a bamm-c:Enumeration ;
   bamm:preferredName "Toggle result"@en ;
   bamm:description "The possible results of the toggle operation"@en ;
   bamm:dataType xsd:string ;
   bamm-c:values ( "ok" "denied" "unknown" ) .

could be expressed as

:ToggleResult a rdfs:Datatype ;
   bamm:preferredName "Toggle result"@en ;
   bamm:description "The possible results of the toggle operation"@en ;
   bamm:dataType xsd:string ;
   owl:oneOf ( "ok" "denied" "unknown" ) .

Describe the solution you'd like Evaluate if it is possible to better align BAMM with RDFS/OWL to leverage existing modeling tools and reasoners.

Maybe it is possible to mix current BAMM concepts with RDFS/OWL as follows:

:Student a bamm:Entity ;
  rdfs:subClassOf :Person, [ owl:onProperty :studentNumber; owl:cardinality 1 ] .

Using OWL property restrictions would also allow to refine BAMM properties per entity:

:Student a bamm:Entity ;
  rdfs:subClassOf :Person, [ owl:onProperty :hasCourse; owl:allValuesFrom :UniversityCourse ] .

:Pupil a bamm:Entity ;
  rdfs:subClassOf :Person, [ owl:onProperty :hasCourse; owl:allValuesFrom :SchoolCourse ] .

[atextor]

The decision to use RDF as the basis for BAMM but not build BAMM's vocabulary on RDFS (or OWL) was a conscious one. I'll try to summarize the reasons.

• Having a well-defined closed vocabulary for the meta model emphasizes its suitability to serve as the basis for actual implementations. In other words, only by disallowing the common RDF modeling practice modeling of using arbitrary vocabularies, the implementation of robust and interoperable tools working on and with Aspect Models becomes possible. For example, let's say one modeler likes to add element descriptions using rdfs:comment and another likes to use dcterms:description. To reliably generate code, documentation and other artifacts from the model, we have to choose one way to add descriptions and disallow all others. Extrapolate this problem from just adding descriptions to all modeling questions.

• BAMM uses one additional mechanism to decouple model and meta model specifications from infrastructure concerns: All model elements are identified by URNs, not by URLs. While URLs are suitable for the original Semantic Web visions in which resources on the web (which are inherently resolvable on the web) can be described using RDF, in an industrial application it might well be undesirable or even impossible to directly resolve resources from the web. Using URNs thus has two effects: It communicates to modelers that an element is identified, but not resolved, and it forces the application to have a clean model resolution implementation in place, which can retrieve models and model elements from numerous sources, such as local file systems, package repositories, model stores or the web. Despite usage of RDFS being possible nevertheless, this would imply and have modelers expect that they can use third-party RDF/RDFS vocabularies in Aspect Models, which they can not (due to the point mentioned above). Additionally, by definition, all URNs in the meta model itself and as used in the models follow a well-defined structure that includes the version (either of the meta model or the model namespace, respectively). This allows frequent new releases - like actively maintained software - without dilluting semantics when multiple models with different versions reside in the same graph. This would not be possible in a straightforward way when building on third-party vocabularies, because many different ways of versioning are used in the wild (e.g., owl:versionInfo, dcterms:hasVersion, including versions in the URI, etc...)

• Although there are overlaps in meaning between RDFS, OWL and BAMM, they are not identical and while mixing/reusing vocabularies has obvious benefits (tool reuse), this complicates things when we leave modeling and want to implement actual software based on the models. One example between RDFS and OWL: While OWL reuses rdfs:subClassOf to indicate subclass relationsships, it does not reuse rdfs:Class but introduces owl:Class, precisely because it's not the same thing. When building the model, it's no problem, but as soon as you do something with it it can be, in this case it would break inferencing. For BAMM, it would be even more difficult, because BAMM does not follow the open world assumption and furthermore, unlike OWL, imposes the unique name assumption. So to properly express the Aspect Model fragment:

  :Student a bamm:Entity ;
   bamm:extends :Person ;
   bamm:properties ( :studentNumber ) .
  
  :Teacher a bamm:Entity ;
   bamm:extends :Person ;
   bamm:properties ( :employeeNumber ) .
  
  :Person a bamm:Entity ;
   bamm:properties ( :name :surname ) .

  in OWL, you would have to write:

  :Student a owl:Class ;
   rdfs:subClassOf :Person,
     [ a owl:Restriction ; owl:onProperty :studentNumber; owl:cardinality 1 ] .
  
  :Teacher a owl:Class ;
   rdfs:subClassOf :Person,
     [ a owl:Restriction ; owl:onProperty :employeeNumber; owl:cardinality 1 ] 
  
  :Person a owl:Class ;
   rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :surname; owl:cardinality 1 ] ,
                   [ a owl:Restriction ; owl:onProperty :name; owl:cardinality 1 ] .
  
  # Modelers duty: Add owl:AllDifferent for all used leaf classes
  [
   a owl:AllDifferent ;
   owl:members ( :Teacher :Student ) ;
  ] .

  So while this works for the small example, we can see a couple of things here:

  1. Redundancy. I think you can't leave out the a owl:Restriction to have this file work everywhere. The modeler has to manually add cardinalities of 1 everywhere; they'd have to do this for every single Property reference. Keep in mind that semantic modeling experts are not the only target audience of BAMM, but developers are - who are quick to point out the "unnecessary" overhead.
  2. The AllDifferentFrom axiom needs to be added manually by the model author. They would have to do this for all owl:Classes/bamm:Entities. Strictly speaking, this could only be added by the implementor of a solution at the moment the closure of all used model elements is known...
  3. This covers only the small part of semantics where there is a direct equivalent in OWL. What about e.g. abstract entities? You can not express in OWL that you have D subClassOf C with C being "abstract" (in the Java sense) so that a statement "foo a D" is allowed but "bar a C" becomes an error. When going into details of trying to build BAMM on OWL, there are numerous corner cases where this will not work and/or require workarounds in the OWL ontology - see also my comment on #110. This makes it even more difficult to get a model right.

• Additionally, consciously not using the RDFS vocabulary allows for integrated or hybrid systems that use both Aspect Models and OWL: As RDFS semantics must not be used in OWL ontologies (because this results in an undecidable ontology), integration of RDFS-based Aspect Models and OWL-based systems would not be possible. The same holds true vice versa: If BAMM would be based on OWL, integration with systems using purely RDFS semantics would be impossible. With BAMM being a separate vocabulary, you still have the option of custom integration in your runtime system, if that is what you need: E.g., you could state bamm:Entity rdfs:subClassOf rdfs:Class (or bamm:Entity rdfs:subClassOf owl:Class) and bamm:extends rdfs:subPropertyOf rdfs:subClassOf and run your RDFS inferencer or OWL reasoner. In rule-based reasoners you could also customize which kinds of inference rules you want to have in a fine-grained way.

However, all of the above is primarily meant as an explanation of the status quo and does not preclude further developments, including better alignments with RDFS and/or OWL. However, if we address this to reap the obvious benefits (being able to use tools such as Protégé and integration with other OWL/RDFS-focused tooling) we should keep in mind usability, both for developers (read: not too much syntactical overhead) and modelers (read: domain experts which can understand "entities" and "properties" but are not ontology engineers that are aware of all the pitfalls and intricacies of OWL, such as the Open World Assumption, restrictions, profile semantics etc.).