EN 17632-1:2022

SLOVENSKI STANDARD
01-april-2023
Informacijsko modeliranje gradenj (BIM) - Semantični standard za modeliranje in
povezovanje (SML) - 1. del: Generični vzorci modeliranja
Building Information Modelling (BIM) - Semantic Modelling and Linking (SML) - Part 1:
Generic modelling patterns
Semantischer Modellierungs- und Verknüpfungsstandard (SMLS) für die
Datenintegration in der gebauten Umwelt
Modélisation d'informations de la construction (BIM) - Modélisation et liens sémantiques
(SML) - Partie 1 : Schémas de modélisation génériques
Ta slovenski standard je istoveten z: EN 17632-1:2022
ICS:
35.240.67 Uporabniške rešitve IT v IT applications in building
gradbeništvu and construction industry
91.010.01 Gradbeništvo na splošno Construction industry in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 17632-1
EUROPEAN STANDARD
NORME EUROPÉENNE
December 2022
EUROPÄISCHE NORM
ICS 35.240.67
English Version
Building information modelling (BIM) - Semantic
modelling and linking (SML) - Part 1: Generic modelling
patterns
Modélisation d'informations de la construction (BIM) - Semantischer Modellierungs- und
Modélisation et liaisons sémantiques (SML) - Partie 1 : Verknüpfungsstandard (SMLS) für die
Schémas de modélisation génériques Datenintegration in der gebauten Umwelt
This European Standard was approved by CEN on 12 September 2022.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2022 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 17632-1:2022 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 7
3 Terms and definitions . 8
4 Symbols and abbreviated terms .11
4.1 Symbols .11
4.2 Abbreviated terms .11
5 Semantic modelling levels of capability .13
6 L1: Information language .14
6.1 Conceptual L1: Information language.14
6.2 Concrete L1: Information language bindings .16
6.3 Modelling patterns .19
7 M1: Information model .28
7.1 Top level information model .28
7.2 Systems engineering extension.30
8 Implementing SML in code .32
9 Conformance .32
9.1 General .32
9.2 Conformance on language level .32
9.3 Conformance on semantic level .33
Annex A (normative) SML implementation in ‘linked data’ .34
A.1 Introduction .34
A.2 SKOS part .34
A.3 RDFS part .40
A.4 OWL part .48
A.5 SHACL part .53
Annex B (normative) Selected W3C RDF language subsets .58
B.1 General .58
nd
B.2 XML schema (XSD), part 2: Datatypes 2 edition .58
B.3 Resource description framework (RDF).58
B.4 Simple knowledge organization system (SKOS) .59
B.5 Resource description framework schema (RDFS) .59
B.6 Web ontology language (OWL) .60
B.7 Shape constraint language (SHACL) .61
Annex C (informative) SML Example in SKOS/RDFS/OWL/SHACL (Turtle format) .64
C.1 Example description .64
C.2 SKOS part .64
C.3 RDFS part . 66
C.4 OWL part . 69
C.5 SHACL part . 70
C.6 Data part . 71
Annex D (informative) Relationships with other asset/product modelling standards . 73
D.1 General . 73
D.2 Relationship with the ISO 21597 series . 73
D.3 Relationship with EN ISO 23387 . 73
D.4 Relationship with the ISO 15926 series . 92
Annex E (informative) Linking information . 94
E.1 Types of linking . 94
E.2 Language-level language link sets . 94
Bibliography . 96

European foreword
This document (EN 17632-1:2022) has been prepared by Technical Committee CEN/TC 422 “Building
information modelling (BIM)”, the secretariat of which is held by SN - Norway.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by June 2023, and conflicting national standards shall be
withdrawn at the latest by June 2023.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the United
Kingdom.
Introduction
This document is about the built environment. In the built environment, assets relating to buildings and
infrastructures need to be managed across their entire life cycle, involving programming, design,
construction, operation, modification and demolition or disassembly. Vast amounts of valuable
information about them are created or captured, stored and communicated according to a diverse range
of forms and structures - and often lost again.
To manage these projects and their resulting assets more efficiently and effectively, information needs to
be findable, accessible, interoperable and reusable (FAIR). The world wide web consortium (W3C)
provides open and generic linked data (LD) and semantic web (SW) technologies [1] which are capable
of providing this ‘FAIRness’ giving information a common form (‘syntax’) and structure (‘semantics’).
Using the ‘new European Interoperability Framework’ (EIF) [9] terminology, this document focuses on
syntactic and semantic interoperability.
This document specifies how organizations in the built environment can apply this W3C technology to
best suit their needs. For example, it can be used within organizations to communicate information
internally between various business departments and software, or it can be used externally to publish
information across the multitude of databases and organizations in the sector.
Application of this document will in particular help to align and integrate relevant ‘modelling worlds’ for
the built environment, typically involving already existing complex information models, like in Building
Information Modelling (BIM), Geographical Information Systems (GIS), Systems Engineering (SE),
Monitoring & Control (M&C) and Electronic Document Management (EDM).
Regarding to BIM Building Information Modelling, this document has been prepared with the
EN ISO 16739-1 [11] Industry Foundation Classes (IFC) information model in mind, and it has been
aligned with the revision work of EN ISO 12006-3 [17] (used to extend IFC via a buildingSmart data
dictionary (bSDD)). More specifically, this document offers a ‘linked data’ view on the ‘data templates’
related to CEN TC442/WG4. It provides a way to represent the ‘attributes’ for ‘properties’ of
EN ISO 23386:2020 [15] implemented according to EN ISO 23387:2020 [16], again involving
EN ISO 12006-3.
As any other technical specification, this document requires expertise and experience in specifying,
procuring and delivering work results. As semantic modelling and linking is in the domain of computer
science, the content is aimed at those professionals. This document however, provides a standardized
approach for the built environment, and thus this introduction addresses the sector and its decision
makers.
Wherever the sector could benefit from better ways of searching, finding and (re)using information, this
document specifies how to store, model, publish and link this information, with the aim of modelling
information once in a standardized way, instead of adapting and transforming information on an ad hoc
basis. In other words, it is not a matter of shifting information structures already in place, but a matter of
modelling them for publishing on the Web/internet in more cloud-native ways.
The key principle of this document is to keep semantic modelling as simple and standardized as possible.
The objectives for capability range from machine-readable information (interpreted by humans) via (as
far as possible) machine-interpretable information to fully integrated and interlinked information
sources.
This document is complementary to other ISO standards. In the Annex D, related ISO standards are listed
and the exact relationships are described.
The standardized modelling patterns introduced in this document may be applicable to other industry
sectors as well.
1 Scope
This document addresses syntactic and semantic interoperability for information describing assets going
through their life cycle in the built environment. It assumes the underlying technical interoperability
provided already by the Internet/World Wide Web (WWW) technology-stack. The syntactic aspects
relate to the Linked Data (LD)/Semantic Web (SW) formats and the SPARQL direct access method
provided. The semantic aspects relate to the LD/SW-based information models in the form of thesauri
and ontologies giving meaning to the information.
The following information architecture (Figure 1) applies.

Figure 1 — Information architecture with (grey areas indicating the scope of this document)
This document specifies:
— a conceptual “L1: Information language” with four RDF-based language bindings being SKOS, RDFS,
OWL and SHACL, including:
— a choice of ‘linked data’/RDF-based formats (to be used for all modelling and language levels);
and
— a generic Top Level Information Model of a total “M1: Information model”, here “an upper ontology”,
including:
— a set of generic information modelling patterns for identification, annotation, enumeration
datatypes, complex quality/quantity modelling, decomposition and grouping.
This modelling approach for information models and information sets is relevant within the built
environment from multiple perspectives such as:
— Building information modelling (BIM);
— Geographical information systems (GIS);
— Systems engineering (SE);
— Monitoring & control (M&C); and
— Electronic document management (EDM).
Annex E discusses in an informative way how the information models and sets relevant for these different
worlds can be linked together using LD/SW technology.
This document does not specify a full meta-‘information model’, sometimes referred to as a ‘Knowledge
Model (KM)’. EN ISO 12006-3 provides such an often used model for the built environment. In Annex D,
Subclause D.3 it is shown how this existing model can be made compliant to this document. The only
direct support for this meta level comes in the form of the possibility to define ‘types’ (enumeration types
or concept types) and ‘objectifications’ as metaconcepts.
This document does not specify a meta-‘information language’ since this is already provided by the
concrete RDF-based language bindings (being RDFS).
The scope of this document in general excludes the following:
— Business process modelling;
— Software implementation aspects;
— Information packaging and transportation/transaction aspects already handled by ISO TC59/SC13
Information container for linked document delivery (ICDD) ([13]) respectively various information
delivery manual (IDM) / information exchange requirements (EIR)-related initiatives; and
— Domain-specific (here: ‘built environment’-specific) content modelling in the form of concepts,
attributes and relations at end-user level (the actual ontologies themselves) beyond a generic top
level information model (‘upper ontology’) and modelling and linking patterns.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements for this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
JSON-LD 1.1, A JSON-based Serialization for Linked Data, W3C Recommendation, 16 July 2020,
https://www.w3.org/TR/json-ld11/
OWL 2 Web Ontology Language, Document Overview (Second Edition), W3C Recommendation,
11 December 2012, https://www.w3.org/TR/2012/REC-owl2-overview-20121211/
RDF 1.1 Concepts and Abstract Syntax, W3C Recommendation, 25 February 2014,
https://www.w3.org/TR/rdf11-concepts/
RDF 1.1 Turtle, W3C Recommendation, 25 February 2014, https://www.w3.org/TR/turtle/
RDF 1.1 XML Syntax, W3C Recommendation 25 February 2014, https://www.w3.org/TR/rdf-syntax-
grammar/
RDF Schema 1.1, W3c Recommendation, 25 February 2014, https://www.w3.org/TR/rdf-schema/
SHACL (Shapes Constraint Language). W3C Recommendation, 20 July 2017,
https://www.w3.org/TR/shacl/
SKOS Simple Knowledge Organization System Reference. W3C Recommendation, 18 August 2009,
https://www.w3.org/TR/skos-reference/

Hereafter referred to as just “OWL”.
SPARQL 1.1 Overview, 21 March 2013, W3C Recommendation, https://www.w3.org/TR/sparql11-
overview/ (referencing, among others, the next two, more specific, references)
SPARQL 1.1 Query Language, W3C Recommendation, 21 March 2013,
https://www.w3.org/TR/2013/REC-sparql11-query-20130321/
SPARQL 1.1 Protocol, W3C Recommendation, 21 March 2013, https://www.w3.org/TR/sparql11-
protocol/
XML Schema Part 2: Datatypes, Second Edition, W3C Recommendation, 28 October 2004,
https://www.w3.org/TR/xmlschema-2/
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 6707-1 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
3.1
asset
item, thing or entity that has potential or actual value to an organization
[SOURCE: ISO 55000:2014, 3.2.1, modified – Note 1, 2 and 3 to entry have been removed.]
3.2
attribute
inherent characteristic
Note 1 to entry: The term used in EN ISO 12006-3 is xtdProperty.
[SOURCE: EN ISO 9241-302:2008, 3.4.2, modified – Note 1 to entry has been added.]
3.3
built environment
collection of man-made or induced physical objects located in a particular area or region
[SOURCE: ISO 6707-3:2017, 3.1.3]
3.4
closed-world assumption
CWA
assumption, in a formal system of logic used for knowledge representation that a statement that is true
is also known to be true; therefore, conversely, what is not currently known to be true is false
Note 1 to entry: Typically combined with the Unique Name Assumption (UNA).
3.5
concept
abstract entity for determining category membership
[SOURCE: ISO/IEC 2382:2015, 2122971]
3.6
data format
predetermined arrangement of data on a data medium
[SOURCE: ISO 5127:2017, 3.1.13.12]
3.7
exchange information requirement
EIR
information requirement in relation to an appointment
[SOURCE: EN ISO 19650-1:2018, 3.3.6]
3.8
hierarchy
concept system in which all concepts are related in hierarchical relations that form a partial ordering
[SOURCE: ISO/IEC TR 11179-2:2019, 3.8]
3.9
information model
data model
description of the organization of information giving structure/meaning (‘semantics’) to an information
set
3.10
information set
data set
named collection of information describing or specifying something you can or could point at in reality
3.11
level of capability
LoC
semantic modelling power provided by the ‘linked data’ languages related to the needs of a specific use
case type
3.12
machine-interpretable
able to (to a certain extent) be semantically interpreted by a computer
3.13
machine-readable
able to be read and processed by a computer
3.14
meronomy
type of hierarchy which deals with part-whole relationships
[SOURCE: ISO/IEC 11179-3:2013, 3.2.73]
3.15
metadata
data about data (documents, information sets, information models or elements in those)
3.16
n-ary
having an arity of n
3.17
object
any part of the perceivable or conceivable world
Note 1 to entry: An object is something abstract or physical toward which thought, feeling, or action is directed.
Note 2 to entry: Within this document, the term individual is used as synonym of object.
[SOURCE: EN ISO 12006-2:2020, 3.1.1, modified – added Note 1 and Note 2 to entry.]
3.18
ontology
formal, explicit specification of a shared conceptualization
Note 1 to entry: An ontology typically includes definitions of concepts and specified relationships between them,
set out in a formal way so that a machine can use them for reasoning.
[SOURCE: ISO 25964-2:2013, definition 3.57]
Note 2 to entry: See also ISO/TR 13054:2012, definition 2.6; ISO/TS 13399-4:2014, definition 3.20;
ISO 19101-1:2014, definition 4.1.26; ISO 18435-3:2015, definition 3.1; ISO/IEC 19763-3:2010, definition 3.1.1.1.
Note 3 to entry: Applied in this document as a set of concepts, reference individuals, value types, reference values,
attributes, relations, constraints and derivations.
[SOURCE: ISO 5127:2017, 3.1.2.03, modified – added Note 3 to entry.]
3.19
open-world assumption
OWA
opposite of the closed-world assumption stating that lack of knowledge does not imply falsity
Note 1 to entry: typically combined with the No Unique Name Assumption (NO-UNA).
3.20
property
attribute or a relation
Note 1 to entry: This is also the term used in RDF (rdf:Property).
3.21
relation
relationship
sense in which concepts can be connected, via constituent roles
Note 1 to entry: The related concepts may be general or individual concepts.
Note 2 to entry: The term used in EN ISO 12006-3 is xtdRelationshipToSubject.
EXAMPLE Causality is a relation with two constituent roles: cause and effect.
[SOURCE: ISO/IEC 11179-3:2013, 3.2.119, modified – added Note 2 to entry.]
3.22
systems engineering
SE
interdisciplinary approach governing the total technical and managerial effort required to transform a
set of stakeholder needs, expectations, and constraints into a solution and to support that solution
throughout its life
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.65]
3.23
taxonomy
type of hierarchy which deals with generalization/specialization relationships
[SOURCE: ISO/IEC 11179-3:2013, 3.2.135]
3.24
top level information model
generic part of an information model (typically a generic taxonomy)
3.25
triple
statement in the form subject-predicate-object that expresses a fact
3.26
typology
type of hierarchy which deals with classification/instantiation relationships
3.27
use case
sequence of actions that an actor (usually a person, but perhaps an external entity, such as another
system) performs within a system to achieve a particular goal
[SOURCE: ISO/TR 17185-3:2015, 3.17; ISO/TR 25102, modified]
4 Symbols and abbreviated terms
4.1 Symbols
This document does not contain any symbols.
4.2 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
API application programming interface
BIM building information modelling
bSDD buildingSmart data dictionary
CWA closed world assumption
ECMA European computer manufacturers association international
EDM electronic document management
EIF European interoperability framework
EIR exchange information requirements
FAIR findable, accessible, interoperable, reusable [go-fair.org]
GIS geographical information systems
GUID globally unique identifier (typically assigned)
ICDD information container for linked document delivery [ISO]
IDM information delivery manual
IFC industry foundation classes [ISO]
IETF internet engineering task force
JSON JavaScript object notation [ECMA]
JSON-LD JavaScript object notation - linked data [W3C]
LD linked data (technology) [W3C]
LoC level of capability
M&C monitoring & control
OMG object management group
OWA open world assumption
OWL web ontology language [W3C]
QUDT quantities, units, dimensions and data types [qudt.org]
RDF resource description framework [W3C]
RDFS resource description framework schema [W3C]
RFC request for comments [IETF]
SE systems engineering
SHACL shapes constraints language [W3C]
SML semantic modelling and linking [CEN]
SPARQL sparql protocol and RDF query language [W3C]
SPFF step physical file format [STEP]
SSoF single source of facts
STEP standard for the exchange of product model data [ISO]
SW semantic web (technology) [W3C]
UML unified modelling language [OMG]
URI uniform resource identifier [W3C]
UUID universally unique identifier [IETF]
XML extensible markup language [W3C]
XSD extensible markup language schema definition [W3C]
W3C world wide web consortium
WWW world wide web [W3C]
5 Semantic modelling levels of capability
An appointing party shall define the levels of capability required for each use case.
Different use case types need different ‘levels of (semantic modelling) capability’ (LoC) related to the
required modelling power. This document specifies three main LoCs (Figure 2).

Figure 2 — Three use case types and related 'Levels of (semantic modelling) Capability’ (LoCs)'
The left part of Figure 2 represents the organizational use case type activity, the right side the related
(linked data) modelling languages available. The simplest use case type, requiring the weakest semantic
modelling, is the common understanding and alignment of terms and definitions used to describe assets,
their environment and internal structure. Weak modelling is sufficient here as a first step especially
targeted towards human interpretation. A good definition gives an end user guidance on how to later
classify and instantiate their information according to these terms. This level targets common human
understanding of terms and definitions and at least making sure the information is machine-readable.
Terms and definitions can be distributed as well as published on websites for others to refer to and reuse.
For this LoC-1 the RDF framework and the SKOS language shall be used.
More expressive power is needed whenever common understanding is required for the exchange or
sharing of asset information between digital systems (within or between parties). This can achieved with
LoC-2 where information is classified according to basic ontologies involving concepts, valuetypes,
attributes and relations and restrictions. This stronger level builds upon the lowest level making the
information also machine-interpretable. Because of this adding of semantics, limited automatic inference
of information from asserted information becomes possible. For this LoC-2 the RDF framework and the
RDFS language shall be used.
NOTE 1 OWL is defined on top of RDFS and is providing more modelling power than RDFS by introducing
‘restrictions’ that can be used to infer new information from asserted information.
The term ‘machine-interpretable’ should be understood in an informal sense.
NOTE 2 Machine-interpretation like humans do would ultimately require understanding of all the names and
labels used for the concepts, attributes and relations. At least the ontologies provide a level of structure defining the
possibilities and impossibilities for the data provided giving some machine-interpretable meaning to the
information.
Finally, to be able to integrate data for all kinds of decision support, even stronger semantics are needed.
This stronger knowledge comes in the form of explicit constraints and rules for the data against which
data can be verified respectively inferred assuming an open-world assumption (OWA) or closed-world
assumption (CWA). These constraints and rules can be definitional or operational, the latter specified by
the client brief or legalisation/regulation body on top of the definitional ones. For this LoC-3 the RDF
framework and (RDFS+OWL) and/or (RDFS+SHACL) shall be used.
Note 3 The W3C Recommendation for the SHACL specification (consisting of two parts: SHACL Core and SHACL-
SPARQL) is used for data verification, the SHACL 1.1 Advanced Features draft community track report [5] for data
inference.
Note 4 The default interpretation for data inference in case of OWL modelling is OWA, the default interpretation
for data verification in case of SHACL modelling is CWA.
6 L1: Information language
6.1 Conceptual L1: Information language
The conceptual L1: Information language that is still independent from concrete RDF-based languages is
specified as in Table 1.
Table 1 — Conceptual L1: Information language
Meta-set
1. Information model
2. Information set
3. Group
Meta-concept
4. Concept
5. Individual
6. Value type
7. Value
8. Attribute
8.1 Annotation
8.2 Quality
8.3 Quantity
9. Relation
Meta-relation From To
10. Grouping 1 to 3 (or) 3 to 9 (or)
11. Classification 4 or 5 4
(inverse: Instantiation)
7 6
12. Generalization 4 4
(inverse: Specialization)
6 6
8 8
9 9
13. Constraint (more complex n-ary)
14. Derivation (more complex n-ary)

From/To Meta-set/Meta-concept.
This conceptual information language contains meta-sets, meta-concepts and meta-relations.
Meta-sets
The first meta-set reflects a specification for information sets in general referred to as an information
model. Good examples of information models are vocabularies, thesauri, dictionaries and (basic or
advanced) ontologies. View models that only reuse (without changing) existing other models are also an
example of information models. In addition, there are information sets that contain individual
information typically according to/controlled by some information model. Finally, there can be user-
defined groups reflecting subsets of the information model or information set.
Meta-concepts
The first basic meta-concept being a member of an information model is a concept referring to abstract
notions as type of things of interest. The next one is an individual, an instance of a concept representing
something you can or could point at in reality. The next meta-concept is a valuetype, like a string, decimal,
double, boolean or enumeration type that have values as instances.
Then there are attributes describing intrinsic characteristics and relations describing extrinsic
characteristics of individuals of concepts. Attributes are further divided in annotations, adding human-
interpretable identifiers, names, labels, definitions etc. and machine-interpretable qualities and
quantities.
Relations in this document shall be binary relations since all specified language bindings in this document
use binary relations only. In case there is a need to model n-ary relations (n > 2) the modelling approach
shall be used as described in [6] following the specific complex relation pattern of 6.3.9.
— An example relation is decomposition (see 6.3.7), where constraints on this decomposition define a
socalled ‘meronomy’ or ‘typical decomposition’.
Meta-relations
Two meta-relations are specified:
— Classification (inverse: instantiation), from ‘concrete’ to ‘abstract’;
Concepts shall be instantiated with individuals. Such individuals get lexical values for attributes or
references for relations. Lexical values shall be classified according to some value type.
— Generalization (inverse: specialisation), from ‘specific’ to ‘generic’;
Concepts shall be specialized in other concepts; attributes shall be specialized in other attributes, and
relations shall be specialized in other relations. Specialized concepts, attributes and relationships
inherit all constraints and derivations of the concepts, attributes, relationships they are specialized
from.
These two mechanismsgive rise to two hierarchy types namely:
— a typology;
— a taxonomy.
Beside these two abstraction mechanisms the following other meta-relation should be used:
— Grouping, like for grouping all concepts, attributes, relations, etc. into one information model.
Finally, there are two more complex n-ary relations that define explicit rules that information should
comply to:
— Constraints, restricting the amount of values, the values themselves or both. Concepts, value types,
attributes and relations can have restrictions with respect to their source or target concepts (in case
of relations) or target value type (in case of attributes); and
— Derivations, describing how new values for attributes or relations shall be inferred from existing
asserted values. Constraints shall be “definitional” or represent requirements, regulations or
recommendations.
6.2 Concrete L1: Information language bindings
A language binding defines how the conceptual information language is mapped to the available
modelling constructs provided by a given concrete information language. To keep things as simple as
possible, this document uses wherever possible, the most simple and direct use of language constructs
available. This means that only quantities shall be ‘objectified’ and modelled as classes, qualities and
relation shall be directly modelled as RDF properties (in OWL: datatype properties respectively object
properties). This way, standard language functionalities offered like inverse relations and various
attribute or relation constraints types shall be often directly reused.
Below in Tables 2 and 3 the specifications are given for each modelling style per level of capability (LoC).
Table 2 — Specified language binding for LoC-1: Terminology and definition alignment with
SKOS
Language binding for LoC-1: Terminology and definition
Meta- set/concept/relation
alignment with SKOS
1. Information model skos:ConceptScheme
2. Information set not applicable
3. Group skos:Collection
4. Concept skos:Concept
5. Individual in general not applicable, only enumeration items: skos:Concept
6. Value type not applicable
7. Value not applicable
8. Attribute
8.1 Annotation existing RDFS/SKOS/SML annotations (see 6.3.5)
8.2 Quality skos:Concept
8.3 Quantity skos:Concept
9. Relation skos:Concept
10. Grouping skos:inScheme, skos:member
11. Classification skos:broader (only for enumeration type instances)
12. Generalisation skos:broader
13. Constraint not applicable
14. Derivation not applicable
NOTE 1 Individuals are not modelled. Therefore, rdf:type relations are not relevant. There is one exception: the
instances of “type classes” used for enumerated datatypes. Here the allowed values become SKOS concepts too,
related to the broader ‘enumeration type class’.
NOTE 2 Technical representation entities involving placement in space and time are also not relevant.
Table 3 — Specified language bindings for LoC-2&3: information exchange/sharing or
integration
Language binding for Language binding for Language binding for
Meta-
LoC-2: Information LoC-3a: Information LoC-3b: Information
set/concept/
exchange/sharing with integration with integration with
relation
RDFS (RDFS+) OWL (RDFS+) SHACL
1. Information owl:Ontology
model
2. Information owl:Ontology
set
3. Group rdfs:Container
4. Concept rdfs:Class owl:Class rdfs:Class
5. Individual rdfs:Resource (implicit) owl:NamedIndividual or rdfs:Resource (implicit)
anonymous individual
(both implicit)
6. Value type rdfs:Datatype, or rdfs:Datatype, or rdfs:Datatype, or
rdfs:Class + rdf:Property owl:Class + rdfs:Class +
for enumeration owl:ObjectProperty for rdf:Property for
datatypes enumeration datatypes; enumeration data
incl. owl:oneOf for fixed types; incl. sh:in for
sets fixed sets
7. Value plain or typed literal plain or typed literal plain or typed literal
(implicit) (implicit) (implicit)
8. Attribute
8.1 Annotation rdf:Property owl:AnnotationProperty rdf:Property
8.2 Quality simple via rdf:Property simple via simple via rdf:Property
owl:DatatypeProperty or or complex via
or complex via
complex via QualityValue range
QualityValue range
owl:ObjectProperty with
(except for
(except for
QualityValue range
enumerations)
enumerations)
(except for enumerations)
enumerations:
enumerations:
enumerations: rdf:Property with range
rdf:Property with range
owl:ObjectProperty with an instance of
an instance of
range an instance of
EnumerationType class EnumerationType class
EnumerationType class
Language binding for Language binding for Language binding for
Meta-
LoC-2: Information LoC-3a: Information LoC-3b: Information
set/concept/
exchange/sharing with integration with integration with
relation
RDFS (RDFS+) OWL (RDFS+) SHACL
8.3 Quantity simple via rdf:Property simple via simple via rdf:Property
owl:ObjectProperty
or complex via or complex via
or complex via QuantityValue range
QuantityValue range
owl:Objectproperty with
QuantityValue range
9. Relation simple via rdf:Property simple via simple via rdf:Property
or complex via owl:ObjectProperty or or complex via
RelationReference range complex via RelationReference
owl:ObjectProperty with range
RelationReference range
10. Grouping implicit (same file) or explicit via rdfs:member
11. Classification rdf:type
12. Generalisation rdfs:subClassOf or rdfs:subClassOf & rdfs:subClassOf &
rdfs:subPropertyOf rdfs:subPropertyOf rdfs:subPropertyOf
13. Constraint rdfs:domain or owl:Restriction sh:NodeShape &
a
rdfs:range rdfs:domain & rdfs:range
sh:PropertyShape
14. Derivation not applicable not applicable sh:Rule
a
When there is a domain and a range: mapping to a NodeShape with a PropertyShape (having a sh:targetClass in
case of explicit/separate target classes). When there is a range only: mapping to a NodeShape (always having a
sh:targetObjectsFrom).
NOTE 3 Since all (limited) machine-interpretable modelling really starts at LoC-2a, it will often be the starting
point that might be in a later stage extended towards LoC-3 for more advanced constraint/derivation modelling.
NOTE 4 In this document, Turtle is used for encoding SML itself (Annex A) and the SML Example(Annex C).
NOTE 5 Domain and range are positioned as ‘constraint’. An RDFS reasoner infers new information based on
these constraints (following the RDFS ‘entailment’). ‘Derivations’ are interpreted as user-defined inferences based
on user-defined rules.
NOTE 6 The term ‘Uniform Resource Locator’ (URL) refers to the subset of URIs that, in addition to identifying a
resource, provide a means of locating the resource by describing its primary access mechanism (e.g. its network
location).
NOTE 7 The owl:AllDisjointClasses type constraints have no direct SHACL counterpart. This is modeled in
SHACL as in the following example:
sml:AllDisjointClassesShape_1
a sh:NodeShape ;
sh:targetSubjectsOf rdf:type ;
sh:property [
sh:path (rdf:type [sh:zeroOrMorePath rdfs:subClassOf]) ;
sh:qualifiedValueShape [
sh:in (
sml:PhysicalObject
sml:InformationObject
sml:State
sml:Event
sml:Activity
) ;
] ;
sh:qualifiedMaxCount 1 ;
] ;
sh:property [ etc.
6.3 Modelling patterns
6.3.1 General
When mapping to a concrete language modelling patterns shall be applied as defined in 6.3.2 to 6.3.9.
6.3.2 Identification via URI strategy
A URI shall always be used to identify semantic resources following the RDF framework.
For optimal reuse and clarity the specific URI strategy should be specified as in Table 4.
Table 4 — URI strategy
— uri = ‘http’, [‘s’], ‘://’, internet domain, ’/’, [path], ’/’, reference
— reference =
a
— ‘term’, (‘/’ | ‘#’), term |
— def’, (‘/’ | ‘#’), (conceptname | attributename | relationname | reference-
b
individualname) |
c
— ‘id’, (‘/’ | ‘#’), individualname |
— ‘doc’, (‘/’ | ‘#’), documentname, [documentextension], [(‘/’ | ‘#’),
d
fragmentidentification]
Meta-symbols
defined by (a ‘production rule’)
=
symbol devider
,
predefined symbol (‘terminal symbol’)
‘…’
obligatory symbol
…
optional symbol
[ … ]
( … ) grouping
Logical ‘exclusiv
...