parsing ontologies with duplicate object properties

[DougalW]

Hi, how would OBA handle an ontology with 2 of the same object property on a class?

e.g. the GIST upper ontology defines a class "Physical Substance", with the following two object properties that point to different classes:

'Has Magnitude' some Volume
'Has Magnitude' some Weight

and as rdf:

<!-- https://ontologies.semanticarts.com/gist/PhysicalSubstance -->

    <owl:Class rdf:about="https://ontologies.semanticarts.com/gist/PhysicalSubstance">
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty rdf:resource="https://ontologies.semanticarts.com/gist/hasMagnitude"/>
                <owl:someValuesFrom rdf:resource="https://ontologies.semanticarts.com/gist/Volume"/>
            </owl:Restriction>
        </rdfs:subClassOf>
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty rdf:resource="https://ontologies.semanticarts.com/gist/hasMagnitude"/>
                <owl:someValuesFrom rdf:resource="https://ontologies.semanticarts.com/gist/Weight"/>
            </owl:Restriction>
        </rdfs:subClassOf>
        <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Physical Substance</rdfs:label>
    </owl:Class>

[dgarijo]

@DougalW ,
this is a nice question, and I think we may not have it fully considered in our mapping: https://owl-to-oas.readthedocs.io/en/latest/mapping/#somevaluesfrom-example which considers only one restriction per object property in a class.

Right now, OBA would probably consider only one of the restrictions.

Ideally, I believe that the most we can do is say that the range of the expected property is either volume or weight through allOf; I don't think OpenAPI supports expressing fully the same meaning as in OWL.

@paoespinozarias this would be something to have a look at.

Do you have a suggestion on a concrete mapping, @DougalW?

[DougalW]

@dgarijo this is not an easy issue to solve.

The design philosophy in GIST is to dramatically minimise class sub typing and object property proliferation. This is great from the perspective of having a maintainable and understandable ontological model, but causes this sort of impedance mismatch when translated into JSON.

Perhaps the OBA mapping could treat two or more occurrences of the same object property as being owl:unionOf i.e.:

PhysicalSubstance hasMagnitude some (Volume or Weight)

It's not strictly the same semantics as in the original OWL but might be close enough. If OBA used owl:intersectionOf that's too far from the OWL meaning because we're trying to say that a PhysicalSubstance is allowed to have either Weight or Volume, not the intersection of the two because that doesn't mean anything sensible.

I guess another approach is you could construct a 'synthetic/virtual' object property by concatenating the restriction class onto the end of the object property name, so you would get:

PhysicalSubstance hasMagnitudeVolume some Volume
PhysicalSubstance hasMagnitudeWeight some Weight

A third approach might be to look at how the OWLAPI parses these types of object properties. Protege is written in Java and uses the OWLAPI, and it can handle these cases from the user interface level all the way down into the OWL file itself so it must have some way to represent these axioms and manipulate them.

I also just found the ONT-API which blends Jena with the OWLAPI (https://github.com/owlcs/ont-api/wiki).

[dgarijo]

If you are trying to say that the magnitude can be Volume or Height, why not make the range of the property the union between those two? (which is supported in OBA, btw). I think the only case where that would not work as desired is when the domain is more generic, in which case the some values from property specializes a little bit for this particular class.

In any case, I tend to agree that the anyOf (corresponding to the union in OWL) looks like the appropriate way to go.

Note that the problem is not parsing the ranges, but finding the appropriate way of doing the mapping. We use the OWLAPI in OBA.

[DougalW]

In this case, I'm using GIST as my upper ontology, and have created a business ontology that slots into GIST. GIST is created and maintained by Semantic Arts but they won't modify the semantics of GIST to convert PhysicalSubstance to an OWL union so I'm stuck with the semantics they provide unless I fork GIST, which introduces a maintenance overhead.

I had wanted to follow the GIST approach in my business ontology because it makes for very readable ontologies, something like this:

Product categorizedBy ProductType
Product categorizedBy ProductSpecification
Product categorizedBy ...

and so on, for all sorts of categories that I might use to categorise products. Instead I'll have to use unionOf:

Product categorizedBy (ProductType or ProductSpecification or...) etc, but this makes the ontology harder to read and a bit harder to maintain.

Looking at the YAML spec, the closest thing to these repeated object properties with different ranges, is the Discriminator and Mapping Type Names from this section of the spec:

https://swagger.io/docs/specification/data-models/inheritance-and-polymorphism/

It's a long time since I dived into YAML but perhaps this might work for the mapping?

[dgarijo]

@DougalW,
This is what I was suggesting, to use the anyOf predicate for the mapping, which is the same we use to translate unions in OWL.

[DougalW]

Would that mean my ontology could keep the separate axioms e.g.

Product categorizedBy ProductType
Product categorizedBy ProductSpecification
Product categorizedBy ...

and OBA would map them through anyOf?

[dgarijo]

Yes, when translating them to the right schema, OBA would map them through anyOf. We have not implemented this yet, but I think it would be something we need to incorporate :)

[DougalW]

Sounds great, thanks.

BTW have you tried generating a Java server from the mappings?

[dgarijo]

[Edit]: sorry, I saw whether we offer a server implementation only.

No, we have not generated a Java server yet. But there are extensions of OpenAPI for Java.

We have a Python implementation of OpenAPI generator to create an API that operates completely through JSON, according to what it's specified in the ontology. Details on how to deploy the server are available at: https://oba.readthedocs.io/en/latest/server/