1. V-Con Modelling Issues Input for V-Con dialogues/expert meetings with vendors | Michel Böhms & Bart Luiten (TNO) and Lars Wikström & Olle Bergman (TRIONA)

2. Overview TNO-initiated
A. General issue on Meta-Modelling (not just for V-Con)
B. Specific issues on upcoming QUDT version 2.0
C. Syntax forms: now Turtle, what about popular JSON-LD?
TopQuadrant-initiated
D. Linking Rule Sets approach
“Beyond-OWL-capabilities”
Simple linking scenarios, same-as logic; conceptual or implementational
Check actual ‘same-as’ logic/requirements in use cases! (TRV & RWS)
E. Importing approach (+when import really needed)
TRIONA-initiated
F. More from Lars/Olle
Semmtech-initiated
G. Also support needed for less-semantic levels
- documents
- structured without schema
22 | V-Con Modelling Issues
20 September 2016

3. A. General issue on Meta-Modelling
Different projects with different goals use different ontology/’object type library (OTL)’ modelling approaches related to choice of meta-level which often hampers reuse, alignment and combination of results
Some have a Knowledge perspective
Some have a Data perspective
In the end you typically want BOTH perspectives combined in the best way
Even within one organisation
Example: V-Con (“data-perspective”) and KEBO (“knowledge-perspective”) within Rijkswaterstaat (RWS)
To understand the issue better let’s first be clear about the concept of ‘meta-level’
22 | V-Con Modelling Issues
20 September 2016

4. Meta-levels
Typically we deal with (and ‘have to model somehow’) three meta-levels:
In general
For example
‘Class’
owl:Class
1. Language
Instantiation*
rdf:type
A specific Class
:Road
2. Ontology
instantiation
rdf:type An
Individual
:The ‘A4’
road in NL
3. Individuals
22 | V-Con Modelling Issues
20 September 2016
* In set theory: ‘membership of a set’

5. Example situation (KEBO)
owl:Class
Language
:TechniqueType
:DamageType
Ontology
:EddyCurrent
:Cracking
Individuals
Note: The Ontology and Individuals levels capture Knowledge
* WikiPedia: The term eddy current comes from analogous currents seen in water when rowing using an oar,
causing localised areas of turbulence known as eddies give rise to persistent vortices.
Somewhat analogously, eddy currents can take time to build up and can persist for very short times
in conductors due to their inductance.
22 | V-Con Modelling Issues
20 September 2016

6. Relationship added (an ObjectProperty in OWL-speak)
Class
:Technique
Type
:measures
DamageType
:Damage
Type
domain
range
instantiation
(rdf:type)
Individual
:EddyCurrent
:Cracking
:measuresDamageType
Note: Again, the Ontology and Individuals levels capture Knowledge
(from here we leave out the language meta-level which stays the same)
22 | V-Con Modelling Issues
20 September 2016

7. In owl code (kebo1.ttl)
ONTOLOGY: :TechniqueType rdf:type owl:Class . :DamageType rdf:type owl:Class . :measuresDamageType rdf:type owl:ObjectProperty ; rdfs:domain :TechniqueType ; rdfs:range :DamageType . DATA: :EddyCurrent rdf:type :TechniqueType . :Cracking rdf:type :DamageType . :EddyCurrent :measuresDamageType :Cracking .
22 | V-Con Modelling Issues
20 September 2016

8. Observations
We are modelling ‘knowledge’ only, mostly as individuals (and some top-level classes)
However, we often (also) want to model the ‘real-life’ data: individuals of Techniques used at a point in time and Damages you can/could* point at in space
I.e. not abstract types but techniques and damages occurring in spacetime
One way to make this possible is to ‘promote’ the Individuals to become subclasses that can be instantiated into such ‘real’ individuals
Some knowledge is lost now that has to be added somehow:
The original “:EddyCurrent :measuresDamage :Cracking .”
The typical way to do it is to capture this knowledge in a Restriction now at the new class ‘EddyCurrent’
*existing respectively planned
22 | V-Con Modelling Issues
20 September 2016

9. Enabling ‘real’ data ObjectProperty Class :Technique** :Damage
:measures
Damage
:Damage
rdfs:domain
rdfs:range
Specialization*
(rdfs:subClassOf)
:EddyCurrent
:Cracking
Restriction: AllValuesFrom on :measuresDamage
instantiation
(rdf:type)
:Eddy
Current
Application11
:Cracking
Case 54
Individual
:measuresDamage
* set theory: subset of set
**meaning: ‘TechniqueApplication’
22 | V-Con Modelling Issues
20 September 2016

10. In owl code (KEBo2.ttl)
ONTOLOGY: :Technique rdf:type owl:Class . :Damage rdf:type owl:Class . :EddyCurrent rdf:type owl:Class ; rdfs:subClassOf :Technique ; rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom :Cracking ; owl:onProperty :measuredDamage ] . :Cracking rdf:type owl:Class ; rdfs:subClassOf :Damage . :measuresDamage rdf:type owl:ObjectProperty ; rdfs:domain :Technique ; rdfs:range :Damage . DATA (if available/relevant): :EddyCurrentApplication11 rdf:type :EddyCurrent . :CrackingCase54 rdf:type :Cracking .
22 | V-Con Modelling Issues
20 September 2016

11. Alternative
So far we started from three meta-levels where each item belonged to one level
The OWL2 Description Logic (DL) variant permits any amount of levels (below language level) via what they call “Punning”
See also:
We have to check whether this is actually any amount or just one level…
So alternatively, we can also add an extra level (not needing OWL Full variant)
Involving 3-step instantiation (rdf:type)
(==2-step below language level)
Note: ‘Ontology’ and ‘Data’ become mixed
Some items are both Class and Individual at the same time
22 | V-Con Modelling Issues
20 September 2016

12. Graphically :Technique Type :Damage Type :Technique* :Damage
:measures
DamageType
:Damage
Type
rdfs:domain
rdfs:range
:measuresDamageType
:Technique*
:Damage
:measures
Damage
rdfs:domain
rdfs:range
:measuresDamageType
:EddyCurrent
:Cracking
Restriction: AllValuesFrom on :measuresDamage
:Eddy
Current
Application 11
:Cracking
Case 54
:measuresDamage
22 | V-Con Modelling Issues
20 September 2016
*again meaning: ‘TechniqueApplication’

13. Owl code (kebo3.ttl)
:TechniqueType rdf:type owl:Class . :DamageType rdf:type owl:Class . :measuresDamageType rdf:type owl:ObjectProperty ; rdfs:domain :TechniqueType ; rdfs:range :DamageType . :Technique rdf:type :TechniqueType ; :measuresDamageType :Damage . :Damage rdf:type :DamageType . :measuresDamage rdf:type owl:ObjectProperty ; rdfs:domain :Technique ; rdfs:range :Damage . :EddyCurrent rdf:type :TechniqueType ; rdfs:subClassOf :Technique . :measuresDamageType :Cracking ; rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom :Cracking ; owl:onProperty :measuresDamage ] . :Cracking rdf:type :DamageType ; rdfs:subClassOf Damage . :EddyCurrentApplication11 rdf:type :EddyCurrent ; :measuresDamage :CrackingCase54 . :CrackingCase54 rdf:type :Cracking .
22 | V-Con Modelling Issues
20 September 2016

14. Other typical patterns
MaterialType versus MaterialUsed
Asphalt as instance of MaterialType & An AsphaltSlab in reality as instance of Asphalt
CatalogueItem versus ProductBought
BMW320i as instance of BMWType & MyBMW320i as instance of BMW320i
“Telegraaf” as instance of (Dutch) Newspaper and “MyTelegraafOnSaturday” as instance of “Telegraaf”
Or even more meta-levels (example from G.E.B. by D. Hofstadter)
Class
Newspaper
Telegraph
TelegraphOnSaturday
TelegraphOn2July2016 (morning edition)
MyTelegraphOn2July2016 (morning edition)
22 | V-Con Modelling Issues
20 September 2016

15. } Global Observations In the past also referred to as
With option 1 you need own-defined “specialisation/subclassing” info working on individuals (like also in QUDT version 2 where actual quantities and units are modelled as individuals)
With option 2 you lose data-level standard functionality like in default TQ SWA application generation (especially in the case without data; so where knowledge is only modelled the class-way)
Option 3 might be too powerful for direct support of reasoners etc.?
I.e.: hard to edit by TopBraid Composer from GUI, but accepted as imported file …
Generated SWA default app keeps working (2-level individuals shown)
Pure conceptually, Option 3 is what you want, so (at least) 4 meta-levels:
Language
Ontology
Types
Individuals (reflecting real-life) }
In the past also referred to as
“Generic, Specific, Occurrence” dimension
[Wim Gielingh, GARM, TNO])
22 | V-Con Modelling Issues
20 September 2016

16. Personal initial Preference
OPTION No 2
Natural class-level modelling of “types”
Reserve ‘individuals’ for real life stuff ‘things you can/could point at”
No need for an “own specialization” property (reuse of rdfs:subClassOf)
Simple OWL variant not disturbing reasoners and possibly more complex SPARQL querying involving Restrictions
Data level needs dependent on use case
Suppose “ReferenceProject” class/data
Links to individuals data? (this bridge has Crack_1 and Crack_2)
Or only to Class-level?(this Bridge had a typical Damage…)
BUT: OPTION 3 is conceptually very tempting…
Sub-issue: can we infer Restrictions on data-level from the meta-data on knowledge-level? (non-trivial! : i.e. can we formalize the link between property x and property xType?)
22 | V-Con Modelling Issues
20 September 2016

17. Sub-issue Graphically
:Technique
Type
:measures
DamageType
:Damage
Type
rdfs:domain
rdfs:range
:measuresDamageType
:Technique
:Damage
:measures
Damage
rdfs:domain
rdfs:range
:measuresDamageType
:EddyCurrent
:Cracking
Infer?
Restriction: AllValuesFrom on :measuresDamage
:Eddy
Current
Application 11
:Cracking
Case 54
:measuresDamage
22 | V-Con Modelling Issues
20 September 2016

18. B. Specific issues on upcoming QUDT version 2.0
Source:
22 | V-Con Modelling Issues
20 September 2016

19. QUDTv2.0 Initial Issues Meta nature
Since QuantityKind is ‘meta-like’ (in the sense that i.e. ‘length’ is an instance of it, another hint: qudt-defined “generalization” as meta-objectproperty) you lose some directness (of saying this object hasLength Length). Stating that a certain class has some specific property restrictions (like 1 depth) now becomes a more indirect/complex one: one quantity where quantityKind = depth). Feedback welcome. Well, dependent also on issue no 2….:
2. End-user defined quantitative properties (ie “height”)
Option1: Add to the list of Quantities (as Individual), and then having a qudt-generalization link to length)?
Option 2: as subclass of Quantity?
Option 3: separately referring to a Quantity (where Quantity is then interpreted as not being a property like height…)?
What about qualitative properties (incl. enumerations)?
3. Bug or intentional?
Quantity is currently a subclass of QuantityKind which seems not ok. (error in generation of ?)
4. Naming
QuantityDimensionVector >>> shouldn’t that be: QuantityKindDimensionVector?
5. What could be a “QUDT-light”?
6. Process
What is the timeline for qudt2.0? will it be free? (or do we all have to buy NASA handbook)
22 | V-Con Modelling Issues
20 September 2016

20. C. JSON-LD Note: JSON-LD can do more than RDF so not 1-to-1
Now often only used for SPARQL results
Note: JSON-LD can do more than RDF so not 1-to-1
JSON-LD is a concrete RDF syntax as described in [RDF11-CONCEPTS]. Hence, a JSON-LD document is both an RDF document and a JSON document and correspondingly represents an instance of an RDF data model. However, JSON-LD also extends the RDF data model to optionally allow JSON-LD to serialize Generalized RDF Datasets. The JSON-LD extensions to the RDF data model are:
In JSON-LD properties can be IRIs or blank nodes whereas in RDF properties (predicates) have to be IRIs. This means that JSON-LD serializes generalized RDF Datasets.
In JSON-LD lists are part of the data model whereas in RDF they are part of a vocabulary, namely [RDF11-SCHEMA].
RDF values are either typed literals (typed values) or language-tagged strings whereas JSON-LD also supports JSON's native data types, i.e., number, strings, and the boolean values true and false. The JSON-LD Processing Algorithms and API specification [JSON-LD-API] defines the conversion rules between JSON's native data types and RDF's counterparts to allow round-tripping.
Summarized, these differences mean that JSON-LD is capable of serializing any RDF graph or dataset and most, but not all, JSON-LD documents can be directly interpreted as RDF as described in RDF 1.1 Concepts [RDF11-CONCEPTS].
22 | V-Con Modelling Issues
20 September 2016

21. D. Linking Rule Sets approach
Role of SPIN
Role of SHACL
Relationship between the two (overlap, difference)
Ie will SHACL make SPIN obsolete or do we need both in the end?
SHACL for CWA-constraints?
SPIN for rules (or also via SHACL)?
Relationship with OWL?
Will SHACL replace OWL (“all classes becomes shapes”) or coexist?
(question not only for the rules but also for the normal modelling)
How to “organize” this, keep open world ontology AND closed worlds SHACL?
SHACL AND SPIN?
Ontology-level> how to keep clean? >
LRS can differ but keep ontologies ‘clean’ ie
“rules” (spin) versus “constraints” (shapes)
22 | V-Con Modelling Issues
20 September 2016

22. E. Importing approach Get clear when importing is REALLY needed
Preferably avoided, just referencing (?)
When needed: what is best way?
Whole existing ontologies, or
Own-defined subsets
Risk: out of sinc with original source?
22 | V-Con Modelling Issues
20 September 2016

23. F. More from Lars/Olle For David
Could we set up a common place also for DC-ANNOTATIONS and SKOS-ANNOTATIONS?
Same for GeoSPARQL
Proposal for versioning scheme for ontologies/datasets
For V-Con
Standardize use of dc annotations?
Official release of Ifc Alignment ontology?
DUL vs. ISO 15926
“Beyond owl reasoning”
Cardinality restrictions (we have small example)
E.g. “OWA issues” like cardinality == 0
Value restrictions (numerical, e.g. >=, <=, ...) (we have small example)
Property <=> Class (e.g.  IfcRelDecomposes <=> cmo:hasPart)
Expressions/functions (e.g. ?pX = f(?pY, ?pZ))
Built-in functions and operators such as +, -, *, /, AVG, SUM, MIN, MAX, SQRT, CONCAT, ... (SPARQL?)- standard versus tool-dependent
How to organize e.g. SPIN together with the LRS:s?
Also SPIN rules are “ontology level”!! Michel: and/or SHACLE?
2 times LRS for IFC to be consistent (needs more discussion)?
22 | V-Con Modelling Issues
20 September 2016

24. G. Support for less-semantic data
The VCS should support also less-semantic datasets (ie multiple ambition levels)
Unstructured data, linked documents like pdf to semantic objects (no further processing). Already covered by specification;.
Otherwise (not yet specified)
Structured linked data without schema/ontology
?Other (Semmtech: what were your exact 4 layers?)
Potentially Semmtech VCS-only
To be discussed
22 | V-Con Modelling Issues
20 September 2016

25. Thank you for your attention