Aligning two ontologies with an "adapter"

Question

Simplifying a little, I have a domain ontology (D) expressed in OWL, which describes devices, their capabilities, configurations. Also, for each vendor I would like to have vendor-specific ontology (V), which would be connected to the domain one. The question is, how to align D and V? Is it feasible to leave V as near to the vendor terms as possible or just subclass D's classes to V (and possibly do the same for data properties and object properties)? The idea is that application uses ontology D for queries and inference mechanisms hide the vendor specifics as much as possible.

The first variant seems more logical (after all, semantic technology is about interconnecting), but I can foresee some mismatches in some datatypes. For example, one vendor can express battery levels by percent, another one uses words like high, medium, low. I am not sure how to bring such data to the common denominator using OWL. There maybe even harder cases, requiring regex application and whatever scripting voodoo is usually done. (It is also interesting detail whether to use dataproperties directly or add one more layer of indirection by "wrapping" dataproperties with object properties and concepts per dataproperty to be more prepared for typemismath).

In other words, it seems like the input data should be pre-processed before entering the RDF ecosystem... Or maybe there are other possibilities?

(for those who tend to be quick marking the question as a duplicate, I am not asking something like mapping between two ontologies , but rather arranging for "alignment" as pre-processing vs. richer "adapter pattern" in the OWL itself)

Answer 1

In general, you'd connect the two ontologies by creating a new ontology, O, that imports both D and V, and defines a bunch of axioms relating the classes and properties within them.

The first variant seems more logical (after all, semantic technology is about interconnecting), but I can foresee some mismatches in some datatypes. For example, one vendor can express battery levels by percent, another one uses words like high, medium, low. I am not sure how to bring such data to the common denominator using OWL.

This is actually a case that you could handle in OWL. For instance, suppose that V1 has an object property hasPowerLevel that relates a Battery to one of the individuals High, Medium, and Low. Suppose that V2 has a datatype property hasPercentageRemaining that relates a PowerCell to an integer in the range [1,100]. You'd first start by determining the relationship between Battery and PowerCell. This could be any of the following, for instance, or something else entirely. It would depend on the particular semantics of the classes.

    Battery ⊑ PowerCell
    PowerCell ⊑ Battery
    PowerCell ≡ Battery
    Battery ⊑ PowerCell ⊓ ∃ hasPowerSource^-1

Then you'd have to relate the properties. This could be along the lines of

    (hasPowerLevel value High) ≡ (hasPercentageRemaining some integer[>= 66])
    (hasPowerLevel value Medium) ≡ (hasPercentageRemaining some integer[<= 66, >= 33])
    (hasPowerLevel value Low) ≡ (hasPercentageRemaining some integer[<= 33])

That's just one example, but it shows that you can actually do a lot of this "bridging" within OWL. hasPowerLevel

There maybe even harder cases, requiring regex application and whatever scripting voodoo is usually done. (It is also interesting detail whether to use dataproperties directly or add one more layer of indirection by "wrapping" dataproperties with object properties and concepts per dataproperty to be more prepared for typemismatch).

Those OWL datatype facets (e.g., how we specified ranges of integers) can also handle regex restrictions. That said, it's true that it may often be easier to do some amount of intermediate connecting before uniting everything within OWL. SWRL rules can be helpful here, as can dropping things down to the RDF level and doing some rule-based processing with SPARQL or SPIN.

While there's lots of research in this area, there's not really any magic bullet or solution that will work everywhere. Anything that claims to be universally applicable is going to be so very high level that its practical application will require answering most of the same questions you're already asking. There are some general methodologies that might be useful, but we'd really need some specific situations to be able help with those.