Lars, Bart, Michel , Jaap, Edo Ontologies in V-Con Lars, Bart, Michel , Jaap, Edo 2014-12-17 Please, note that we use the perspective of RWS and CB-NL, because these slides will also be used for discussion in NL with CB-NL and within RWS.

Purpose Explain the main structure for ontologies in V-Con Explain the rationale for the structure Explain the relationships with existing ontologies of interest for V- Con: Internationally In the Netherlands In Sweden

Main structure (RWS-View) Specialization (of ontology) Mapping Context ontologies Common ontology Context ontologies Inspire Ifc4Roads (incl. IfcAlignment) International Infra (incl. Top Level) CityGML BSAB NEN 2767-4 TEiP Etim NL-specific (incl. CBNL taxonomy) SE-specific ANDA IMgeo2.0 Provecy RWS-specific TRV-specific RWS-OTL 2.0

Main structure (TRV-View) Specialization (of ontology) Mapping Context ontologies Common ontology Context ontologies Inspire Ifc4Roads (incl. IfcAlignment) International Infra (incl. Top Level) CityGML BSAB NEN 2767-4 TEiP Etim NL-specific (incl. CBNL taxonomy) SE-specific ANDA IMgeo2.0 Provecy RWS-specific TRV-specific TRV-OTL 1.0

2 issues to decide upon in NL General approach to ontologies and place of RWS-OTL in V-Con Sept 2015 Position of CB-NL irt RWS-OTL Ad 1. Basically two alternatives Alt 1: RWS-OTL 2.0 = Common = SUM (top level onto, INT onto, Nat Onto, RWS Onto) Alt 2: RWS-OTL 2.0 = Context ontology of Common ontology (which only has layers: top, int, nat) Ad 2. Basically also two alternatives Alt A: CB-NL is completely incorporated in NL Common (and ….) Alt B: CB-NL is input for NL Common, but remains as a context ontology First we’ll discuss these items separately; later we’ll combine them into one proposal

Development process of Alt 1 Analyse input ontologies (RWS-OTL 1.4, CB-NL, KernGis, IFCRoad, BSAB, TEIP, etc.); if an ontology doesn’t exist yet: develop it Identify shared elements (classes, properties, etc.) Distribute those elements to layered structure of common ontologies; aim at placing shared elements as high as possible Note: the RWS Onto only contains RWS specific extension of the layers above => RWS Onto ≠ RWS-OTL 1.4! Status of the input ontologies after the distribution: Some input ontologies end up completely in the common and disappear (e.g. RWS- OTL 1.4 in this example) Some input ontologies remain as context ontologies (e.g. KernGIS), because they are needed to communicate to someone who ‘doesn’t speak the Common Ontology’

Consequences of Alt 1 Agreement must be reached with higher layers (e.g. on Top Level and Modelling Guide); this might include compromises; this might include losing control => only put restrictions up if really, really necessary; too many restrictions on the higher levels might imply problems for the lower levels! INT onto, Common NL, Common RWS will share the modelling guide and the top level ontology To be more precise: the MG of the lower level ontologies should not contradict MG of the higher level ontologies; they might extend this into extra restrictions e.g. on higher level rules for definition of classes; on lower level also rules for definition of properties Note that you can always define new concepts on the lower level

Issue 1, Alt 2: RWS-OTL = Context Specialization Common ontology Mapping Context ontologies CityGML Context ontologies ifcRoads (incl ifcAlignment) Common International (inc. Top Level) Inspire NEN Common NL Common Sweden BSAB KernGis RWS-OTL 1.4

Development process of Alt 2 Analyse input ontologies (RWS-OTL 1.4, CB-NL, KernGis, IFCRoad, BSAB, TEIP, etc.); if an ontology doesn’t exist yet: develop it Identify shared elements (classes, properties, etc.) Distribute those elements to the layered structure of the common ontologies (Top, INT, NAT) Status of the input ontologies after the distribution: Some input ontologies end up completely in the common and disappear Some input ontologies remain as context (e.g. RWS-OTL 1.4), because they are needed to communicate to someone who ‘doesn’t speak the Common Ontology’

Consequences of Alt 2 For TOP, INT and NAT: Agreement must be reached with higher layers; this might include compromises; this might include losing control INT, NAT will share the same modelling guide and the same top level ontology RWS-OTL 1.4 remains a context; two-way mapping has to be defined with the common ontology To be determined: how to deal with the context ontologies of context ontologies (e.g., KernGis as a context of the RWS-OTL context)

Conclusion of Issue 1. General approach Proposal: We are in favour of Alternative 1. The most synergy NL – Sw The most synergy per country The least mapping Fits best to the scope of the V-Con Solution = support information management of project organisation of a road authority

Issue 2: place of CB-NL Two options Alt A: CB-NL is completely incorporated in NL Common (and ….) Alt B: CB-NL is input for NL Common, but remains as a context ontology In both options, CB-NL is an input ontology => its common elements will be distributed to the INT and NAT-NL ontology of the common ontologies Difference between Alt A and B is the status of the CB-NL after this distribution Alt A: CB-NL ends up completely in the common ontology in the INT and NAT-NL ontology Alt B: CB-NL remains a context ontology Note that CB-NL ‘only’ contains the taxonomy (= definition of classes and properties); for use in V-Con we also need additional restrictions (e.g. which properties belong to which classes, and instantiation)

Consequences of the alternatives for CB-NL Alt A: CBNL = Common INT + NL Less mapping Partly the same top level and MG More compromise RWS-CBNL Easy to explain to the market Alt B: CBNL remains context More mapping Different top and MG (the more difference, the more mapping) RWS and CBNL less dependent Difficult to explain to the market

Conclusion of Issue 2. Position CB-NL Proposal: We are in favour of Alternative A. The most synergy CB-NL and RWS The least mapping Fits best with ambition of RWS in national context (BIR, CB-NL) and internally (RWS-BIM Program) Each ontology can be split into a taxonomy and ‘additional restrictions’

Overall proposal: Alt 1A We propose Alt 1A: Alt 1: RWS-OTL 2.0 = Common = SUM (..) Alt A: CB-NL is completely incorporated in NAT-NL ontology As CB-NL contains the taxonomy, we add an additional NL-ONT ontology, containing other restrictions needed on national level, when instantiating into data sets and transferring these data sets (e.g. with NEN 2767-4) We probably need a similar split between taxonomy and ‘the rest’ on international level This is the most obvious and clear solution; this is our direction; we start working on it and we’ll see how far we get

Issues SE Role of BSAB Role of TEiP Role of ANDA BSAB == Common SE BSAB == A context ontology mapped to a common SE Role of TEiP TEiP == Common TRV TEiP == A context ontology mapped to a common TRV Role of ANDA ANDA == Common TRV ANDA == A context ontology mapped to a common TRV

Proposal for V-Con regarding Swedish ontologies Proposal: Create a separate common ontology at SE and TRV levels using BSAB, TEiP and ANDA as input Pro:s Ensure that common SE and TRV comply with the V-Con modelling guide Easier to make common SE/TRV as ”pure specializations” of common TOP/INT Easier to achieve within the timeframe of the V-Con project. Reduces coupling with activities outside the control of V-Con Ontology development within ANDA can occur as a separate activity Con:s Common SE will not be a sanctioned ontology outside the V-Con project BSAB, TEiP and ANDA will have to be mapped to Common SE/TRV

Methodology for development SE OWL:ify selected parts (for use in V-Con use cases) of the application schema for ANDA OWL:ify selected parts (for use in V-Con use cases) from the BSAB classification (Building elements, Work results) OWL:ify selected parts (for use in V-Con use cases) from the TEiP ontology From the above, extract necessary definitions and add to Common SE/TRV (perhaps only SE level is needed for V-Con?) Make sure that common SE/TRV are properly defined according to MG and in relation to Common TOP/INT. Negotiate definitions to Common INT together with Common NL/RWS In the same process, define mappings between the concepts Provide all schemas and mappings for use in V-Con test cases

Issues international contexts Concepts from IfcRoads, InfraGML, CityGML needs to be OWL:ified and mapped to Common INT Using a documented method (EXPRESS=>OWL, xsd=>OWL, UML=>OWL) May require additions to Common INT Provide ontologies and mappings for use in V-Con test cases bsDD vs OWL ontologies Issue when using IFC with ”dynamic content” Propose to use a way of linking from ”generic” IFC/SPFF (entities/attributes) to ”specific” OWL concepts Reduce the need to involve additional parties in this work Specify and document!