We fielded several questions as part of our recent webinar (recording available here): Interoperable Physical Asset Data Management and Digital Twins using Knowledge Graphs. The list below includes questions we were able to answer during the webinar as well as questions we did not get to in the webinar.

1. What happens if the customer’s OTL gets updated.  Do I need to start from scratch?

No, you don’t have to start from scratch. If you have one crosswalk, you can go into it and create a copy of it for the new version. And the second way to tackle this is by exporting and mapping and then reimporting apps into a newly created crosswalk.  So you do not have to start from scratch, you can re-use what you’ve already got and build on top of it.

2. You mentioned some standards in the construction and asset management area.  Are there more such standards existing or in development?

There is a whole slew of standardization efforts going on, both from national levels and internationally. For example, ICT D is an ISO standards for exchanging building data and TC 442  is a semantic model new standard for the construction world. There is also the Serif family of standards that is coming up. So, yes, there are many, many standards around, and, of course, the nice thing about standards is that you have so many of them to choose from.  This shows that there is a real need for interoperability. And also, a growing awareness, that Knowledge Graph technology RDF is the key to this problem.

3. Is it possible (and has it to be avoided) to have a 1 to n mapping between classes of the two ontologies?

Generally speaking, a crosswalk can capture n to n mappings because:

Resource 1 could be mapped to Resource 2 and Resource 3

Resource 4 could be mapped to Resource 2

Crosswalk does not support 1-n mappings if that means ConClass 1 instances are mapped to a network of linked instances of GridClass 2, GridClass 3 and GridClass 4. That is a case where a rules-based data converter is likely required.

However, in the case where what’s actually happening is that sub/super classes are missing from one or the other OTL, then often sub/super classes are added to one or both so that the mapping can be 1-1. In that case, since instances of a class are also instances of all its superclasses then the two-view approach shown in the demo can still work.

4. What is the mapping effort between the OTL and the authoring tools data models? Is it the same kind of mapping that is needed?

In the OTL examples shown in the demo, an underlying ontology called the Basic Semantics contology was used and the OTLs are build upon that structure. Therefore, the OTL classes can be directly used in the “authoring tools data model”. However, as was shown in the Inspection demo, that standard Physical Object data model structure can be reused in a more typical bespoke data model that wraps the underlying standard one.

If the question is about the BIM/CAD/SAP/etc data models and how they are mapped to an OT for exchange, then that is a question about writing a data exchange importer/export capability. Typically, that kind of software development ranges from a few days to couple of weeks to a couple of months of effort.

5. Why are crosswalks better than creating a mapping ontology where you use owl:equivalentClass for example?

There is a different degree of semantic commitment and meaning when using owl:equivalentClass mapping versus skos:exactMatch/crosswalk:exactMatch/“some other custom predicate”.

OWL equivalent class says all members of Class A are also members of Class B, and vice versa, and adds rdf:type statements to make that so – always in both directions. That’s what happens when an OWL reaonser is run over the data. In that case, all properties Class A and Class B appear all the time when looking at an instance and all restrctions/constraints of both Class A and Class B are applied to all data instances all the time. This is the ontology alignment approach that Jan mentioned during the Webinar. That may be useful to some organisations in some scenarios but has obvious limitations as you’ve merged two full ontologies into one and modified the data to use both sets of classes.

The OTL mapping using Crosswalks case is a somewhat different scenario. There are large libraries of classes for the same real world thing managed by multiple organisations. There is very often a one-to-one mapping because the kinds of physical objects are so standard in the BIM/Infrastructure/Building and Construction industries. The approach is not trying to solve the general ontology alignment case with all its complexity, but is instead handling a more standardised case and so a simpler approach makes more sense.

Because the very far reaching level of semantic commitment of the owl:equivalentClass statements, it has become a norm in the industry to use other predicates when capturing mappings between different vocabularies. Having said this, EDG will let you select a predicate to use, so, if desired, you could use owl:equivalentClass to capture crosswalk mappings.

6. How were the instances in the “Data Graphs” generated? Automatically or manually?

In general data like what as demod is created in native BIM/CAD/SAP/etc. applications and then pushed or linked in the CMDB via an XML/Spreadsheet/RDF importer or via direct integration using Web services.

7. Once the mapping is done between 2 OTLs, is it possible to export them under RDF format?

Yes, they are stored natively as RDF.

8. Is it possible to connect/map more than 2 OTLs?

The EDG Crosswalks UI supports a mapping between two OTLs at a time. However, if you have OTL1-OTL2 crosswalk built and then have an OTL2-OTL3 crosswalk built it is very simple to infer the OTL1-OTL3 crosswalk. A simple SHACL rule as was shown in the Inspection demo can do that inference in EDG.

Once you bring the two crosswalks together, you effectively have the third one.

‍