V-Con Technical Specification End of Project...Technical Specification, End of Project March 31st, 2017 4 1.2 Overview of PCP documents The Technical Specification is the part of the

Technical Specification, End of Project

March 31st, 2017 1

V-Con

Technical Specification

End of Project


March 31st, 2017 2

Content

1 INTRODUCTION ...................................................................................................................................... 3

1.1 PURPOSE OF THE DOCUMENT ........................................................................................................................ 3 1.2 OVERVIEW OF PCP DOCUMENTS ................................................................................................................... 4 1.3 STRUCTURE OF THE TECHNICAL SPECIFICATION, PHASE 3 .................................................................................... 4

2 TERMS AND ABBREVIATIONS ................................................................................................................. 5

3 V-CON APPROACH ................................................................................................................................. 8

3.1 ORGANISATIONAL CONTEXT AND SCOPE: INFORMATION MANAGEMENT ON A ROAD AUTHORITY’S PROJECT ................... 8 3.2 APPLICATIONS AND ONTOLOGIES ................................................................................................................... 9 3.3 SYSTEM BOUNDARIES AND INTERFACES ......................................................................................................... 10 3.4 HYBRID APPROACH.................................................................................................................................... 11 3.5 LAYERED MODELLING IN THE COMMON ONTOLOGY ......................................................................................... 14 3.6 CONNECTING COMMON AND CONTEXT DATASETS .......................................................................................... 15

4 KEY TECHNICAL CHALLENGES ............................................................................................................... 17

4.1 TC1: SUPPORT ONTOLOGY-BASED HANDLING OF DATASETS .............................................................................. 18 4.2 TC2: SUPPORT HANDLING DATASETS IN NON-LINKED DATA FORMATS ................................................................. 19 4.3 TC3: MANAGE AND STORE DATA STRUCTURES AND DATASETS ........................................................................... 20 4.4 TC4: CONNECT DATASETS FROM DIFFERENT DOMAINS ..................................................................................... 21 4.5 TC5: VIEW (CONNECTED) INFORMATION ...................................................................................................... 25 4.6 TC6: ENSURE SYSTEM QUALITY ................................................................................................................... 25 4.7 TC7: ENSURE A FUTURE PROOF SYSTEM ........................................................................................................ 26 4.8 GENERAL ICT REQUIREMENTS ..................................................................................................................... 27

5 SUGGESTIONS FOR (NATIONAL) ROAD AUTHORITIES ........................................................................... 28

5.1 APPLYING THE V-CON RESULTS.................................................................................................................... 28 5.2 RELATED INITIATIVES ................................................................................................................................. 29

INTRODUCTION TO ANNEXES ............................................................................................................................... 30

ANNEX TC1: SUPPORT ONTOLOGY-BASED HANDLING OF DATASETS ................................................................... 31

OWL 2 ONTOLOGY LANGUAGE ................................................................................................................................. 31 ONTOLOGIES AND LINKING RULE SETS PHASE 3 ........................................................................................................... 32

ANNEX TC2: SUPPORT HANDLING DATASETS IN NON-LINKED DATA FORMATS ................................................... 34

ANNEX TC4B: CONNECT AND TC5: VIEW (CONNECTED) INFORMATION ............................................................... 35

ANNEX TC6/TC7: ENSURE SYSTEM QUALITY AND ENSURE A FUTURE-PROOF SYSTEM ......................................... 36

SOFTWARE DESIGN PRINCIPLES ................................................................................................................................. 36 ARCHITECTURAL DESIGN STYLE GUIDELINES ................................................................................................................. 37

ANNEX A: FIGURES AND TABLES ........................................................................................................................... 39

ANNEX B: EXPLANATION OF TEST SCENARIO........................................................................................................ 40

ANNEX C: RIJKSWATERSTAAT’S GENERAL ICT REQUIREMENTS ............................................................................ 43

ANNEX D: TRAFIKVERKET’S GENERAL ICT REQUIREMENTS ................................................................................... 44

ANNEX E: INFORMATIVE REFERENCES ................................................................................................................. 45

ANNEX F: LINKS TO THE TECHNICAL V-CON DOCUMENTATION ............................................................................ 47


March 31st, 2017 3

1 Introduction This document includes the final version of the V-Con approach and its Technical Challenges. It is intended to be used by future principals and contractors for the development and application of V-Con-like solutions. The original Technical Challenges were to be met by the Contractor for the pre-commercial V-Con Solution in Phase 3 of the V-Con project. In this final version the lessons from V-Con Phase 3 are incorporated. This final version of the Technical Specification is the refinement of the Technical Specification, Phase 3 (V-Con TS P3, 2016)1. For the introduction and background to the V-Con PCP, please see the Invitation to Tender (V-Con ITT P1, 2015) and accompanying documents.

1.1 Purpose of the document This document is intended to be used by future principals and contractors for the development and application of V-Con-like solutions. The Technical Specification defines the Principal’s requirements and the technical constraints on the V-Con Solution. During the tender phase (Phase 0) and solution design phase (Phase 1), the Contractors used the first version of these requirements to design their solutions: Technical Specification, Phase 1 (V-Con TS P1, 2015). In the prototype phase, Phase 2, the Contractors used the Technical Specification, Phase 2 (V-Con TS P2, 2015) to develop and test their prototype V-Con Solutions. In the solution phase, Phase 3, the Contractor used the Technical Specifications to develop, test and demonstrate a pre-commercial version of its V-Con Solutions. In this final document the Principal has incorporated the lessons from Phase 3 to update the V-Con approach and the Technical Challenges. The content, which was specific for testing the V-Con Solutions in Phase 3, has been removed from this document. When the Test Scenarios are mentioned in this document, they refer to the Test Scenarios of Phase 3 of the V-Con project, as described in (V-Con TS P3, 2016).Of course, the test information is still available for reference and inspiration of future V-Con-like solutions2.

1 In annex E, references to informative documents can be found.

2 In annex F, references to the documentation used in the V-Con project can be found.


March 31st, 2017 4

1.2 Overview of PCP documents The Technical Specification is the part of the V-Con procurement documents (see Figure 1) that adds the technical (ICT) point of view to the overall challenge and business perspective described in the Challenge Brief and the Business Specification.

Figure 1 Document structure for the V-Con Pre-Commercial Procurement process

1.3 Structure of the Technical Specification, Phase 3 The Technical Specification is structured as follows:

• Chapter 1 introduces this document.

• Chapter 2 gives an overview of the terms and abbreviations used in this document.

• Chapter 3 describes the approach of V-Con.

• Chapter 4 describes the Technical Challenges for the V-Con Solution.

• Some of the Technical Challenges are explained further in the annexes. The TC annexes describe the choices made by the Principal on refining these technical challenges for the V-Con project.

• Finally, the annexes contain general overviews, such as a list a figures and tables (annex A), a list of informative references (annex E) and links to the technical documentation (annex F).


March 31st, 2017 5

2 Terms and abbreviations Terms that are capitalized in this Technical Specification are defined in Schedule 1 (Definitions) (V-Con ITT P1, 2015), in the Business Specification (V-Con BS P2, 2015), or in the table below.

Term Abbreviation Definition

BSAB BSAB Swedish classification system for buildings and their parts. Based on ISO 12006-2.

building Smart International

bSI buildingSMART is a worldwide organisation developing open, international standards such as IFC

Computer Aided Design

CAD The use of computer systems to assist in the creation, modification, analysis, or optimization of a design.

CityGML CityGML A common information model and XML-based encoding for the representation, storage, and exchange of virtual 3D city and landscape models

Common Dataset A Dataset that is associated to a Common Ontology containing objects and their properties that need to be exchanged or shared between different contexts or used for linking data from different contexts.

Common Ontology A Ontology containing a minimal set of those concepts that two or more Context Ontologies have in common. Context ontologies can more efficiently linked together through a Common Ontology reducing the amounts of Linking Rules Sets.

Concept Modelling Ontology

CMO A generic reusable upper ontology extending OWL capabilities for conceptual modelling, including annotations, decomposition and quantities/units.

Construction company

Any contractual partner in a road project launched by a road authority, including, e.g. construction, engineering and project development companies

Context Dataset A Dataset that is associated to a Context Ontology. Some of this data can be unique for the context, while some of it can overlap with other contexts and can be exchanged or shared efficiently between contexts through a Common Dataset.

Context Ontology A Context Ontology is an Ontology typically representing an existing view from a given standard or software application like IFC or CityGML. Sometimes ontologies are available but often they have to be derived from specifications in other formats like EXPRESS or XSD.

Conversion (of datasets)

Transformation of a dataset associated to one ontology (‘source’) to a dataset associated to another ontology (‘target’), as defined by a Linking Rule Set of the ‘source’ ontology to the ‘target’ ontology. The data format stays the same when converting.3

Convertor A component of the V-Con Solution which performs the Conversion (change of data structure) of datasets.

Data structure Class-level definition of the structure (sometimes ‘semantics’) of a dataset. It can cover real world objects and properties but also their explicit shape representations (‘geometry’).

Dataset Collection of objects (in semantic web terms: ‘individuals’) level, structured associated to a data structure (in semantic web terms: ‘ontology’).

3 See section 4.4.1.


March 31st, 2017 6


EXPRESS A standardized language for specifying product data models. EXPRESS is formalized in the ISO Standard for the Exchange of Product model data (STEP).

eXtensible Mark-up Language

XML A mark-up language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable.

Information Delivery Manual

IDM a methodology that describes an interaction framework for information exchange - ISO 29481-2:2012; in the Netherlands also known as VISI

Industry Foundation Classes

IFC International open standard for building product information data structures

ifcOWL ifcOWL The semantics of the IFC now not represented as an EXPRESS schema but as ontology in OWL.

Linking Dataset Specification of how objects of one dataset are related to objects in another dataset (and vice versa). For instance, in a Linking Dataset, it can be indicated that two individuals are “the same”, which implies that both individuals refer to the same real-life object; which information can be used to collect and combine data on the same object from different views.

Linking Rule Set LRS Specification of how classes and properties of one ontology are related to classes and properties of another ontology (and vice versa). Sometimes also called Linking Ontology. For instance, in a Linking Rule Set, it can be indicated that two classes are “equivalent”, which implies that both classes refer to the same set of objects; which information can be used to convert data associated to one ontology to data associated to the other ontology. Two types of LRS can be distinguished: Alignment Ontologies (AO) for “data enrichment” (in a limited OWL subset) and Conversion Rule Sets (CRS) for “data conversion” (in OWL/SPIN).

Matcher Software functionality recognising that two objects refer to the same real-world object.

Metadata In this document, the term metadata is used to indicate data about datasets: who created the dataset, what is its version, status, reliability, etc. Other interpretations might use the term metadata for the ontology the data is associated with, or data about the ontologies etc.

Mini Case MC A small scenario involving some key technical challenges that had to be supported in Phase 2.

Modelling and Linking Guide

MLG A guide on how to apply the W3C Linked Data approach and related Semantic Web technologies like RDF, RDFS and OWL when developing and interconnecting ontologies/data sets in V-Con.

Object A data instance referencing a specific real-world object (‘something you can or could point at’); in OWL terminology this is referred to as an ‘individual’.

Object Type The type of an Object; in OWL terminology this is referred to as a “Class”. Sometimes called a “Concept”. Objects can be classified according to multiple Object Types.


March 31st, 2017 7


Ontology An ontology is an abstract, simplified view of a part of reality to be represented for some purpose. An ontology is essentially a set of Concepts, Properties and Relationships, or in Linked Data-terminology: a set of Classes, Datatype Properties and Object Properties respectively. Furthermore it contains Datatypes (as ranges for the Datatype Properties) and all kinds of Restrictions. Sometimes an Ontology is referred to as an Object Type Library. In V-Con we distinguish Context Ontologies and Common Ontologies.

Product Life Cycle Support

PLCS ISO 10303-239, an international standard that specifies an information model that defines what information can be exchanged and represented to support a product through life.

Reference design Ontologies, linking rule sets and datasets provided by the Principal, intended for the Contractor to copy. They contain the essentials for executing the Test Scenarios. The Contractor may enhance or modify them as required, as long the essentials are adhered to.

Resource Description Framework

RDF RDF is a standard model for data interchange on the Web. RDF has features that facilitate data merging even if the underlying schemas differ, and it specifically supports the evolution of schemas over time without requiring all the data consumers to be changed.

Rijkswaterstaat Object Type Library

RWS-OTL Object Type Library developed and applied by Rijkswaterstaat.

SPARQL Query language for RDF

STEP Physical File Format

SPFF A textual data file format defined by the ISO STEP standard (ISO 10303-21) that defines the encoding mechanism on how to represent data valid against a certain EXPRESS schema.

Technical Challenge

TC High level technical requirement, described in chapter 4of the Technical Specification, encompassing a set of lower level requirements.


TS The specification of technical requirements for the V-Con Solution.

Test Scenario A number of tests defined for each Business Use Case, described in a table.

Translation (of datasets)

Transformation of a dataset according to one format into a dataset according to another format, without changing its data structure. Translation may also concern transformations needed when the same format but different modelling approaches for the same conceptual notion have been used.4

Translator A component of the V-Con Solution which performs the translation (change of format) of datasets.

Turtle Terse RDF Triple Language, a compact textual form of an. RDF graph, made up of triples consisting of a subject, predicate and object.

Web Ontology Language

OWL The W3C Web Ontology Language is a Semantic Web language designed to represent rich and complex knowledge about things, groups of things, and relations between things.

World Wide Web Consortium

W3C The World Wide Web Consortium (W3C) is an international community where member organisations, a full-time staff, and the public work together to develop Web standards.

4 See section 4.2.


March 31st, 2017 8

3 V-Con approach This chapter begins by describing the organisational context and scope of the V-Con Solution. It will then go on to explain the V-Con approach.

3.1 Organisational context and scope: information management on a road authority’s project

The organisational context of the challenge is defined in the Challenge Brief (V-Con CB P1, 2015) and the Business Specification (V-Con BS P2, 2015) as the management of a construction or maintenance project by a road authority. The scope of the V-Con Solution is to support information management in this context. The Business Specification describes three business use cases, which are a typical set for the many business use cases Rijkswaterstaat and Trafikverket envision to be supported by the V-Con Solution. The three initial business use cases include communication with: the asset management department; with employees involved in such a project; and with the construction company (as pictured in green in Figure 2). Communication with traffic management, the third core business of a road authority, will become relevant for future developments of the V-Con Solution. Please note that the term “construction company” is used in a broad sense: it stands for any contractual partner in a road project, launched by a road authority, including amongst others: construction, engineering and project development partners.

Figure 2 Organisational context of the V-Con Solution: road authority’s core functions, with green objects indicating the scope of the V-Con Solution. The red circles represent software applications.


March 31st, 2017 9

As Figure 2 depicts, the V-Con Solution supports information management at a road authority’s project organisation. Therefore, the V-Con Solution has interfaces with:

• other project management software applications;

• software applications of a construction company (or companies);

• software applications of the road authority’s asset management department.

3.2 Applications and ontologies Based on the Business Specification, Figure 3 presents the type of applications that are to be expected in the organisational context of the V-Con Solution: Systems Engineering and project management applications within the project organisation; design and BIM5 applications within the construction company’s organisation; and asset management and GIS applications in the Road Authority’s asset management organisation.

Figure 3 Possible applications and ontologies in the organisational context of the V-Con Solution

5 In the industry, the term BIM is used for different scopes, ranging from ‘just’ the design by the construction company to all information in the infrastructure sector. In this chapter, the term BIM is used for the design and engineering information provided by the construction company.


March 31st, 2017 10

Figure 3 depicts that (in this example):

• the V-Con Solution interfaces with applications for design, construction, maintenance and operation (as typically used by a construction company);

• the V-Con Solution interfaces with Systems Engineering (SE), project management, GIS and asset management applications of the road authority.

Ontologies for road infrastructure play a central role in the vision of V-Con, since they serve as the data structure (semantics) of the datasets that are exchanged/shared with the V-Con Solution. Data structures in general contain object types, property types and relationship types. In the OWL domain, data structures are represented by ontologies, containing classes, data type properties and object properties. The exchange/sharing of datasets for V-Con will be based on a set of interrelated ontologies for road infrastructure. These ontologies are specified and will be made available through the Internet by the Principal. For example, the concept of a guardrail is defined as a class with its relevant properties in an ontology. If the data exchange between the road authority’s project organisation and the construction company contains the dataset on a specific guardrail, then the data structure of this guardrail is defined by the ontology. This is represented in Figure 3 as grey curved arrows from the ontology that defines the data structure of the dataset being exchanged/shared through the V-Con Solution.

3.3 System boundaries and interfaces The ambition of the Principal is to use the open information exchange standards in the V-Con Solution that are relevant for road infrastructure projects (V-Con D3.1, 2013) (V-Con D3.2, 2013). These standards prescribe the data structures and the formats (the syntax, languages) to define the data structures and datasets. Relevant standards cover domains such as Geographical Information Systems (GIS), Computer-Aided Design (CAD), Building Information Models (BIM), Systems Engineering (SE) and national infrastructure-related classification systems or Object Type Libraries. The Principal provides a selection of these relevant standards upon which to base data exchange / sharing with the V-Con Solution in Phase 3. The Principal provides the ontologies corresponding to the data structures of the selected standards. To ensure compatible ontologies, the Principal has drawn up a Modelling Guide (MG)6, to which the common ontologies should comply, and a Linking Guide (LG), describing how to connect datasets. Annex F describes where the guides, ontologies, linking rulesets and datasets can be found. In conclusion, it is important to note the following preconditions with respect to the use of standards in V-Con:

• the domains covered by these standards have many overlaps;

• the list of standards the road authorities want to use will change over time;

• the standards themselves will evolve over time.

6This is a refinement of (V-Con D3.4.1c, 2014)


March 31st, 2017 11

3.4 Hybrid approach To be able to deal with this multi-standard world, with continuously evolving, overlapping and changing standards, the Principal has decided to adopt a so-called hybrid approach. The motivation for this hybrid approach is reported in V-Con D3.2 (V-Con D3.2, 2013). The hybrid approach uses the strengths of existing open standards (which are all under development and at different maturity levels). It connects these standards using the Linked Data approach with ontologies in OWL2 (W3C, a), available through the Internet. Elaboration of the hybrid approach with multiple domain standards in the example context of Figure 3 leads us to Figure 4.The light blue area illustrates the scope of the V-Con Solution.

Figure 4 A look inside the V-Con Solution

Figure 4 depicts that the V-Con Solution is able to deal with multiple sets of data, each defined in its own domain standard by an ontology in OWL2. One dataset is defined as the Common Dataset; a dataset that is associated to a Common Ontology. This Common Dataset contains objects and properties that need to be exchanged or shared between different contexts, or used for linking datasets from different contexts. The Context Datasets are connected to each other through the Common Dataset. The Context Datasets are associated to a Context Ontology. Typically, they are derived from an existing data structure, such as IFC2x3 or CityGML2.0. Part of this data can be unique for


March 31st, 2017 12

the context. Part of this data can overlap with data in other contexts. Both parts can be linked through the Common Dataset7, as described in section 3.6. Managing the links between objects that refer to the same real-life objects to ensure that complementary data can be found, as well as managing overlapping data in different datasets, are key functionalities of the V-Con Solution. Connections between Common and Context Datasets are defined in Linking Datasets, which are specifications of how objects and properties associated to one ontology are related to objects and properties associated to another ontology (and vice versa). The V-Con Solution interfaces directly with software applications that comprehend the data format of W3CLinked Data (indicated in Figure 4 and Figure 5). An overview of W3C ontologies and related document formats is given in annex TC1, Figure 9.The V-Con Solution also interfaces with specific software applications that only comprehend the data format of one of the selected context standards (as defined in annex TC2). This example features a BIM application and a GIS application (indicated at the top of Figure 4, in Figure 6 and in Figure 7). In this case, a translation is needed from the context data format to the data format of W3C Linked Data. These three examples of interfaces between external applications and the V-Con Solution are elaborated below:

1. Interface using a W3CLinked Data format such as Turtle or RDF/XML (annex TC1, first section and Figure 5)

2. Interface using a format often used in the BIM world such as STEP physical file format (SPFF) (annex TC2 and Figure 6)

3. Interface using a format often used in the GIS world such as XML (annex TC2 and Figure 7)

Figure 5 elaborates the first interface example between a software application, understanding an ontology and a W3C data format supported by the V-Con Solution. The software application exports a dataset according to the agreed data format and ontology, in this example Turtle and the Common Ontology. The V-Con Solution directly imports the dataset and creates a dataset in the V-Con Solution. In this example, the dataset is viewed as the Common Dataset. The same procedure is possible for Context Datasets.

7 ’Common’ is a relative notion, depending on the viewpoint of the organisation that will deploy and use the V-Con Solution, in this case a road authority. ’Common’ implies those elements which the ontologies, relevant for this organisation, have in common, and can be used to link the corresponding datasets. From this viewpoint, CityGML or IFC Ontologies are ’Context’.

At the same time, from the viewpoint of a construction company, an IFC Ontology might be used to link the relevant datasets in his domain and therefore be regarded as ’Common’.


March 31st, 2017 13

Figure 5 Example of interface between a software application and the V-Con Solution using an ontology described by V-Con and a W3C data format

Figure 6 elaborates the second interface example between a BIM application and the V-Con Solution. In this example, a dataset is used with a data structure and a data format standardised in the domain of the buildingSMART Initiative (buildingSMART, 2012), which is known by the BIM application. This BIM application does not know the ontologies used by the client (expressed in OWL2), nor does it know the W3C data format.

Figure 6 Example of the interface between a BIM application and the V-Con Solution using a data structure and a data format standardised in the IFC domain

The example of Figure 6 depicts the following (from left to right):

• The external BIM application interfaces with the V-Con Solution through an exported SPFF file. This is an example of a file-based interface.

• The V-Con Solution imports this SPFF file. This means that the dataset represented in the SPFF file is translated to a Context Dataset in the V-Con Solution with a data structure defined in an IFC ontology, using a Translator (orange circle in the Figure) according to a translation specification (orange rectangle in the Figure).

• In the V-Con Solution, this Context Dataset can now be connected to the Common Dataset. The types of connections will be elaborated in section 3.6.


March 31st, 2017 14

• The return route from right to left can also be followed, i.e. exporting datasets from the V-Con Solution to external datasets in a standardised open data structure and in a standardised open format.

Figure 7 elaborates the third interface example between a GIS application and the V-Con Solution. In this example, a dataset is used with a data structure and a data format standardised in the domain of the OGC initiative (OGC). Again, this GIS application does not know the ontologies used by the V-Con Solution (expressed in OWL2), nor does it know the W3C data format. The explanation is similar to the previous example.

Figure 7 Example of the interface between a GIS application and the V-Con Solution using a data structure and a data format standardised in the GIS domain

The Principal will provide the ontologies (see annex TC1) and the translation specifications (see annex TC2, in which the references to the candidate external data structures and formats are specified). These ontologies will evolve and change in the course of time. The V-Con Solution should be able to deal with these continuously evolving ontologies of V-Con. This is elaborated further in section 4.1.

3.5 Layered modelling in the Common Ontology The Common Dataset of Figure 4 is associated to the Common Ontology. This Common Ontology is a set of layered ontologies, each with its own scope. Examples are ontologies with an international, national, company or even project-specific scope. In general, ontologies with a more specific scope reuse the more general ontologies with a wider scope. For example, classes in a higher ontology are specialised into subclasses in a lower ontology, or classes from a higher ontology are used as ranges for object properties in a lower ontology. The motivation for the layered (or distributed)modelling approach is described in (V-Con D3.1, 2013, pp. 68-69), (V-Con D3.2, 2013), and (Nederveen, Bektas, Luiten, & Böhms, 2013). Classes and property types are defined in the widest scope as possible for maximum reusability. V-Con developed a top-level ontology called Concept Modelling Ontology (CMO), covering quantities/units and decomposition (annex TC1 and annex F)8.

8This is an update of (V-Con D3.4.1c, 2014)


March 31st, 2017 15

The Principal will provide a set of layered ontologies for the Common Ontology, to be used in the PCP, where the classes and property types in one ontology use the classes and properties in another ontology with a wider scope on a higher layer. For example, classes in one ontology are sub-classes and sub-property types of classes and property types in the other ontology. The V-Con Solution should be able to deal with datasets and ontologies based on a layered ontology structure.

3.6 Connecting Common and Context Datasets As a result of the chosen approach described above, the V-Con Solution will contain multiple separate or independent datasets representing the same real-life objects, where each dataset represents a certain perspective (or view) from a certain domain. These perspectives can lead to complementary and/or overlapping data in the datasets. The V-Con Solution will make it possible to connect these datasets by

1) Linking them together as separate existing (re)sources, and/or 2) Converting all or parts of one dataset into another dataset, guided by the Linking Rule

Set between their corresponding ontologies. The first (preferred) option is according to the principles of the “Linked Data approach”. In this approach data is not duplicated, but kept in the separate partial datasets and linked. The second option is often required when software applications using one view have to take into account data from application with another view. In this case, the duplication of data is instantiated according to the target ontology and linked to the originating data on the fly. The Principal has defined a Linking Guide (LG) (see Annex F). This Linking Guide defines guidelines for developing Linking Datasets and Linking Rule Sets in a consistent manner. For example, from the perspective of the construction company with its BIM application, a bridge has other properties than a bridge that is viewed by a spatial planner, with his GIS application. This is complementary data. Another case is when there are multiple ways to interpret or classify the data in one dataset. An existing classification system might define the class ‘StiffPavement’. The Common Ontology might define the class ‘Pavement’ and the property ‘Material’. A Linking Rule Set could state that ‘StiffPavement’ is equivalent to ‘Pavement’ restricting the property ‘Material’ having the value ‘Concrete’. The linking and/or conversion needed when connecting these datasets are controlled by Linking Rule Sets. This implies that the V-Con Solution should be able to handle the following:

• Linking between objects in existing complementary datasets from different sources (and typically associated to different ontologies), indicating that the same real-life object is described in different domains. In general, this is done (1) manually by the user, and/or (2) with support from the V-Con Solution, and/or (3) fully automated by the V-Con Solution (for example using ‘data matchers’).

• Where really needed, converting a dataset associated to one ontology into a new dataset associated to another ontology according to a Linking Rule Set. One way of viewing this is as a necessary reclassification of existing datasets, e.g. visualising BIM datasets in a GIS viewer or vice versa. Two alternative sub-scenarios can be distinguished:

o The new dataset will be persistently stored and linked, and o The new dataset can be (re)generated on the fly.


March 31st, 2017 16

In the Test Scenarios of Phase 3 (V-Con TS P3, 2016), the Principal provided the information exchanges between actors that match the above V-Con approach. For example, importing from an external GIS application to the V-Con Solution, linking and converting within the V-Con Solution between GIS Context, Common and BIM Context Datasets, exporting to an external BIM application, receiving back the enriched datasets from these applications and processing the datasets in the V-Con Solution. The V-Con Solution should support these scenarios connecting datasets and ensuring the validity and integrity over time of these connections.


March 31st, 2017 17

4 Key Technical Challenges Given the V-Con approach towards information management for road authorities described in the previous chapter, the Principal has defined the Technical Challenges for the V-Con Solution as follows:

• TC1: Support ontology-based handling of datasets

• TC2: Support handling datasets in non-linked data formats

• TC3: Manage and store data structures and datasets

• TC4: Connect datasets from different domains

• TC5: View (connected) information

• TC6: Ensure system quality

• TC7: Ensure a future proof system The seven challenges are positioned in the diagram of the V-Con Solution in Figure 8.

Figure 8 Key Technical Challenges positioned in the V-Con Solution

The following seven sections describe what the Principal means by each Technical Challenge, what the Principal provides, and what functionality is required from the Contractor. For readability purposes, tables are provided in the Technical Challenges (TC) annexes and background information is provided in separate documents. The references to these documents can be found in annex F. Unless indicated otherwise, the provided information is binding for the Contractor. In the final section, section 4.8, the general ICT requirements are introduced. Contractor is encouraged to express its views on each of the Technical Challenges in its bid for Phase 3, explicitly referring to the required functionalities. These views can also be shared in the dialogue sessions. The Contractor is requested to demonstrate to what extent


March 31st, 2017 18

its pre-commercial V-Con Solution supports the required functionality. In case it will not support the functionalities yet, the Contractor is requested to indicate how it plans to support this functionality in future (commercial) versions of its Solution.

4.1 TC1: Support ontology-based handling of datasets In the V-Con approach described in chapter 3, ontologies define the data structure (semantics) of the datasets that are to be handled. In the V-Con Solution, ontologies are applied for the definition, storage, access, exchange and sharing of road infrastructure datasets. Under the V-Con approach, these ontologies are developed according to the V-Con Modelling Guide (annex F)9. As described in the V-Con Modelling Guide, the V-Con Solution must be able to handle ontologies that are defined in the OWL2 language (W3C, a). Some ontologies provided for the V-Con Solution will be direct translations from existing data structures defined in open domain standards. Currently, the domains at the international level are BIM and GIS related (V-Con D3.2, 2013). The domains at the national level include the Netherlands and Sweden and at company level Rijkswaterstaat and Trafikverket. Some elements of the Systems Engineering domain have been incorporated at the national and company level. The Principal provides:

• the V-Con Modelling Guide (see reference in annex F9) that has been used for defining the ontologies;

• the ontology CMO (Concept Modelling Ontology with documentation; see reference in annex F) which has been used as a basis for each ontology and which models general concepts such as decomposition and units;

• a set of ontologies, defined according to the V-Con Modelling Guide, accessible on V-Con’s public website (see reference in annex F). These ontologies should be viewed as a reference design, intended for the Contractor to copy. They contain the essentials for executing the Test Scenarios. The Contractor may enhance or modify them as required, as long the essentials are adhered to. The ontologies to be used in Phase 3 are described in separate documents (V-Con D3.4.2a, 2016), (V-Con D3.4.2b, 2016), (V-Con D3.4.2c, 2016), references to which can also be found in annex F.

• the datasets to be used in Phase 3. These datasets are described in chapter Error! Reference source not found. and are accessible on V-Con’s public website (see reference in annex F). These datasets should also be viewed as a reference design.

The V-Con Solution provides functionality to: 1.1 access the ontologies provided by V-Con in Turtle and RDF/XML format (see annex

F); 1.2 create a persistent storage (database, file system, …) conforming to the ontologies; 1.3 import datasets in a W3C Linked Data format (W3C, b) like Turtle and RDF/XML

conforming to the ontologies, including, e.g. syntactic validity checks, semantic validity checks and error handling.

1.4 import datasets that are updates of datasets that already exist in the V-Con Solution, including, e.g. merging, conflict notification and conflict resolving mechanisms;

1.5 export datasets in a W3C linked data format like Turtle conforming to the ontologies;

9This is an update of (V-Con D3.4.1c, 2014).


March 31st, 2017 19

1.6 SPARQL endpoint provision: allow external applications to directly access the ontologies/datasets using the SPARQL1.1 query language (W3C, c); complementing the file-based LD file upload/download;

1.7 attach digital files in any format to the (road infrastructure) objects. These files could be, for example, geometry models in the format of a domain standard or non-structured documents.

The ontologies and datasets (and the linking rule sets, discussed in TC4a, section 4.4.1) provided by the Principal should be viewed as a reference design. The Contractor is requested to indicate how it will deal with the needed enhancements and modifications during Phase 3. Likewise, during future application of the V-Con solution in practice, ontologies and datasets (and the linking rule sets) might be incomplete or incorrect. Therefore, the Principal requires the views of the Contractor on a elaboration of the required functionalities regarding:

• 1.1 Access ontologies and to some extent also to 3.2 Version management, and 6.4 Robustness: how does the V-Con Solution deal with incomplete and/or incorrect ontologies?

• 1.3 Import datasets and to some extent also to 3.2 Version management, and 6.4 Robustness: how does the V-Con Solution deal with incomplete and/or incorrect datasets?

• 4.2 and 4.4 Object and Property value conversion and to some extent also to 3.2 Version management, and 6.4 Robustness: how does the V-Con Solution deal with incomplete and/or incorrect Linking Rule Sets?

Annex TC1 provides listings of the W3C Linked Data formats and an overview the selected ontologies (and Linking Rule Sets) to be supported in Phase 3.

4.2 TC2: Support handling datasets in non-linked data formats Some datasets to be handled by the V-Con Solution will not be in W3C Linked Data formats, but in formats of other open domain standards or in company specific formats (see Figure 6 and Figure 7). The V-Con Solution must be able to handle the non-linked data formats indicated in annex TC2. Related to handling non-linked data formats is handling of linked data datasets that conform to a modelling guide which is non-compatible to the V-Con modelling guide. Those datasets also may need translation before they can be linked to datasets that conform to a compatible modelling guide. Examples of different modelling approaches for the same conceptual notion may concern cases when object relationships in one case are modelled as a simple associations, while in another case relationships are objectified (i.e., modelled with an intermediate object representing the relationship). The latter is the typical case in IFC. Another illustrative example is COINS, in which properties are objectified (using option D, as explained in chapter 4, guideline 5 of the Modelling Guide). The Principal provides (see annex TC2):

• the references to the description and definition of the non-linked data structures and data formats from other domain standards that must be supported; ;

• the corresponding Context Ontologies (as described in TC1).


March 31st, 2017 20

The V-Con Solution provides functionality to: 2.1 store/manage datasets according to the non-linked data formats. For example,

store and manage the originating STEP Physical File Format (SPFF) files; 2.2 import and translate datasets expressed in non-linked data formats to datasets

expressed in the selected linked data formats10. For example: translate SPFF to Turtle files;

2.3 translate datasets expressed in the selected linked data formats to datasets expressed in non-linked data formats and export those non-linked datasets. For example: translate Turtle to SPFF files;

2.4 import and translate datasets conforming to non-compatible modelling guides to datasets conforming to compatible modelling guides. For example: translate the non-compatible parts of COINS datasets to compatible COINS datasets;

2.5 translate datasets conforming to compatible modelling guides to datasets conforming to non-compatible modelling guides and export those datasets. For example: translate compatible COINS datasets to COINS datasets with non-compatible parts in it.

With respect to the integration of datasets according to the bSI standard IFC 2x4 (including Step Physical File Format (SPFF) – ISO 10303-21 and ifcXML) with datasets according to the standards for linked data and the semantic web, the Principal proposes an approach as described in the document Integration IFC and Linked data (see annex F). The Contractor is requested to express its view on this approach in the dialogues in Phase 3 and in its bid. The issue of integration of datasets conforming to non-compatible modelling guides, has been elaborated in the Linking Guide (sheet 37; see annex F). This issue will be relevant for several Test Scenarios, e.g. when communicating using COINS and IFC. The Contractor is requested to express its view on this approach in its bid for P3 and in the dialogues in Phase 3, and to implement a solution in the pre-commercial version of its solution during Phase 3. Storage and management of the linked data datasets in the V-Con Solution are described in TC1 and TC3. Annex TC2 provides a list of selected formats to be supported in Phase 3 and a suggested approach for dealing with COINS datasets with incompatible parts.

4.3 TC3: Manage and store data structures and datasets The V-Con Solution should work with datasets from different domains and sources/systems, some originating from different formats, make them available to different users and handle different versions. The V-Con Solution should manage the organisation, storage, access, security and integrity of data structures and datasets.

10Translation of datasets from one format to the other might also require some conversion, e.g., because of the differences in modelling approaches behind the formats. These conversions are not specified by the Principal.


March 31st, 2017 21

The V-Con Solution must provide the following functionality for data management: 3.1 Initialisation: specify the roles and the ontologies (and possibly subsets of ontologies)

that are valid for use within the project. 3.2 Version management: ensure that different versions of ontologies11, linking rule sets,

datasets, datasets originating from different formats or locations, and datasets that are connected, are all subject to version control.

3.3 Baseline management: create and maintain established baselines to capture which versions of data are associated to different life-cycle phases, such as ‘Planned’, ‘Designed’ and ‘Built’. The solution should also manage different stages of approval for the various baselines. A note with the Principal’s view on baselines can be found in Annex F.

3.4 Data selection and filtering: provide mechanisms to support selection and filtering of data, (e.g. data associated to specific ontologies or a geographical area) in order, for example, to export part of the data (see TC1) or to view the data from different viewpoints (see TC5).

3.5 Security and access control: provide security and access control mechanisms to data depending on roles of users.

3.6 File/document management: handle, store and manage files and/or documents attached to (road infrastructure) objects.

3.7 Workflow management: base transactions between actors through the V-Con Solution on open standards and protocols for workflow management, such as, ISO 29481-2 BIM – IDM – Part 2 Transaction framework (ISO 29481-2, 2012), PLCS (ISO 10303-239), PLM standards.

Note that these functionalities are dynamic, which implies that ontologies, linking rule sets and datasets change over time, and the V-Con Solution should be able to support these dynamics and keep the system consistent by, for example, handling previously connected (see TC4) and potentially updated datasets that have been replaced by new versions. In the Test Scenarios some of these functionalities are touched upon. The Contractor is requested to indicate in the Updated Solution Design description how each of the functionalities mentioned above is / will be dealt with in their V-Con Solution.

4.4 TC4: Connect datasets from different domains For V-Con, a distinction is made between connecting datasets on a semantic level and connecting datasets on a geometrical level.

4.4.1 TC4a: Connect datasets on a semantic level

Connecting datasets on a semantic level can take two forms. One traditional form is to transform data according to one view to another view: data conversions. This is needed when one software application with a certain view on the data has to deal with data related to another view of another software application. Typically first translations are needed (as described in section 4.2) to bring data in a common form before semantic conversion can start. Another, more modern form of connecting datasets is linking. This is the essence of the Linked Data approach. Data is no longer converted (and hence duplicated) but kept at the originating source. It is linked explicitly to other data by indicating that an object in one

11 This includes dealing with ever evolving standards.


March 31st, 2017 22

dataset is meant to be the same as an object in another dataset. In this way, a topological interface explosion (n x m) is avoided by only linking datasets where it is expedient. As described in section 3.6, the V-Con Solution should connect datasets from different domains. The V-Con Solution should be able to handle multiple ontologies for describing the same real-life objects. Under the V-Con approach, Linking Rule Sets between these ontologies are developed according the V-Con Linking Guide (more info can be found via the references given in annex F). As described in the V-Con Linking Guide, the V-Con Solution must be able to handle Linking Rule Sets between ontologies, that are provided by the Principal, and Linking Datasets between datasets. The following terms are used in the Linking Guide to describe the characteristics of connections between ontologies:

• Linking Dataset (between two datasets): a specification of how objects of one dataset are related to objects in another dataset (and vice versa). For instance, a Linking Dataset can indicate that two objects refer to the same real-life object, and this information can be used when collecting information about the same real-life object from multiple domain views.

• Linking Rule Set (between two ontologies): a specification of how classes and properties of one ontology are related to classes and properties of another ontology (and vice versa). For instance, a Linking Rule Set can indicate that two classes are ‘equivalent’, which implies that both classes refer to the same set of objects, and this information can be used to convert datasets associated to the one ontology to datasets associated to the other ontology.

Both Linking Sets can be used to infer new knowledge or data from asserted knowledge or data. See the Linking Guide (annex F) for a full description of potential connections depending on the “semantic level” of the classes available. The Principal provides:

• the V-Con Linking Guide (annex F) that will be used for defining the Linking Rule Sets between ontologies and the Linking Datasets between datasets;

• Linking Rule Sets (LRSs) between Common Ontologies and Context Ontologies (as described in section 3.6), defined according to the V-Con Linking Guide, and accessible on V-Con’s public website (see reference in annex F). These LRSs should be viewed as a reference design. The LRSs to be used in Phase 3 are described in separate documents (V-Con D3.4.2a, 2016), (V-Con D3.4.2b, 2016), (V-Con D3.4.2c, 2016), references to which can also be found in annex F.

• Other linking information which cannot be formalised using the standard OWL constructs. The following terms are used to describe the characteristics of connections between datasets:

• Translation (of datasets): transformation of a dataset without changing its data structure (or semantics) (see TC2, section 4.2). Translation can take place as the transformation of a dataset according to one format, into a dataset according to another format. Another manner in which translation takes place, is when a non-compatible dataset is transformed into a compatible dataset.

• Linking (between objects and their valued properties): connection, for example ‘SameAs’ links as defined by OWL, which implies that two objects refer to the same real-life object.


March 31st, 2017 23

• Conversion (of datasets): transformation of a dataset associated to one ontology (‘source’) to a dataset associated to another ontology (‘target’), as defined by a Linking Rule Set. The data format stays the same linked data format.

The V-Con Solution must provide the following basic functionality for linking and converting datasets: 4.1 Linking Datasets: Creating ‘SameAs’ links between objects that already exist in the V-

Con Solution and that refer to the same real-life objects. These SameAs links can be made (1) manually by the user, and/or (2) with support from the V-Con Solution, and/or (3) fully automated by the V-Con Solution (for example using ‘matchers’ or reasoners)12.

4.2 Object conversion: Creating a new linked dataset associated to another ontology. A dataset associated to one ontology (‘source’) is converted to a new dataset associated to another ontology (‘target’). This conversion uses the Linking Rule Set between classes and property types in the ontologies concerned. Note: typically, if new persistent data is created as a result of conversion, each source and corresponding target object will be automatically linked with SameAs links.

4.3 Object enrichment: Objects in an existing dataset according to one ontology is enriched by properties from another dataset according to another ontology. Such an enrichment is done according to a class-level mapping, indicating which property types are added from which class in the new ontology.

4.4 Property value conversion: Creating values for linked properties of linked objects. This can be partly expressed using standard OWL functionality in a Linking Rule Set, for example, copying values for equivalent properties with different names. More complex property value conversion is needed when properties are not equivalent, but have some quantified relationship (calculation or equation). For example, “x:diameter:= 2 * y:radius”.

4.5 Managing linking data: Managing the links between objects that refer to the same real-life objects to ensure that complementary data can be found, and managing overlapping data in different datasets is a major challenge for the V-Con Solution.

4.6 Functionality beyond standard OWL: The Modelling Guide prescribes how to model the ontologies and datasets. The Linking Guide states that many simple connections between ontologies and/or datasets can also be handled by the OWL functionality already defined in the Modelling Guide (so that standard OWL reasoning can be used for basic linking, enrichment, conversion etc.). For complex executions functionality beyond the standard OWL might be needed. Complex executions are for instance: value conversions, or ”non-1-to-1”links between classes or properties. The Contractor is encouraged to propose solutions for these complex executions.

The Principal is well aware of the ongoing debate on the precise semantics of the formal “owl:SameAs” links and their practical application. When using reasoners these links can, for instance, cause an explosion of duplicated facts for alternative views. The Contractor is encouraged to propose alternative functionalities. The debate is documented in a W3C paper (Halpin, Herman, & Hayes, 2010). The Principal also requests the views of the Contractor on a elaboration on automated or supported identification of same-as objects (as part of functionality 4.1 Linking datasets)13.

12In general, a user should be able to indicate which properties should be used for identifying objects that refer to the same real life objects. Typical criteria in civil infrastructure for this identification, are the type of the objects, the location and the unique identifier given by the asset manager.

13In the Test Scenarios, an example has been introduced.


March 31st, 2017 24

The Test Scenarios of Phase 3 contain extensive and complex linking examples to be tested. The overview in TC1 includes the Linking Rule Sets to be supported in Phase 3.

4.4.2 TC4b: Connect geometry datasets

Datasets that are imported in the V-Con Solution will often contain geometry data. Obviously BIM datasets (e.g. IFC SPFF) and GIS datasets (e.g. CityGML) contain geometry, but other datasets may also contain geometric data. As explained in section 3.6, in general, it is possible to either link, convert or enrich datasets when exchanging data, or use combinations of these scenarios. For V-Con, the focus is on linking geometry data in the native format since, for most cases, the principle will not provide ontologies or linking rule sets detailed to this level. To connect datasets from different domains, the approach considered has two steps:

• Firstly, the semantic aspect is considered, consisting of an object hierarchy including identification, types and properties of objects and the relationships among them.

• Secondly, the geometry is taken into account and considered separately. The V-Con approach is that there won’t be a specific V-Con ontology for the geometry. The geometry description (collection of objects describing the geometry) is provided in the original format, where the link between semantic and geometry is maintained in a suitable way (e.g. links to external geometry objects or as string or binary encoded literals).

One exception to this will be the alignment geometry, where a harmonized model has been developed jointly by bSI and OGC and which is vital for one of the V-Con business use cases. Therefore V-Con will provide necessary ontologies and linking rule sets for alignments. The V-Con Solution is not required to provide geometric conversions, where no ontologies or linking rule sets exist. The V-Con Solution will indeed exchange and link semantic datasets and may convert semantic datasets. But, the V-Con Solution does not need to provide the functionality for converting representations, such as geometric models. As a result, geometric representation datasets may remain stored in their native format (often CAD or GIS). However, it will be regarded as positive if the V-Con Solution can also convert and/or simplify geometry. Therefore, it must be clear to what degree the V-Con Solution supports this. The V-Con Solution must provide functionality to view and combine geometric data in a single view as described in TC5. The Test scenarios of Phase 3 contains tests related to geometry, focussing on CAD and GIS. Annex TC1, section on International Context Ontologies, gives an overview which standards are to be used in Phase 3. Annex TC4b gives an overview of the geometry formats to be supported in Phase 3, both for linking and viewing. Again, this is a very interesting topic for the dialogues in the coming phase.


March 31st, 2017 25

4.5 TC5: View (connected) information The users of the V-Con Solution must be able to view the applied ontologies and datasets in the V-Con Solution from different perspectives. The V-Con Solution must provide the following viewing functionality: 5.1 View the ontologies in use and their dependencies. 5.2 View, on the data-structure level, the class and property structures within an ontology in

the following representations:

• textual representation;

• graphical representation, depicting for instance subclass relationships between classes in a tree representation.

5.3 View, on the dataset level, datasets and property values in the following representations:

• textual representation;

• graphical representation of data, including a tree representation for decomposition structures.

5.4 Graphical representation of geometric and geographical data, including combined geometry from domain standards for CAD and GIS. Combining geometrical representations from different sources requires alignment of the coordinate reference systems.

In Phase 3, these functionalities will be part of the Test Scenarios. For geometry, the focus will be on domain standards for CAD and GIS.

4.6 TC6: Ensure system quality The Principal desires a solution that provides quality of use for three role types involved in a project: the road authority’s system administrator, the road authority’s information manager for the project and the project (end-)user. The V-Con Solution should: 1. be utilised effectively by these three roles; 2. perform within certain designated constraints; 3. be able to effectively use its resources; and 4. be able to take measures against harmful actions. The V-Con Solution should be: 6.1 configurable: the system should be designed so that it can be configured into multiple

forms, depending on its context/application. 6.2 scalable: the system should be scalable (horizontally/vertically) to be able to handle

increased loads without any impact on its performance. 6.3 performant: the system should be designed to be responsive and perform its functions

within reasonable time constraints. 6.4 robust: the system should be able to continue to function properly under abnormal

conditions or circumstances. 6.5 manageable: the system should be easy to manage through sufficient and effective

instrumentation for monitoring, debugging and performance tuning. 6.6 secure: the system should be designed so that damage to valuable assets is prevented

or reduced in terms of probability or severity through authorisation, authentication, encryption, auditing, and logging.

6.7 usable: the system should be designed with the user in mind, so that it is intuitive to use, can be localised and globalised, and provides a good overall user experience.


March 31st, 2017 26

Annex TC6/TC7provides general design principles and architectural design styles that might play a role when designing a high-quality V-Con Solution. The Contractor is asked to indicate in the Updated Solution Design description his ideas on ensuring the system quality of his V-Con Solution, relating his ideas to the ideas expressed in annex TC6/TC7, and how these are / will be dealt with in the V-Con Solution. Annex C and D specify some of the Principal’s requirements in further detail.

4.7 TC7: Ensure a future proof system V-Con aims to have a system solution architecture that is future proof and flexible. The system should be able to accommodate changing user and application needs, support new versions of standards, have the ability to incorporate additional functionality, extend connectivity, and incorporate new technology or components. Its design should allow for progressive (functional and technical) enhancements and emphasise the systematic reuse of system components. In the first PCP Phase, V-Con provides a general description of the future readiness characteristics of the V-Con Solution. The V-Con Solution should be: 7.1 reusable: components of the system should be designed to be reused in different

scenarios in different applications. 7.2 replaceable: components of the solution should be replaceable, so they may be

substituted with other similar components to support vendor-independent upgrades of targeted functionality.

7.3 extensible: the system (or components of the system) can be extended from existing components to provide new behaviour and functionality for the V-Con Solution, accommodating future changes in requirements.

7.4 accessible: services provided by the system should be autonomous and accessed through a formal contract. The contract should describe how other components can access the internal functionality of a particular component, module, or function.

7.5 interoperable: system software and hardware, protocols and data formats should conform to defined standards that promote interoperability, allowing deployment on different platforms.

Annex TC6/TC7provides general design principles and architectural design styles that might play a role when designing a future-proof V-Con Solution. The Contractor is asked to indicate in the Updated Solution Design description his ideas on ensuring a future-proof V-Con Solution, relating his ideas to the ideas expressed in annex TC6/TC7, and how these are / will be dealt with in the V-Con Solution. Annex C and D specify some of the general ICT requirements in further detail.


March 31st, 2017 27

4.8 General ICT requirements During the PCP process, the Principal requires that the RTD activities focus on the management of (linked) data, following the V-Con approach as described in chapter 3.This includes handling and storing (linked) data, linking, translations, conversions, communication with internal and external stakeholders and their applications, etc. Therefore, these functionalities will be the focus of the Test Scenarios of Phase 3. Furthermore, also the general ICT requirements are important. Regarding the implementation of a commercial version of a V-Con Solution in their core business processes, the Principal expects best practice solutions for the general ICT requirements, as described in TC6, TC7 and the generic parts of TC3 and TC5. The Principal prefers using best-practice solutions, that are applied already in the industry and that are seamlessly integrated with the V-Con Solution, rather than custom made solutions. The Contractor is requested to elaborate in its Updated Solution Design how it meets these requirements in its Solution (using their existing platform), and/or how it plans to provide the related functionalities (e.g. by integrating with (off-the-shelf) applications or by extending its existing platform). This should include a rough time planning. In annexes C and D an explanation is given. As long as no explanation is given, the Contractor should interpret the required functionality as ‘best-practice in the industry’.


March 31st, 2017 28

5 Suggestions for (National) Road Authorities Based on the experienced gained in the V-Con project recommendations are gathered for (National) Road Authorities that aim for implementing an information management system that makes use of the linked data and semantic web technologies. The first part of these recommendations are a short description how to use the results of the V-Con project. The second part highlights some current related initiatives.

5.1 Applying the V-Con results The main V-Con results can be listed as follows:

• Specification of a V-Con Solution by a (National) Road Authority o Challenge Brief, describing the overall challenge of the V-Con project (V-Con

CB P1, 2015) o The Business Specification, describing the organisational context of the V-

Con Solution and the business perspective on the challenge (V-Con BS P2, 2015)

o The Technical Specification, describing the technical approach and challenges for the V-Con Solution (this document and its references documents)

• V-Con Solutions in different stages of development by software vendors (in this document called Contractors)

o 6 descriptions of a solution design (2015) o 4 prototype implementations, including a more detailed solution design (2016) o 2 pre-commercial implementations, including a detailed solution design (2017)

• Lessons learnt in the PCP process The specification of the V-Con Solution can be used by (National) Road Authorities aiming for an upgrade of their information management systems and want to (investigate how to) apply a V-Con like approach. All information on the specification of the V-Con solution, generated in the V-Con project, is open and publicly available (see Annex F for references). This specification can be used as source of inspiration. Next to the V-Con approach, especially the Modelling & Linking Guide deserves attention. The V-Con Solutions, developed by market parties are owned by those parties. Conditions on how these solutions can be used by Road Authorities is to be discussed with them. The six market parties that joined the V-Con PCP process are:

• Participating in Phase 1, 2 and 3, resulting in a pre-commercial V-Con Solution: o TopQuadrant (UK) o Arcadis/SemmTech (NL/NL)

• Participating in Phase 1 and 2, resulting in a prototype V-Con Solution: o Jotne (NO) o Sweco (SE)

• Participating in Phase 1, resulting in a solution design for a V-Con Solution: o Trimble (ViaNova) (NO) o Demo/RDF (NL/BU)


March 31st, 2017 29

These parties indicated they continue development of their V-Con Solutions (possibly under a different name, though) and that they can be contacted for demonstrations of their (V-Con) Solutions. The V-Con Solutions were specified and developed in a pre-commercial procurement (PCP) process. An evaluation of this process will be reported to the European Commision. The overall conclusion on PCP is that it is valuable, but also needs special attention, both for Principals, as for Contractors.

5.2 Related initiatives The V-Con approach and the V-Con Solutions are not yet built on mature, fully developed technologies. The application of linked data / semantic web is very promising, but still under development. The buildingSMART Linked Data / InfraRoom initiatives and the CEDR-INTERLINK project (roadotl.eu/) are two current initiatives worth mentioning in this context. Organisations considering applying V-Con-like Solutions are recommended to follow these initiatives. The organisations involved in the V-Con project will continue to develop the approach and to apply these technologies in their business processes. You may contact the persons mentioned below for more information:

• Rijkswaterstaat, the Netherlands, Benno Koehorst, [email protected]

• Trafikverket, Sweden, Mikael Malmkwist, [email protected]

• TNO, the Netherlands, Bart Luiten, Michel Böhms, [email protected], [email protected]

• CSTB, France, Bruno Fies, [email protected]

• Triona, Lars Wikström, [email protected]

http://buildingsmart.org/standards/standards-organization/groups/linked-data-working-group/

http://www.buildingsmart-tech.org/infrastructure

http://roadotl.eu/


March 31st, 2017 30

Introduction to annexes Several Technical Challenges are further discussed in the following TC annexes. The document concludes with general annexes:

• Annex A: Figures and Tables

• Annex B: Explanation of Test Scenario

• Annex C: Rijkswaterstaat’s general ICT requirements

• Annex D: Trafikverket’s general ICT requirements

• Annex E: Informative references

• Annex F: Links to the technical V-Con documentation/models


March 31st, 2017 31

Annex TC1: Support ontology-based handling of datasets

OWL 2 ontology language V-Con bases its approach on the semantic web. V-Con uses the OWL 2 ontology language to describe the ontologies that describe the data structure of the datasets that are exchanged via the V-Con server. In the overview document (W3C, a), W3C defines OWL as follows:

The OWL 2 web ontology language, informally OWL 2, is an ontology language for the semantic web with a formally defined meaning. OWL 2 ontologies provide classes, properties, individuals, and data values and are stored as semantic web documents. OWL 2 ontologies can be used along with information written in RDF, and OWL 2 ontologies themselves are primarily exchanged as RDF documents.

Their overview document serves as an introduction to OWL 2 and the various other OWL 2 documents. It describes the syntaxes for OWL 2, the different kinds of semantics, the available profiles (sub-languages), and the relationship between OWL 1 and OWL 2.

Figure 9 OWL 2, ontologies and related document formats

The V-Con Solution should at least support the W3C formats Turtle and RDF/XML.


March 31st, 2017 32

Ontologies and Linking Rule Sets Phase 3 Figure 10 gives an overview of the ontologies and linking rule sets to be used in Phase 3 to support the use cases, as described in the Business Specification (V-Con BS P2, 2015) chapter Error! Reference source not found.. The International, Swedish and Dutch ontologies and linking rule sets to be used in Phase 3 are described in separate documents, which references can be found in annex F. Based on these ontologies, datasets for the Test Scenarios are provided. The references to these ontologies, linking rule sets and datasets can be found in annex F.

Figure 10 Overview of ontologies and linking rule sets to be used in Phase 3


March 31st, 2017 33

Figure 11 Linking rule sets in the 5 Test Scenarios

Figure 12 Key External Semantic Resources


March 31st, 2017 34

Annex TC2: Support handling datasets in non-linked data formats The following formats of open domain standards are to be supported in Phase 3: Original formats Data Structures/Data

References (URL) Corresponding Context Ontology

Versions to be used (data structures/format)

Relevance for VCS

EXPRESS/ SPFF

http://www.buildingsmart-tech.org/specifications/ifc-releases/ifc4-add1-release (chose “access EXPRESS file”) http://www.buildingsmart-tech.org/news/ifc-alignment-candidate-standard

https://en.wikipedia.org/wiki/ISO_10303-21 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=33713

IFC4x1

See Annex F IFC4 Add1 ISO 10303-21:2002

Must

XSD/ XML

http://www.opengeospatial.org/standards/citygml http://www.citygml.org/ https://en.wikipedia.org/wiki/XML http://www.w3.org/TR/2006/REC-xml11-20060816/

CityGML CityGML2.0/ XML1.1

Must

COINS formats COINS 2.0 info: see Annex F COINS Core Model RWS Reference Framework RWS-OTL

Version 2.0 Must

SQL data definition / SGML (input interface)

See Annex F for ref. to example file IVON See Annex F Must

Native/ ESRI binary shapefile or equivalent XML file

See Annex F for ref. to example files KernGIS See Annex F Must

Table 1 Data Structures/Formats for non-geometry data to be supported in Phase 3

http://www.buildingsmart-tech.org/specifications/ifc-releases/ifc4-add1-release



http://www.buildingsmart-tech.org/news/ifc-alignment-candidate-standard

http://www.buildingsmart-tech.org/news/ifc-alignment-candidate-standard

https://en.wikipedia.org/wiki/ISO_10303-21

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=33713


http://www.buildingsmart-tech.org/future/linked-data/ifcowl/20150925_latest/IFC4_ADD1.owl

http://www.opengeospatial.org/standards/citygml

http://www.citygml.org/

https://en.wikipedia.org/wiki/XML

http://www.w3.org/TR/2006/REC-xml11-20060816/



March 31st, 2017 35

Annex TC4b: Connect and TC5: View (connected) information The following semantics/formats for geometric data are to be supported in the V-Con Solution: Formats Data Structures/ Data

References (URL) Versions to be used in test (data structures/format)

Relevance for VCS

EXPRESS/SPFF (actually the geometry part of IFC)

http://www.buildingsmart-tech.org/ifc/IFC4x1/RC3/ https://en.wikipedia.org/wiki/ISO_10303-21 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=33713

IFC4 Add1/ ISO 10303-21:2002 Incl. Alignment extension

Must

XSD/XML http://www.opengeospatial.org/standards/gml https://en.wikipedia.org/wiki/XML http://www.w3.org/TR/2006/REC-xml11-20060816/

GML 3.1.1/ XML1.1 Incl. Alignment extension

Must

Table 2 Data Structures and Formats for geometry data to be supported in Phase 3

http://www.buildingsmart-tech.org/ifc/IFC4x1/RC3/

https://en.wikipedia.org/wiki/ISO_10303-21


http://www.opengeospatial.org/standards/gml

https://en.wikipedia.org/wiki/XML



March 31st, 2017 36

Annex TC6/TC7: Ensure system quality and ensure a future-proof system This annex presents general design principles and architectural design styles that might play a role when designing the V-Con Solution with respect to ensuring system quality (described in TC6), and ensuring a future-proof system (described in TC7). The Contractor is asked to discuss the design principles and architectural design styles it plans to use when developing the V-Con Solution, referring to the design principles and architectural design styles referred to in this annex.

Software design principles General design principles for the V-Con Solution are as follows:

Separation of concerns The server should be divided into distinct features with as little overlap in functionality as possible. The important factor is minimisation of interaction points to achieve high cohesion and low coupling. When concerns are well separated, individual parts of the server can be developed and updated independently. Of especial value is the ability to later improve or modify one part without having to know the details of other parts, and without having to make corresponding changes to those parts.

No duplication of functionality There should be only one server component providing a specific functionality – this functionality should not be duplicated in any other component in order to increase clarity, make it easier to implement changes and prevent introduction of potential inconsistencies. This makes the server component or module more robust to changes.

Loose coupling Reduction of coupling between components or server parts should be prevalent because it fosters an environment where parts of the server are interconnected without being dependent on each other. As a result, they can be changed independently without breaking the existing interconnection between those parts.

Common vocabulary and data definitions Data is defined consistently throughout the enterprise, and the definitions are understandable and available to all users. The data that will be used in the server must have a common definition to enable sharing of data. A common vocabulary will facilitate communications and enable dialogue to be effective.

Standards-based interoperability Software and hardware should conform to defined standards that promote interoperability for data, applications, and technology. Standards help ensure consistency, thus improving the ability to manage systems and improve user satisfaction, and protect existing IT investments, thus maximising return on investment and reducing costs.

A clear contract for externally available functions/components Components, modules, and functions should be defined in a contract or interface specification that describes their usage and behaviour clearly. The contract should describe how other components can access the internal functionality of the component, module, or


March 31st, 2017 37

function, as well as the behaviour of that functionality in terms of pre-conditions, post-conditions, side effects, exceptions, performance characteristics, and other factors.

Architectural design style guidelines In general three architectural styles are in line with the key architectural principles described above.

Component-based architectural style Provides decomposition of the design into individual functional or logical components that expose well-defined communication interfaces containing methods, events, and properties. Perceived benefits of the component-based architectural style are as follows:

• Reusable: components are designed to be reused in different scenarios in different applications.

• Replaceable: components may be substituted with other similar components.

• Not context specific: components are designed to operate in different environments and contexts. Specific datasets, such as state data, should be passed to the component instead of being included in or accessed by the component.

• Extensible: a component can be extended from existing components to provide new behaviour for the V-Con Solution.

• Encapsulated: components expose interfaces that allow the caller to use its functionality, and do not reveal details of the internal processes or any internal variables or state.

• Independent: components are designed to have minimal dependencies on other components (loose coupling). Therefore components can be deployed in any appropriate environment without affecting other components or systems.

Layered architectural style This architectural style focuses on the grouping of related functionality within an application into distinct layers that are stacked vertically on top of each other. Functionality within each layer is related by a common role or responsibility. Communication between layers is explicit and loosely coupled. Layering your application appropriately helps to support a strong separation of concerns that, in turn, supports flexibility and maintainability. Perceived benefits of the layered architectural are as follows:

• Abstraction: layers allow changes to be made at the abstract level.

• Isolation: allows technology upgrades to be isolated for individual layers in order to reduce risk and minimise impact on the overall system.

• Manageability: separation of core concerns helps to identify dependencies, and organises the code into more manageable sections.

• Reusability: lower layers have no dependencies on higher layers, potentially allowing them to be reusable in other scenarios..

• Performance: distributing the layers over multiple physical tiers can improve scalability, fault tolerance, and performance.

• Loose coupling: communication between layers is based on abstraction and events to enable loose coupling between layers.

Service-oriented architectural style Service-oriented architecture enables the application functionality to be provided as a set of services, as well as the creation of applications that make use of software services. Services are loosely coupled because they use standards-based interfaces that can be invoked, published, and discovered.


March 31st, 2017 38

Perceived benefits of the service-oriented architecture are as follows:

• Domain alignment: reuse of common services with standard interfaces increases business and technology opportunities and reduces cost.

• Abstraction: services are autonomous and accessed through a formal contract, which provides for loose coupling and abstraction.

• Interoperability: because the protocols and data formats are based on industry standards, the provider and consumer of the service can be built and deployed on different platforms.

• Rationalisation: services can be granular in order to provide specific functionality, rather than duplicating the functionality in numbers of applications, hence eliminating duplication.


March 31st, 2017 39

Annex A: Figures and Tables Figure 1 Document structure for the V-Con Pre-Commercial Procurement process 4 Figure 2 Organisational context of the V-Con Solution: road authority’s core functions,

with green objects indicating the scope of the V-Con Solution. The red circles represent software applications. 8

Figure 3 Possible applications and ontologies in the organisational context of the V-Con Solution 9

Figure 4 A look inside the V-Con Solution 11 Figure 5 Example of interface between a software application and the V-Con Solution

using an ontology described by V-Con and a W3C data format 13 Figure 6 Example of the interface between a BIM application and the V-Con Solution

using a data structure and a data format standardised in the IFC domain 13 Figure 7 Example of the interface between a GIS application and the V-Con Solution

using a data structure and a data format standardised in the GIS domain 14 Figure 8 Key Technical Challenges positioned in the V-Con Solution 17 Figure 9 OWL 2, ontologies and related document formats 31 Figure 10 Overview of ontologies and linking rule sets to be used in Phase 3 32 Figure 11 Linking rule sets in the 5 Test Scenarios 33 Figure 12 Key External Semantic Resources 33 Table 1 Data Structures/Formats for non-geometry data to be supported in Phase 3 34 Table 2 Data Structures and Formats for geometry data to be supported in Phase 3 35 Table 3 General description of Test Scenario spreadsheets 42


March 31st, 2017 40

Annex B: Explanation of Test Scenario The V-Con test approach, as described in (V-Con TS P3, 2016), chapter Error! Reference source not found., focus on:

• firstly, fulfilment of the business requirements, as described in the business use cases in the Business Specifications P2 (V-Con BS P2, 2015);

• secondly, fulfilment of the technical challenges, as described in chapter 4. The business use cases describe the refinement process (the life cycle) for a part of the infrastructure; from identifying a requirement for new or changed infrastructure, to opening it for use. During this process, a number of major exchanges (transactions) have been identified. These transactions take place between roles within the organisations and cover varying process steps. These transactions have been described and prioritized. Based upon the prioritization, a number of transactions have been selected for testing the V-Con Solution. These selected transactions constitute the backbone of the Test Scenarios. The test steps cover these selected transactions and any additional step needed to allow:

• interaction between the user and the V-Con Solution,

• data management and preparation by the V-Con Solution. In order to describe these various test steps, spreadsheets have been added to Annex F. These spreadsheets list the test steps per Test Scenario and list the minimum expected outcome per step. These spreadsheets do so by defining per test step topics such as purpose, requirements, preconditions, input/output datasets with used semantics and syntax, interaction, intermediate states, verification method, etc. This annex continues by providing a general description for these topics which are used as column headings in the spreadsheets (see Table 3). This table applies to all Test Scenarios found in Annex F:

• Rijkswaterstaat Test scenarios: Alignment and Repavement;

• Trafikverket Test Scenarios: Alignment and Repavement;

• International Test Scenario: Repavement. Table 3 describes in general terms the column headings (topics) used in the Test Scenario spreadsheets.

Column header

Description Responsible party for content

Test step This column lists the numbers given to the Test Steps to be performed in order to test the prototype. Each row in a spreadsheet constitutes a test step.

Principal

Purpose/ description/ comments/ restrictions

This column describes the intended purpose and description of the Test Step. The description can contain additional comments and/or restrictions.

Principal


March 31st, 2017 41

Column header


Transaction nr. (BS)

This column lists the corresponding Transaction numbers, as described in the Business Specification P2 (V-Con BS P2, 2015) annex A – C. For example Test Step 3 describes the test to be performed for the Alignment Business Use Case and the corresponding transaction T2.

Principal

Technical challenge

This column lists the identifier for corresponding Technical challenges, as described in the Technical Specification Chapter 4 and the annex. For example 5.1 (View the ontologies in use and their interrelationships).

Principal

Input ontology Lists the ontologies applicable to the input datasets.

Principal

Input LRS Lists the Linking Rules set(s) applicable to the input datasets.

Principal

Input format The format (syntax), if relevant, to be used as input for the test step.

Principal

Reference Dataset

Dataset, provided by the Principal, which will be used by the Contractor for the Test step. The dataset is either linked through URL or can be found on the modelserver.

Principal

Execution This column describes the expected performance of the V-Con Solution.

Principal indicates what of interest for the step in the VCS. Contractor responsible for how and the actual content.

Output ontology

The column lists the ontologies applicable to the output dataset , which is to be produced by the V-Con Solution.


Output format The column describes the data formats applicable to the output dataset, which is to be produced by the V-Con Solution.



March 31st, 2017 42

Column header


Verification Dataset

Dataset, provided by the Principal, which will be used by the Principal to verify the output of the V-Con Solution.

Principal

Verification method

The method and tools to be used for the verification of the outcome of the Test step.


In particular cases the Contractor and Principal perform the verification in a joint effort. For example, in the cases where the Principal's tools are needed for verifying the content produced by the Contractor.

Success criteria

The criteria upon which the relative success or failure of the Test step is judged.

Principal

Table 3 General description of Test Scenario spreadsheets


March 31st, 2017 43

Annex C: Rijkswaterstaat’s general ICT requirements As described in section 4.8, the Principal requires the Contractor to elaborate in its Updated Solution Design how it provides the general ICT requirements in its V-Con Solution (using their existing platform), and/or how it plans to provide the related functionalities. A reference to the general ICT requirements of Rijkswaterstaat can be found in annex F.


March 31st, 2017 44

Annex D: Trafikverket’s general ICT requirements As described in section 4.8, the Principal requires the Contractor to elaborate in its Updated Solution Design how it provides the general ICT requirements in its V-Con Solution (using their existing platform), and/or how it plans to provide the related functionalities. A reference to the general ICT requirements of Trafikverket can be found in annex F.


March 31st, 2017 45

Annex E: Informative references

BIM Loket. (2015, May). CB-NL Browser. Retrieved from http://viewer.cbnl.org/

buildingSMART. (2012). Retrieved November 2012, from http://buildingsmart.com/standards

CB-NL. (2015). CB-NL. Retrieved from http://public.cbnl.org/

Halpin, H., Herman, I., & Hayes, P. J. (2010). RDF Next Steps Workshop, June 26-27, 2010, Palo Alto, USA. Retrieved from http://www.w3.org/2009/12/rdf-ws/papers/ws21

ISO 10303-239. (n.d.). Industrial automation systems and integration - Product data representation and exchange - Part 239 Product Life Cycle Support.

ISO 12006-2. (2015). ISO 12006-2:2015 - Building construction -- Organization of information about construction works -- Part 2: Framework for classification. Retrieved from http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=61753

ISO 15926. (2014, 4 5). Standards, together defining the Semantic Web for ISO 15926. Retrieved from http://15926.org/standards/

ISO 29481-2. (2012). Building Information Models - information delivery manual - Part 2: interaction framework, Committee Draft .

Nederveen, S. v., Bektas, E., Luiten, B., & Böhms, M. (2013). Distributed Modeling fo Road Authorities. Proceedings CIB W78. Beijing.

OGC. (n.d.). Retrieved from http://www.opengeospatial.org.

OGC. (2014). OGC Draft LandInfra Conceptual Model. Retrieved from https://portal.opengeospatial.org/files/61594

OMG. (2015, June). Unified Modeling Language. Retrieved from www.omg.org/spec/UML/index.htm

V-Con BS P1. (2015). V-Con Business Specification, Phase 1.

V-Con BS P2. (2015). V-Con Business Specification, Phase 2.

V-Con CB P1. (2015). V-Con Challenge Brief, Phase 1.

V-Con D3.1. (2013). Inventory of available information exchange standards. Retrieved from http://www.rws.nl/en/images/V-Con%20report%20D3.1%20Inventory%20of%20available%20information%20exchange%20standards_tcm224-351276.pdf

V-Con D3.2. (2013). Definition of Road Information Structure - Selection of road information standards. Retrieved from http://www.rws.nl/en/images/V-Con%20report%20D3.2%20-%20Definition%20of%20Road%20Information%20Structure_tcm224-351293.pdf

V-Con D3.3.1. (2015, April). Initial Draft version IFC for Roads. Retrieved from https://staticresources.rijkswaterstaat.nl/binaries/V-Con%20ppt%20D3.3.1%20Initial%20Draft%20version%20IFC-for_tcm21-37157.pdf

V-Con D3.4.1c. (2014). Methodology guidelines and tools to develop (national) object libraries - Appendix C Modelling Guide. Retrieved from http://www.rws.nl/en/images/V-Con%20report%20D3.4.1.%20Appendix%20C%20-%20Modeling%20Guide_tcm224-351295.pdf - PLEASE NOTE the latest (but not final) version of the modeling guide can be found at http://www.cbnl.org/xwiki/bin/view/MODELING+GUIDE/WebHome

V-Con D3.4.2a. (2016). Object Library International. (to be published).

V-Con D3.4.2b. (2016). Object Library Rijkswaterstaat. (to be published).


March 31st, 2017 46

V-Con D3.4.2c. (2016). Object Library Trafikverket. (to be published).

V-Con ITT P1. (2015). V-Con Invitation to Tender, Phase 1.

V-Con PCP P1. (2015). V-Con PCP process, Phase 1.

V-Con TS P1. (2015). V-Con Technical Specification, Phase 1.



VISI. (2010). VISI Communicatie in de bouw (with links to supporting documents) (in Dutch). Retrieved from http://www.crow.nl/vakgebieden/contracteren/visi-communicatie-in-de-bouw

W3C. (a). OWL2 Web Ontology Language Document Overview (Second Edition). Retrieved 2014, from http://www.w3c.org/TR/owl2-overview/

W3C. (b). Linked Data Platform 1.0. Retrieved from http://www.w3.org/TR/ldp/

W3C. (c). SPARQL Query Language for RDF. Retrieved from http://www.w3.org/TR/rdf-sparql-query/

Note: the public V-Con documents delivered to the European Commission related to the V-Con EU project are available through http://www.rijkswaterstaat.nl/english/about-us/doing-business-with-rijkswaterstaat/v-con/index.aspx.

http://www.rijkswaterstaat.nl/english/about-us/doing-business-with-rijkswaterstaat/v-con/index.aspx

http://www.rijkswaterstaat.nl/english/about-us/doing-business-with-rijkswaterstaat/v-con/index.aspx


March 31st, 2017 47

Annex F: Links to the technical V-Con documentation This annex contains direct links to the technical documentation used by the Contractor in Phase 3. Main documents: http://www.modelservers.org/public/V-Con/ReleaseP3/TS-P3-MainDocuments/

• Technical Specification End of Project (this document)

• Technical Specification P3 (also containing the description of the Test Scenarios)

• Document D 3.4.2a describing the International ontologies and their background

• Document D 3.4.2b describing the Swedish ontologies and their background

• Document D 3.4.2c describing the Dutch ontologies and their background General information: http://www.modelservers.org/public/V-Con/ReleaseP3/General/

• V-Con Modelling and Linking Guide (MLG)

• V-Con Ontologies and Linking Rule Sets overview

• V-Con Global Architecture

• V-Con Vision

• IFC-LD, integration IFC Step data and Linked data

• Note on Baselines

• Documentation COINS 2.014 o 0 – Introduction COINS 2.0, o 1 - Specification of COINS 2.0 core model in UML format, o 2 - Specification of COINS 2.0 core model in OWL format o 3 - Specification of Window of Authorization file in OWL format, o 4 - Specification of Units Ontology in OWL format, o 5 - Presentation sheets Introduction COINS 2.0, o 6 - Starter kit COINS 2.0, Illustrative examples and exercises,

• Background information on IVON

• Background information on KernGIS

• General ICT Requirements RWS and TRV Test scenarios: http://www.modelservers.org/public/V-Con/ReleaseP3/TestScenarios/

• Rijkswaterstaat: RWS Alignment

• Rijkswaterstaat: RWS Repavement

• Trafikverket: TRV Alignment & Repavement

• International: International Repavement Reference design of the Ontologies: http://www.modelservers.org/public/V-Con/ReleaseP3/Ontologies/ Reference design of the Linking rule sets: http://www.modelservers.org/public/V-Con/ReleaseP3/LinkingRuleSets/ Reference design of the Datasets: http://www.modelservers.org/public/V-Con/ReleaseP3/DataSets/

14 COINS 2.0, the documentation, and supporting tools are under development. For the latest versions see: http://www.coinsweb.nl/Introduction_COINS_2.htm.

http://www.modelservers.org/public/V-Con/ReleaseP3/TS-P3-MainDocuments/

http://www.modelservers.org/public/V-Con/ReleaseP3/General/

http://www.modelservers.org/public/V-Con/ReleaseP3/TestScenarios/

http://www.modelservers.org/public/V-Con/ReleaseP3/Ontologies/

http://www.modelservers.org/public/V-Con/ReleaseP3/Ontologies/

http://www.modelservers.org/public/V-Con/ReleaseP3/LinkingRuleSets/

http://www.modelservers.org/public/V-Con/ReleaseP3/LinkingRuleSets/

http://www.modelservers.org/public/V-Con/ReleaseP3/DataSets/

http://www.modelservers.org/public/V-Con/ReleaseP3/DataSets/

http://www.coinsweb.nl/Introduction_COINS_2.htm