Ontology Modification: Expose a method to add Owl and RDF relations to objects

[alelom]

Description:

OWL, RDF, RDFS have rich vocabulary. However, our current translator supports only owl:Class and properties (not types of properties). We should be able to define also owl and rdf vocabulary when creating new objects. Some basics ones that one can add from Ontology Editors (such as Protege) are:

• Between Classes: disjoint With, Disjoint Union Of, Equivalent to;

• Properties types: Functional, Inverse Functional, Transitive, Symmetric, Asymmetric, Reflexive,and Irreflexive.

Here are some extended explanation of class axioms and property definition: • rdfs:subClassOf • owl:equivalentClass • owl:disjointWith

4.2 Relations to other properties o 4.2.1 owl:equivalentProperty o 4.2.2 owl:inverseOf • 4.3 Global cardinality restrictions on properties o 4.3.1 owl:FunctionalProperty o 4.3.2 owl:InverseFunctionalProperty • 4.4 Logical characteristics of properties o 4.4.1 owl:TransitiveProperty o 4.4.2 owl:SymmetricProperty

I suggest for this topic as well, we need to workshop a bit, what is the best/most strategic way to integrate it to our toolkit.

[DiellzaElshani]

To augment the relations between BHoM objects with OWL and RDF vocabulary we can add some components that refine the ontology before converting the cSharp graph to ttl.

In this way we can access all the classes, objects properties, Data properties and individuals. We can design gh components for each of them that allow augmenting the classes, properties , as well as individuals with new information. As base specifications we can use the same specifiations that ontology editors (such as Protégé) use. The workflow can start with setting up two parts: 1) ontology settings, and 2) creating BHoM objects

This two will be used as input in the cSharp graph component, which will make accessible all ontological classes, properties, individuals and other ontology settings.

At this step several components can be used to augment different parts of the ontology. Eg. OWL class settings components A component that takes as input the whole graph, from where we can chose which OWL class we want to edit; and we can define it that class is subclass of some other class, if it’s a disjoint class with another class, etc.

Similarly also with properties, for example the owl object property settings component can look like:

In general such workflow can look like:

[alelom]

@DiellzaElshani sounds good! Just to specify, the CSharpGraph object was designed with this "refinement" workflow in mind, so we can explode it and "refine" its individual properties:

Therefore, the components in your screenshot do not need to take Graph as a first input, but rather the individual property of CSharpGraph that they are refining: Classes, ObjectProperties, DataProperties for the T-Box; IndividualRelations for the A-Box. If needed, we can revise the structure of CSharpGraph in order to ensure that all "refinements" are possible.

Then, the modified Classes, ObjectProperties, DataProperties and IndividualRelations can be merged together in a new CSharpGraph instance, which can finally be converted to TTL via the already existing ToTTLGraph method.

[DiellzaElshani]

I think during the refinement we need to be able to access all Classesand Properties. (E.g. to add one more class as range of an object property, we need to access also the classes in the graph, and not only object properties). That's why I suggested to load the whole graph. However, if we can still access all info from the exploded CSharpGraph that's also fine. We can have a session on this in the upcoming days.