- evolv… · Web vie

Technical Specification, Phase 3

V-ConTechnical SpecificationPhase 3

April 8th, 2016 1


Content1 INTRODUCTION.................................................................................................................................... 4

1.1 PURPOSE OF THE DOCUMENT.......................................................................................................................41.2 OVERVIEW OF PCP DOCUMENTS..................................................................................................................41.3 STRUCTURE OF THE TECHNICAL SPECIFICATION, PHASE 3...................................................................................5

2 TERMS AND ABBREVIATIONS............................................................................................................... 6

3 V-CON APPROACH............................................................................................................................... 9

3.1 ORGANISATIONAL CONTEXT AND SCOPE: INFORMATION MANAGEMENT ON A ROAD AUTHORITY’S PROJECT..................93.2 APPLICATIONS AND ONTOLOGIES.................................................................................................................103.3 SYSTEM BOUNDARIES AND INTERFACES........................................................................................................113.4 HYBRID APPROACH...................................................................................................................................123.5 LAYERED MODELLING IN THE COMMON ONTOLOGY........................................................................................153.6 CONNECTING COMMON AND CONTEXT DATASETS.........................................................................................16

4 KEY TECHNICAL CHALLENGES.............................................................................................................. 18

4.1 TC1: SUPPORT ONTOLOGY-BASED HANDLING OF DATASETS.............................................................................194.2 TC2: SUPPORT HANDLING DATASETS IN NON-LINKED DATA FORMATS................................................................204.3 TC3: MANAGE AND STORE DATA STRUCTURES AND DATASETS..........................................................................214.4 TC4: CONNECT DATASETS FROM DIFFERENT DOMAINS....................................................................................224.5 TC5: VIEW (CONNECTED) INFORMATION......................................................................................................264.6 TC6: ENSURE SYSTEM QUALITY..................................................................................................................264.7 TC7: ENSURE A FUTURE PROOF SYSTEM.......................................................................................................274.8 GENERAL ICT REQUIREMENTS....................................................................................................................28

5 TEST APPROACH................................................................................................................................. 29

5.1 OBJECTIVES............................................................................................................................................295.2 APPROACH FOR SPECIFYING AND TESTING THE V-CON SOLUTION......................................................................29

6 TEST SCENARIOS................................................................................................................................ 30

6.1 OBJECTIVES OF TEST SCENARIOS.................................................................................................................306.2 ADDITIONAL INFORMATION ON THE FINAL SOLUTION DESIGN AND THE PRE-COMMERCIAL V-CON SOLUTION............306.3 TEST SCENARIOS OVERVIEW......................................................................................................................316.4 TEST SCENARIO RIJKSWATERSTAAT ALIGNMENT.............................................................................................326.5 TEST SCENARIO RIJKSWATERSTAAT REPAVEMENT...........................................................................................366.6 TEST SCENARIO TRAFIKVERKET ALIGNMENT..................................................................................................406.7 TEST SCENARIO TRAFIKVERKET REPAVEMENT................................................................................................446.8 TEST SCENARIO INTERNATIONAL REPAVEMENT..............................................................................................47

INTRODUCTION TO ANNEXES............................................................................................................................. 49

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

OWL 2 ONTOLOGY LANGUAGE...............................................................................................................................50ONTOLOGIES AND LINKING RULE SETS PHASE 3.........................................................................................................51

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

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

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

SOFTWARE DESIGN PRINCIPLES................................................................................................................................55ARCHITECTURAL DESIGN STYLE GUIDELINES................................................................................................................56

April 8th, 2016 2


ANNEX A: FIGURES AND TABLES......................................................................................................................... 58

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

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

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

ANNEX E: INFORMATIVE REFERENCES................................................................................................................ 64

ANNEX F: LINKS TO THE TECHNICAL DOCUMENTATION......................................................................................66

April 8th, 2016 3


1 IntroductionThis document includes a description of the V-Con approach and the Technical Challenges to be met by the Contractor for the pre-commercial V-Con Solution in Phase 3. This Phase 3 version of the Technical Specification is the refinement of the Technical Specification, Phase 2 (V-Con TS P2, 2015)1, and is intended to be used by the Contractor to develop, test and demonstrate a pre-commercial version of its V-Con Solutions, in Phase 3.

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

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 this document the Principal has added the Test Scenarios to be demonstrated by the Contractor with its pre-commercial V-Con Solution, in chapter 6. At the end of Phase 3, the Contractor will demonstrate the extent to which its pre-commercial V-Con Solution supports these Test Scenarios.

This document, the Technical Specification, Phase 3, includes the requirements described earlier in the Technical Specification, Phase 2, and thereby replaces the Technical Specification, Phase 2.

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.

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

April 8th, 2016 4


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 to be met by the Contractor for the V-Con

Solution. Chapter 5 describes the test approach to be used in Phase 3. Chapter 6 describes Test Scenarios to be supported with the pre-commercial V-Con

Solution of the Contractor. 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 Phase 3 of the PCP process. These TC annexes have the status Final.

Annex B explains briefly how to read the Test Scenario descriptions. Annex C and D list the general ICT requirements of Rijkswaterstaat and Trafikverket. 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).

Compared to Technical Specification, Phase 2, the first five chapters have been refined, based on progressive insight by the Principal, gained, among others, during the dialogues with the Contractors. The old chapter 6 on the Mini Cases has been removed and a new chapter 6 on the Test Scenarios has been added. The Ontologies, Linking Rule Sets and datasets to be used in the Test Scenarios are described in separate documents, which can be retrieved using the references in annex F. The annexes related to the Technical Challenges have been refined and their status has migrated from Draft to Final.

April 8th, 2016 5


2 Terms and abbreviationsTerms 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 DefinitionBSAB 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 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.2

Convertor A component of the V-Con Solution which performs the Conversion 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’).

2 See section 4.4.1.

April 8th, 2016 6


Term Abbreviation DefinitionEXPRESS A standardized language for specifying product data models.

EXPRESS is formalized in the ISO Standard for the Exchange of Product model data (STEP).

eXtensibleMark-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

ifcXML ifcXML The semantics of the IFC now not represented as an EXPRESS schema but as an XML Schema (XSD).

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 Guide LG The V-Con specification describing how ontologies and/or datasets can be linked together. These links can be used to infer new data from already asserted data. Inferring can be used to collect all data on the same object or convert data from one view to another.

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.

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 Guide MG A guide on how to apply the W3C Linked Data approach and related Semantic Web technologies like RDF, RDFS and OWL when developing ontologies 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.

April 8th, 2016 7


Term Abbreviation DefinitionOntology 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 RDFSTEP 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.

Technical Specification

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.3

Translator A component of the V-Con Solution which performs the translation 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.

3 See section 4.2.

April 8th, 2016 8


3 V-Con approachThis 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.

April 8th, 2016 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 BIM4 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

4 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.

April 8th, 2016 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)5, 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.

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

April 8th, 2016 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

April 8th, 2016 12


the context. Part of this data can overlap with data in other contexts. Both parts can be linked through the Common Dataset6, 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 22.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.

6 ’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’.

April 8th, 2016 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.

April 8th, 2016 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)7.

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

April 8th, 2016 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/or2) 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, ando The new dataset can be (re)generated on the fly.

April 8th, 2016 16


In the Test Scenarios (chapter 6), the Principal will provide information exchanges between actors that match the above scenarios. 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.

April 8th, 2016 17


4 Key Technical ChallengesGiven 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

April 8th, 2016 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)8. 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 F8) 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-ConD3.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 6 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;

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

April 8th, 2016 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).

April 8th, 2016 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 formats9. 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.

9Translation 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.

April 8th, 2016 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 ontologies10, 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

10 This includes dealing with ever evolving standards.

April 8th, 2016 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.

April 8th, 2016 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)11.

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)12.

11In 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.12In the test scenarios, an example has been introduced.

April 8th, 2016 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.

April 8th, 2016 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.

April 8th, 2016 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.

April 8th, 2016 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’.

April 8th, 2016 28


5 Test approachThis chapter describes the test approach for testing the pre-commercial version of the V-Con Solution in Phase 3. The approach is based on the test approach used in Phase 2,and updated, among others, using the feedback from the Contractors during Phase 2.

5.1 Objectives

To prove fulfilment of the business and technical specifications, the Contractor will perform tests of its pre-commercial version of the V-Con Solutions during Phase 3, demonstrate the tests to the Principal and report them in its end of phase reports. The pre-commercial solution is expected to be a refined, enhanced, and more complete version of the prototype tested in Phase 2. Testing in Phase 3 will be based on realistic test scenarios, datasets, ontologies and Linking Rule Sets, provided by the Principal (elaborated in chapter 6), and on the pre-commercial solution, provided by the Contractor.

5.2 Approach for specifying and testing the V-Con solution

To be able to specify and test what information to exchange and share and the functionality required for managing data, there is a need for describing the business, the process, the roles involved, the subsets of information involved, the standards used for exchange and the way information needs to be processed.

The main sources for the testing of V-Con are as follows: First, the terminology (chapter 2), the V-Con approach (chapter 3) and the key

technical challenges (chapter 4) of this document; Second, the Business use cases as defined in BS P2 (V-Con BS P2, 2015) and the

Test Scenarios (chapter 6). The way the cases are described is partly based on the IDM standard of BuildingSMART / ISO. The cases describe the scope of the process, the roles and the interactions between the roles. By means of these descriptions, the events of information exchange are positioned in the process.

Third, the Test Scenarios. For the Business use cases test steps are defined that make up a test scenario described in a table. Each row represents a test step and is, as far as possible, linked to an event of information exchange (transaction) and specifies the ontologies, linking rule sets and datasets(and their format)that shall be used. See annex F for links to the Test Scenarios.

Based on the above a common approach for specifying tests for Phase 3 is used and described in annex B Explanation of Test Scenario description.

April 8th, 2016 29


6 Test ScenariosThis chapter describes the elaboration of so-called Test Scenarios: tests of the exchange of road information between actors and/or applications, based on the business use cases as described in BS P2 (V-Con BS P2, 2015). These Test Scenarios will be used by the Contractor to validate and demonstrate their pre-commercial V-Con Solutions in Phase 3.

6.1 Objectives of Test Scenarios

The objectives of the Test Scenarios are:1. The Test Scenarios are intended to be used by Contractor to validate and

demonstrate its pre-commercial V-Con Solutions, in Phase 3 of the V-Con PCP process.

2. The Test Scenarios illustrate to the Contractor the intended application of the V-Con Solution in the business processes of the Principal.

3. The Test Scenarios illustrate the Principal’s business requirements. Chapter 5 describes the testing approach. Both for the Contractors and for the Principal, the Test Scenarios are a way to get acquainted with this testing approach.

4. The demonstrations of the implemented Test Scenarios are intended to create awareness of and appreciation for the V-Con Solution from future users at Rijkswaterstaat and Trafikverket, and comparable organisations.

The Test Scenarios are not intended to describe the only targeted scenarios for applying the V-Con Solution at National Road Authorities. Instead, the Test Scenarios will describe concrete, representative and testable examples of the intended application to be used for the evaluation of the pre-commercial V-Con Solutions.

6.2 Additional information on the Final Solution Design and the pre-commercial V-Con Solution

Section 7.3 of the PCP Process P1document (V-Con PCP P1, 2015) provides a description of the deliverables by the Contractor at the end of Phase 3. For the evaluation at the end of Phase 3, both the Demonstrations of the pre-commercial V-Con Solutions and the Final Solution Design description are relevant.

For this evaluation, the Principal provides: Business use cases (V-Con BS P2, 2015), Test approach (chapter 5, annex B), Test scenario overview (section 6.3), Test scenario description (sections 6.4 and further), Test scenarios(see annex F), Test scenario ontologies (see annex F), Test scenario linking rule sets (see annex F), Test scenario datasets (see annex F), Support for using software applications at the Principal’s organisation, and The organisation of the demonstration sessions, including an appropriate meeting

room, and the V-Con End Conference.

April 8th, 2016 30


The Contractor must: Demonstrate its V-Con Solution during the dialogues, following the test scenarios and

allowing for ample interaction with the Principal’s representatives; the results from these interactive sessions will be basis for further improvements to be demonstrated in next dialogues; these dialogues will be held both in the Netherlands and Sweden.

Give two interactive demonstrations of its pre-commercial V-Con Solution to a team of representatives from the Principal; one in the Netherlands and one in Sweden. The Contractor follows the test scenarios provided and allows ample time for interaction. This demonstration will be organised by the Principal.

Provide output datasets from the pre-commercial V-Con Solution, according to the Test scenarios.

Give an interactive demonstrations of its pre-commercial V-Con Solution at the V-Con End Conference. The details of the demonstration will be decided upon later. The V-Con End Conference will be organised by the Principal.

Provide a Final Solution Design description, following the structure of the Key Technical Challenges in chapter 4 and referring to the functionalities implemented in the pre-commercial V-Con Solution where possible.

6.3 Test Scenarios Overview

The Test Scenarios (Annex F) describe the sequence of test steps based upon the Business Use Cases as described in BS P2 (V-Con BS P2, 2015). Based upon these Business Use Cases the following five test scenarios have been specified:

Rijkswaterstaat Alignment; Rijkswaterstaat Repavement; Trafikverket Alignment; Trafikverket Repavement; International Repavement.

A selection has been made in the relevant actors, roles, and transactions, as described in the BS P2, for the Test Scenarios. The choice in actors, roles, and transactions has been based upon:

Testing needs: testing all of the transactions described in the BS P2 would be too time consuming, focus has therefore been placed on high-priority transactions and their corresponding actors and roles;

Business needs: in order to simulate a logical business process certain lower priority transactions and their corresponding actors and roles have been added;

Technical needs: certain test steps do not have a corresponding transaction, but have been added to test certain Technical Challenges and solutions.

Each Test scenario will be described in the upcoming sections by: summarizing the scenarios; prioritizing transactions, actors and roles; introducing the corresponding datasets; and listing the applicable ontologies. Section 6.4 and 6.5 will describe the Dutch Test Scenarios for Rijkswaterstaat: Alignment and Repavement. Next, the Swedish Test Scenarios will be addressed in section 6.6 and 6.7. This chapter will then end with the summary of the International Test Scenario. For more information on the outline of the columns and definitions used in the Test Scenario spreadsheets see Annex B.

April 8th, 2016 31


6.4 Test Scenario Rijkswaterstaat Alignment

This section will summarise the Dutch Test Scenario for Rijkswaterstaat Alignment (Annex F). Section 6.4.1 will outline the choice in actors, roles and transactions and provides a non-exhaustive list of relevant ontologies. The section will conclude with a short overview of the datasets in section 6.4.2.

6.4.1 Actors, roles, transactions13

As previously explained in section 6.3, a selection has been made in the transactions and their corresponding actors and roles. As can be seen from Figure 9 the Rijkswaterstaat Alignment Test Scenario focuses on:

first, the start of a new project where the As-is road situation is transferred from the Asset management organisation to the Project organisation (T2) according to Dutch standards;

second, request for a new road design by the Project organisation and transfer of the As-is and As-planned road situations to the Dutch Designer (T4) according to Dutch standards;

third, the Dutch Designer delivers the As-designed road situation to the Project organisation (T5) according to Dutch standards;

next, in order to assess the As-designed road situation the Project organisation transfers the initially agreed upon As-is situation and the new As-designed road situation to the Asset management organisation (T9) according to Dutch standards;14

after approval, the Project organisation then transfers the As-designed road situation, according to Dutch standards, to the Dutch Contractor (T6) to initiate the building phase of the new road.

Figure 9 The selected transactions for the Rijkswaterstaat Alignment Test Scenario

The following list of ontologies are deemed as relevant for the Rijkswaterstaat Alignment Test scenario: (for more information see Annex F)

COINS CORE 2.0; COINS RF RWS; RWS-OTL; COMMON_RWS;

13 Section 6.4.1 summarises the Rijkswaterstaat Alignment Test Scenario and is based upon the BS P2 Annex C: Alignment Use Case (V-Con BS P2, 2015). For more information please refer to the BS P2 Annex C (V-Con BS P2, 2015).14 The assessment procedures of As-designed road situations has been simplified to a great extent for testing the V-Con Solution.

April 8th, 2016 32


COMMON_NL.

The following is a summary of the above described transactions, roles and actors and is a subset of the transactions, roles and actors described in BS P2 Annex C: Alignment Use Case (V-Con BS P2, 2015).

Transaction

Priority Role 1 Role 2 Content of Transaction

T2 Medium Asset manager Project configuration manager

Container 1 As-is.ccrContainer 2 As-planned.ccr

T4 Medium Client’s contract manager

Designer’s contract manager

To be produced by VCS

T5 High Designer’s contract manager

Client’s contract manager

Container 3 As-designed.ccr


Builder’s contract manager


T9 Very High Project configuration manager

Asset manager To be produced by VCS

Table 1 Subset of transactions, roles and actors relevant for RWS Alignment Test Scenario

6.4.2 Datasets

Section 6.4.1 summarised the Rijkswaterstaat Alignment Test Scenario. In this Test Scenario three datasets are used as input for the testing: first, As-is dataset Alignment; second, As-planned dataset Alignment; and third, As-designed dataset Alignment. These dataset are to be provided by the Principal. At the core all three datasets are based upon existing data created by Rijkswaterstaat in the MBI (Middelen BIM Illustratie) project. In this project data was accumulated of a section of the road network in the province Zeeland (see Figure 10). This section of the road network encompasses:

the junction of the A58 highway and the N57 road, both state-owned; the crossing of the N57 and the Canal through Walcheren; various bridges, an aqueduct and a crossing with the railways.

April 8th, 2016 33


Figure 10 Section of road network in datasets (Source: Google Maps)

All three datasets have been enveloped or packed according to the COINS Container format for easy transfer. In the container the object related data is according to COINS 2.0 Core, COINS 2.0 RF-RWS, and RWS-OTL. As can be seen in Figure 11 these containers include various data types, formats and representations. The information in these envelopes (also referred to as containers) can amount to:

100 or more object types; 9,000 physical objects; 2,000 spatial objects.

Figure 11 3D Representation of the A58 and N57 junction “De Rode Leeuw”

Content RWS Alignment datasetsTo conclude, this section shortly describes the content of the datasets provided by the Principal for the Test scenario RWS Alignment.

Dataset Road situation Content of dataset Data formats

Container 1 As-is.ccr

As-is This dataset contains the As-is road network and asset object information. The dataset also contains the As-is

COINS CCR

April 8th, 2016 34



alignment for A58 highway, N57 and the junction between the two. These alignments have both an IFC and a GIS representation.

Container 2 As-planned.ccr

As-planned A small dataset containing capacity requirements, based upon an improvement proposal for the exit- and entry ramps of the N57.

COINS CCR

Container 3 As-designed.ccr

As-designed The dataset contains the As-designed alignment for the N57. The alignment has both an IFC and a GIS representation. The As-designed situation focuses on the widening of the exits and entry ramps of the N57.

COINS CCR

Table 2 Description of RWS alignment datasets

Datasets as COINS 2.0 containersThe datasets are zip files; with a file extension ccr, as specified by the COINS 2.0 standard. For more information on COINS 2.0 see www.coinsweb.nl and see appendix F. The structure of the datasets has been depicted in Figure 12.

COINS 2.0 uses an owl model for exchanging information. This model can be found in de Bim folder within the container. This model imports the COINS 2.0 ontology (COINS Core model) and two other ontologies:

1. COINS Core model;2. Extra ontology: for lifecycle modelling and other objects;3. ObjectTypeLibrary: containing many class definitions of Objects of Interests.

The rdf/owl model in the BIM directory may refer to documents via filename. The actual document can be found in the Doc directory. In these datasets various file formats are enveloped; such as GML, IFC, PDF, etc.

April 8th, 2016 35

http://www.coinsweb.nl/


Figure 12 Data structure COINS 2.0 container

6.5 Test Scenario Rijkswaterstaat Repavement

This section will summarise the Dutch Test Scenario for Rijkswaterstaat Repavement (Annex F). Section 6.5.1 will outline the choice in actors, roles and transactions and list the non-exhaustive list of relevant ontologies. The section will conclude with a short overview of the datasets in section 6.5.2.

6.5.1 Actors, roles, transactions15

In this test scenario an integrated contract is executed by a Dutch Construction company. As can be seen from Figure 13, Rijkswaterstaat employs the Dutch Construction company to repave a certain section of the road network (for more information on the road section see section 6.5.2). In order to do so, the following information is transferred:

in T2 the Asset Management organisation transfers the As-is situation and the Requirements for the pavement to the Project organisation, according to Dutch standards;

15 The Rijkswaterstaat Repavement Test Scenario incorporates both the Systems Engineering and the Repavement Use Cases as described in the BS P2 Annex A and B (V-Con BS P2, 2015).

April 8th, 2016 36


the Project organisation then transfers the As-is situation and the Requirements to the Dutch Construction company (T4) according to Dutch standards;

once the pavement has been rehabilitated, the Dutch Construction Company then transfers a Verification report (T5:a) according to Dutch standards and to demonstrate the fulfilment of the Requirements;

next, the Dutch Construction company transfers the As-built situation of the pavement to the Project organisation (T5:b) according to Dutch standards;

finally, the Project organisation then combines the Verification report and the As-built situation of the pavement into one dataset and transfers this As-built dataset to the Asset Management organisation (T6) according to Dutch standards. These standards are COINS, IVON and KERNGIS16.

Figure 13 The selected transactions for the Rijkswaterstaat Repavement Test Scenario

The following list of ontologies are deemed as relevant for the Rijkswaterstaat Repavement Test scenario: (for more information see Annex F)

COINS CORE 2.0; COINS RF RWS; RWS-OTL COMMON_RWS; COMMON_NL; IVON; KERNGIS.

Of particular interest are the test steps concerning complex conversions. In the Repavement Test scenario for Rijkswaterstaat, the Contractor is challenged to provide solutions for converting:

objectified properties of the asphalt slab within the COINS container to properties relevant for the Legacy system IVON (T9);

objectified properties of the asphalt slab within the COINS container to properties relevant for the Legacy system KernGIS (T9).

The following is a summary of the previously described transactions, roles and actors, and is a subset of the transactions, roles and actors described in BS P2 Annex B: Repavement use case (V-Con BS P2, 2015).

Transa Priority Role 1 Role 2 Content of

16 The acceptance procedures of As-Built documentation and the assets under rehabilitation have been simplified to a great extent, in order to facilitate the testing of the Pre-Commercial Solution. In reality Rijkswaterstaat emphasizes the importance of the pavement’s skidding resistance and will therefore rigorously test whether the rehabilitated top layer complies with the requirements for skidding resistance.

April 8th, 2016 37


ction TransactionT2 Medium Pavement

managerProject configuration manager



Construction company’s contract manager

Container 4 As-required.ccr

T5 High Construction company’s contract manager


Container 5 As-verified.ccrContainer 6 As-built.ccr

T6 Very High Project configuration manager

Pavement manager To be produced by VCS

Table 3 Subset of transactions, roles and actors relevant for RWS Repavement Test Scenario

6.5.2 Datasets

Similar to the Rijkswaterstaat Alignment Test Scenario, the datasets for the Repavement Test Scenario are all based upon the MBI data and are to be provided by the Principal. These datasets are input for certain test steps in the Test Scenario (see Annex F).

Figure 14 Section of road network under rehabilitation (source: RWS BIM Programme 2014, MBI Scenario’s)

The test scenario and datasets focus on the repavement of the A58 highway. In particular, the A58 highway from Vlissingen to Arnemuiden, between exit 39 (MiddelburgseSchroeweg) and exit 37 (Arnemuiden) (see Figure 14). The Repavement Test Scenario focuses on:

rehabilitation of the top layer of the asphalt slabs (including markings and strips); reconstruction of the exit ramp (the widening of the exit is paved).

Content RWS Repavement datasetsTo conclude, this section shortly describes the content of the datasets provided by the Principal for the Test scenario RWS Repavement.



As-is The As-is dataset used in the Alignment Test Scenario is re-used for

COINS CCR

April 8th, 2016 38


the Repavement Test Scenario. Please refer to Table 2 for more information on the content of the As-is dataset.

Container 4 As-required.ccr

As-required Includes functions, requirements, object structures and prescribed verifications.

COINS CCR

Container 5 Verification.ccr

Verification report

Report describing the manner in which the Construction company has fulfilled the requirements, according to the previously prescribed verifications.

COINS CCR

Container 6 As-built.ccr

As-built New and altered objects, such as the new top layer of asphalt and the corresponding markings and strips. The data delivered is according to the RWS OTL and describes asphalt materials and certificates.

COINS CCR

Table 4 Description of RWS Repavement datasets

Similar to the datasets for the Dutch Alignment Test Scenario, the datasets for this Repavement scenario have been enveloped for easy transfer. The following COINS 2.0 containers have been produced for testing the Pre-Commercial V-Con Solution according to the Repavement and Systems Engineering Use cases (Annex A and B of the BS P2):

As-is situation road situation for both alignment and repavement; As-required situation for repavement; Verification report for repavement; As-built situation for repavement.

April 8th, 2016 39


6.6 Test Scenario Trafikverket Alignment

The test scenario is based on data related to an ongoing project in Sweden, bypass Stockholm. Content in datasets might not reflect the current status of the project.

Figure 15 Overview Stockholm by pass (unknown source)

April 8th, 2016 40


Figure 16 Detail over the actual part “Kungens kurva” where we have a very limited set of test data.

6.6.1 Actors, roles, transactions

The Trafikverket Alignment test scenario is based on the Alignment use case as described in the BS P2 Annex C: Alignment Use Case (V-Con BS P2, 2015). The test scenario can be found in Annex F. As previously explained in section 6.3, a selection has been made in the transactions and their corresponding actors and roles. This selection has been performed on the basis of the following assumptions:

The Trafikverket test scenario does not cover the transactions/activities that are out of scope for the V-Con Solution;

transactions that do not involve the Project organisation and/or have a low priority are out of scope for the V-Con Solution;

i.e. transactions T3, T7, T10 and T11 are omitted and thereby the actors and roles associated with these transactions;

The roles and persons associated with the roles should be implemented in the solution;

The roles involved are defined in the test steps in the scenario description and have been depicted in Figure 17;

To include a more “GIS based” test step we have made the asset management organisation “internal” transaction/activity T1 part of the scenario i.e. handled by the Project organisation;

We have split the transaction T9 in a first step (T9a) where the Asset manager inspects the data before it’s transferred (T9b);

Transaction T8 in BS in this scenario essentially handles loading applicable ontologies.

April 8th, 2016 41


Figure 17 Overview Trafikverket Alignment Test Scenario

The following list of ontologies are deemed as relevant for the Trafikverket Alignment Test scenario: (for more information see Annex F)

TRV-IDM; CityGML; IFCAlignment; ANDA; COMMON_SE.

6.6.2 Datasets

The datasets created for the Trafikverket Alignment test scenario are based upon the life cycle phases:

current situation, also known as “As is”; early planning; design; construction.

The description of the created datasets can be found at the end of this section in Table 5.

The datasets cover an area including “Kungens kurva” and essentially the road network and road related features/properties within the area. Reason for double datasets is to test that the V-Con Solution handles GIS standards, enable “same as” and enrichment by having separate datasets with objects relating to same physical “things” and to demonstrate to principal benefits with the linked data approach.

The scenario starts with that the project configuration manager imports the “as is” situation based on CityGML data and extracts from the asset management system in TRV. Next steps are to prepare CityGML data for early planning. The CityGML dataset needs to be “enriched” with data from the TRV-IDM dataset before it is exported to the Planner.

April 8th, 2016 42


Figure 18 depicts how “facts” are gathered to fulfil the needs of the Planner. A prerequisite is to manually identify “SameAs” links between objects in the two datasets. Based on that and Linking Rule Sets basic, TRV-IDM—COMMON_SE and CityGML—COMMON_INT, “facts” can be derived by standard OWL. The property conversion “gml:name = f(roadNumber, euroRoad)” is probably not possible in standard OWL Contractor is encouraged to propose (and implement) a solution.

Figure 18 Overview of the “SameAs” and “Enrichment” scenario

Linking Rules sets deemed relevant for this test scenario: For early planning; LRS involved are CityGML—COMMON_INT. Underlying assumption: The TRV-IDM based dataset should include RoadSpace

representing the road area. No translation of geometry is needed since RoadSpace in COMMON_INT can have a Shape with “any” geometry.

LRS involved are IFCAlignment—COMMON_INT, TRV-IDM—COMMON_SE and ANDA—COMMON_SE. (for design life cycle)

Content Trafikverket Alignment datasets

Dataset Life cycle phases Content Data formats

1 current situation “As is”

Extract from TRV asset management system based on ontology TRV-IDM

RDF/XML


Data reflecting another view of the road network and the surrounding of the network (from Open Street Map and converted) based on ontology CityGML

GML

April 8th, 2016 43


Dataset Life cycle phases Content Data formats


The “As Is” design of alignment for the main road based on IFCAlignment

SPFF

4 Early planning CityGML delivered to “Planner” with the current network as CityGML:Road.

GMLLOD 0

5 Early planning The planned road corridor for a ramp is returned in a CityGML dataset as Road with the new road defined by a road (area). This corridor represents the first version of the of the new road.

GMLLOD1

6 Early planning The planned ramp is exported to asset management (for approval) based on the ANDA(COMMON_INT) ontology.

RDF/XML

7 Design CityGML with the corridor for the new road is exported to designer

GML

8 Design IFCAlignment for the existing main road is exported to designer

SPFF

9 Design IFC with designed alignment for a ramp is imported from designer

SPFF

10 Design Asset manager has a preview on design via SPARQL before importing data

RDF/XML

11 Design The new designed alignment for a ramp is exported to asset management as ANDA

RDF/XML

12 Construction Alignment transferred to contractor. No changes should be made to alignment in this life cycle phase just maybe the baseline.

IFC XML

Table 5 Description of Trafikverket Alignment datasets

6.7 Test Scenario Trafikverket Repavement

The test scenario is based on an authentic repavement project conducted 2013. Only the activities related to the carriageway super structure (pavement) are included (no parking places, side strips etc.). Maintenance of road markings is not part of re-pavement in Trafikverket. The scenario and the related datasets is partially based on the methodology used today within Trafikverket e.g. reporting templates. Some of the data-sets like as is data and requirements are “invented” within V-Con. The project is a “build contract” i.e. in the current organisation at Trafikverket, the pavement manager in the asset management organisation has performed the design.

April 8th, 2016 44


Figure 19 Overview of the re-pavement project


The test scenario is based on use case Repavement in BS P2 Annex C: Repavement Use Case (V-Con BS P2, 2015). The test scenario can be found in Annex F.The roles and persons associated with the roles should be implemented in the solution. The roles involved are defined in the test steps in the scenario description. Only the roles within the Project organisation are of interest.

Figure 20 Overview Trafikverket Repavement Test Scenario

April 8th, 2016 45


The following list of ontologies are deemed as relevant for the Trafikverket Alignment Test Scenario: (for more information see Annex F)

TRV-IDM; IFC4_ADD1; ANDA; COMMON_SE

6.7.2 Datasets

In general, compared with the description of the Repavement use case in BS, most of the test results, reports and other kind of documentation are omitted in the test though there are some links to documents within the datasets.

The re-pavement concerns the three upper layers (from top: wearing layer, binding layer and bearing layer) of the road body. In the project the wearing layer is fully re-established while the binding layer and bearing layer is repaired spot-wise and/or by material replacement. Trafikverket does not keep records of different “slabs” in specifications and reporting but merely information concerning the different layers and there outreach within the project. The split in different data-sets reflects the information architecture within Trafikverket and thereby different context ontologies.

Content TRV Repavement datasets

Dataset Road situation Content Data formats

1 As-is Current road network situation in the area covering the repavement project. The data essentially consists of network, road numbers, functional road class, speed limits and average daily traffic.

TRV-IDM/XML

2 As-is Road condition data in the area, the municipality, covering the repavement project.

ANDA/XML

3 As-required Includes requirements on the road condition of the repaved part of the road.

ANDA/XML

4 Project data General project information TRV-IDM/XML

5 As-built New and altered objects, such as the new top layers and new road surface condition. The data delivered is according IFC-LD ……

IFC4_ADD1/SPFF

Table 6 Description of TRV Repavement datasets

April 8th, 2016 46


6.8 Test Scenario International Repavement

This section will summarise the International Test Scenario (Annex F). Section 6.8.1 will outline the choice in actors, roles and transactions and list the non-exhaustive list of relevant ontologies. The section will conclude with a short overview of the datasets in section 6.8.2.


In contrast to the previous Test Scenarios, the International Test Scenario describes a test case in which cross country data deliveries take place. As can be seen from Figure 21, in the International Repavement test case a Swedish Construction company has executed a rehabilitation project, in which the company has repaved the asphalt along the A58 highway. The following information deliveries are simulated in the International Test Scenario:

Swedish Construction company transfers the As-Built data of the executed repavement contract to the Project organisation (T5) according to Swedish standards;

after which, the responsible role within the Project organisation converts the As-built data using the V-Con Solution to Dutch standards and transfers the COINS container to the Asset Management organisation (T6).17

The International Test Scenario challenges the Contractor to provide solutions for complex conversions. The challenge is to convert:

Swedish location information, which is coordinate based, to Dutch location information, according to COINS standards;

Swedish physical slab information, for instance stone sizes in centimetres, to Dutch physical slab information, such as stone sizes “small”, “medium”, or “large”.

Figure 21 Overview International Repavement Test Scenario

The following list of ontologies are deemed as relevant for the International Repavement Test scenario: (for more information see Annex F)

COMMON_INT COMMON_RWS; COMMON_NL; COINS CORE 2.0; COINS RWS RF; RWS-OTL;

17 The acceptance procedures of As-Built documentation and the assets under rehabilitation have been simplified to a great extent, in order to facilitate the testing of the Pre-Commercial Solution. The main goal of this International Test scenario is to showcase the added value of the V-Con Solution.

April 8th, 2016 47


TRV-IDM.

The following is a summary of the above described transactions, roles and actors and is a subset of the transactions, roles and actors described in BS P2 Annex B: Repavement use case (V-Con BS P2, 2015).

Transaction Priority Role 1 Role 2 Content of TransactionT5 High Construction

company’s contract manager


TRV-IDM As-built

T6 Very High

Project configuration manager

Pavement manager


Table 7 Subset of transactions, roles and actors relevant for RWS Repavement Test Scenario

6.8.2 Dataset

The test scenario and dataset focus on the repavement of the A58 highway. In particular, the A58 highway from Vlissingen to Arnemuiden, between exit 39 (MiddelburgseSchroeweg) and exit 37 (Arnemuiden) (see Figure 14). The International Repavement Test scenario focuses on rehabilitation of the top layer of the asphalt slabs

Dataset Road situation Content Data formats

1 As-Built New and altered objects, such as the new top layer of asphalt. The data delivered is according to the TRV-IDM ontology and describes project information, asphalt materials, certificates and “TRV”-report.

TRV-IDM/XML

Table 8 Description of International Repavement datasets

April 8th, 2016 48


Introduction to annexesSeveral 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 documentation

April 8th, 2016 49


Annex TC1: Support ontology-based handling of datasetsOWL 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 22 OWL 2, ontologies and related document formats

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

April 8th, 2016 50


Ontologies and Linking Rule Sets Phase 3

Figure 23 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 6. 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 23 Overview of ontologies and linking rule sets to be used in Phase 3

April 8th, 2016 51


Figure 24 Linking rule sets in the 5 Test Scenarios

Figure 25 Key External Semantic Resources

April 8th, 2016 52


Annex TC2: Support handling datasets in non-linked data formatsThe 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-21http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=33713

IFCALLIGNMENTIFC4ADD1

http://www.buildingsmart-tech.org/future/linked-data/ifcowl/20150925_latest/IFC4_ADD1.owlIFC4 Add1ISO 10303-21:2002

Must

XSD/XML

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

https://en.wikipedia.org/wiki/XMLhttp://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 ModelRWS Reference FrameworkRWS-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 9 Data Structures/Formats for non-geometry data to be supported in Phase 3

April 8th, 2016 53

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


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

http://www.citygml.org/

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

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



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


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



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



Annex TC4b: Connect and TC5: View (connected) informationThe 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/specifications/ifc-releases/ifc4-add1-release(chose “access EXPRESS file”)

https://en.wikipedia.org/wiki/ISO_10303-21http://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/XMLhttp://www.w3.org/TR/2006/REC-xml11-20060816/

GML 3.1.1/XML1.1

Incl. Alignment extension

Must

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

April 8th, 2016 54


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

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


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



Annex TC6/TC7: Ensure system quality and ensure a future-proof systemThis 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 concernsThe 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 functionalityThere 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 couplingReduction 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 definitionsData 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 interoperabilitySoftware 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/componentsComponents, 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

April 8th, 2016 55


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 styleProvides 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 styleThis 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 styleService-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.

April 8th, 2016 56


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.

April 8th, 2016 57


Annex A: Figures and TablesFigure 1 Document structure for the V-Con Pre-Commercial Procurement process 5Figure 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. 9

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

Figure 4 A look inside the V-Con Solution 12Figure 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 14Figure 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 14Figure 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 15Figure 8 Key Technical Challenges positioned in the V-Con Solution 18Figure 9 The selected transactions for the Rijkswaterstaat Alignment Test Scenario 32Figure 10 Section of road network in datasets (Source: Google Maps) 34Figure 11 3D Representation of the A58 and N57 junction “De Rode Leeuw” 34Figure 12 Data structure COINS 2.0 container 36Figure 13 The selected transactions for the Rijkswaterstaat Repavement Test Scenario 37Figure 14 Section of road network under rehabilitation (source: RWS BIM Programme

2014, MBI Scenario’s) 38Figure 15 Overview Stockholm by pass (unknown source) 40Figure 16 Detail over the actual part “Kungens kurva” where we have a very limited set of

test data. 41Figure 17 Overview Trafikverket Alignment Test Scenario 42Figure 18 Overview of the “SameAs” and “Enrichment” scenario 43Figure 19 Overview of the re-pavement project 45Figure 20 Overview Trafikverket Repavement Test Scenario 45Figure 21 Overview International Repavement Test Scenario 47Figure 22 OWL 2, ontologies and related document formats 50Figure 23 Overview of ontologies and linking rule sets to be used in Phase 3 51Figure 24 Linking rule sets in the 5 Test Scenarios 52Figure 25 Key External Semantic Resources 52

Table 1 Subset of transactions, roles and actors relevant for RWS Alignment Test Scenario 33

Table 2 Description of RWS alignment datasets 35Table 3 Subset of transactions, roles and actors relevant for RWS Repavement Test

Scenario 38Table 4 Description of RWS Repavement datasets 39Table 5 Description of Trafikverket Alignment datasets 44Table 6 Description of TRV Repavement datasets 46Table 7 Subset of transactions, roles and actors relevant for RWS Repavement Test

Scenario 48Table 8 Description of International Repavement datasets 48Table 9 Data Structures/Formats for non-geometry data to be supported in Phase 3 53Table 10 Data Structures and Formats for geometry data to be supported in Phase 3 54Table 11 General description of Test Scenario spreadsheets 61

April 8th, 2016 58


Annex B: Explanation of Test ScenarioThe V-Con test approach, as described in chapter 5, 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 11). 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 11 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

April 8th, 2016 59


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.


Verification Dataset

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

Principal

April 8th, 2016 60


Column header


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 11 General description of Test Scenario spreadsheets

April 8th, 2016 61


Annex C: Rijkswaterstaat’s general ICT requirementsAs 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.

April 8th, 2016 62


Annex D: Trafikverket’s general ICT requirementsAs 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.

April 8th, 2016 63


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/standardsCB-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/ws21ISO 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/61594OMG. (2015, June). Unified Modeling Language. Retrieved from

www.omg.org/spec/UML/index.htmV-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).V-Con D3.4.2c. (2016). Object Library Trafikverket. (to be published).

April 8th, 2016 64


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. V-Con TS P2. (2015). V-Con Technical Specification, Phase 2. V-Con TS P3. (2016). V-Con Technical Specification, Phase 3. 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 .

April 8th, 2016 65

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


Annex F: Links to the technical documentationThis annex contains direct links to the technical documentation to be used by the Contractor in Phase 3.

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

Technical Specification P3, version 20160301 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/ Modelling Guide (MG) Linking Guide (LG) Overview ontologies and linking rule sets Documentation Integration IFC and Linked data – Proposal for Phase 3 Note on baselines Documentation COINS 2.018

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 formato 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: TV Alignment Trafikverket: TV 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/

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

April 8th, 2016 66

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

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

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

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

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

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

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

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

- evolv… · Web vie

Documents

Transcript of - evolv… · Web vie