Extending Two-Level Modeling for IoT Decision-Making

1. Extending Two-level Information Modeling to the Internet • of Things Paul Stacey School of Informatics & Engineering TU Dublin – Blanchardstown Campus Damon Berry School of Electrical and Electronic Engineering TU Dublin – City Campus

2. TU Dublin Technological University Dublin • Blanchardstown • Business • Humanities • Engineering • Informatics TU Dublin Campuses • City Centre • Sciences • Business • Engineering • Music • Food • Media • Art • Languages • Maths • Law • Computers • Tourism • Hospitality • Social Care City Centre Blanchardstown Tallaght • Tallaght • Business • Humanities • Engineering • Informatics • Science

3. Background • Project Motivation The ingredients to GOOD Decision Making DATA is the seed to high quality INFORMATION

4. Background • Interoperability standards Open Data

5. Background • Two-Level Modeling • Traditional information systems design tightly-couples informationandknowledge concepts • In complex domains knowledge is constantly evolving • Solution: Separate Information & Knowledge Reference Model (Object Oriented) Systems Use Operational Templates Archetypes

6. Two-Level Modeling • Two Level Modelling Consists of three artefacts to provide an unambiguous definition of data structures

7. Adopting a Two-Level Modeling • Approach Develop a generalised identity model for the domain. Develop functioning binding to relevant terminologies. Adopt, adapt or develop a suitable reference model. Develop two-level information communication and processing for resource constrained devices. Form a suitable community of supporters. Develop consensus-based domain archetypes.

8. 3. Reference Model Adopt, Adapt or Develop Reference models should only capture the stable concepts within a domain, at the principles level within a multi-level ontological space Adapted from Beale (2002)

9. Adapt: Ref. Model (O&M) • Ref. Model (O&M) Observations & Measurements (O&M) ISO/DIS 19156 Extensibility Mechanism?

10. Adapt: Ref. Model (O&M) “Application of O&M within a technical community requires that the community agree on standard content for the key slots in the model, as well as on required extensions to the base classes provided within the standard. In particular it is necessary to have standard vocabularies” INSPIRE D2.9 (INSPIRE 2013)

11. Recursive Aggregation • Ref. Model (O&M) A portion of the EN 13606 Reference Model. Compound/element patterns are highlighted in green

12. Recursive Aggregation • Ref. Model (O&M) • Composition • - Compositions represent storage concepts • Section • - Sections represent organisation concepts • Entry • - Entries represent content concepts

13. Ref. Model (O&M) • Ref. Model (O&M) Augmented O&M model Stacey P. & Berry D. (2018)

14. archetype (adl_version=1.4) TPOT-OM-Geo_Data_Element.Weekly_Buoy_Data.v1 concept [at0000] language original_language = <[ISO_639-1::en-ie]> description original_author = < ["date"] = <"20160218"> ["email"] = <"paul.stacey@itb.ie"> ["name"] = <"Paul Stacey"> ["organisation"] = <"TPOT"> > lifecycle_state = <"Draft"> > definition Geo_Data_Element[at0000] occurrences matches {1..1} matches { -- Weekly_Buoy_Data archetype_id existence matches {0..1} matches {*} geoDataElement existence matches {0..1} cardinality matches {0..*; unordered; unique} matches { OBSERVATION_SET[at0001] occurrences matches {0..*} matches { -- OBSERVATION_SET observation existence matches {1..1} cardinality matches {1..*; unordered; unique} matches { OBSERVATION[at0003] occurrences matches {0..*} matches { -- SST_Obs featureofinterest existence matches {1..1} matches { [ac0001] } } } ontology terminologies_available = <...> term_definitions = < ["en-ie"] = < items = < ["at0000"] = < text = <"Weekly_Buoy_Data"> description = <"Weekly_Buoy_Data"> • Archetypes While reference models are typically developed by computer scientists, archetypes are developed by domain practitioners using a community consensus approach Constraint Statements or Archetype (Extract)

15. Archetypes • Two level models and archetypes go beyond the idea of “recording measurement”. • Community-standardised documentation, designed by consensus of the members

16. Constraining the RM • Ref. Model (O&M)

17. SensorThings API SensorThings API • Two main parts: Sensing & Tasking • RESTful based standard, enables CRUD (similar to OGC’s Sensor Observations Service) • Sensing part defines a data model, based on ISO/OGC O&M

18. SensorThings API Data Model SensorThings API

19. SensorThings API Data Model & • Two Level Modeling Define in Reference Model or Archetype Model??

20. Concept Mapping Results

21. SensorThings API Archetype Model

22. Scenario of Use • Re-usability • Archetypes and Templates are made available to system developers and domain experts to facilitate their specialization and reuse.

23. Scenario of Use • Building Applications

24. Scenario of Use • Building Applications

25. Scenario of Use • Building Applications

26. Scenario of Use • Building Applications • Constrained Knowledge Kernel

27. Scenario of Use • Query Engine • The use of a common Reference Model & Archetypes enables better semantic interoperability between systems. However, a method to query the information is essential. • Systems that use archetypes may also use the Archetype Query Language (AQL). • AQL is a declarative language, it is applied to both the reference model and the archetype model. • AQL queries are expressed based on semantics defined within the archetype level.

28. Scenario of Use • Query Engine (AQL) • An AQL query statement may be scoped within a particular record/geo-data-document or all documents based on a particular archetype. • A Class expression is used within a FROM clause to achieve scoping. • Here an AQL query snippet is used to discover all ocean observing platforms observing within a certain region in the north sea. SELECT c/…/wmo_platform_code FROM GDR [include specific scoping here]contains GeoData_COMPOSITION c [TPOT-OM-GeoData_COMPOSITION.platform.oceanobserving.v1 contains OM-Observation_Set […] contains OM_Observationobs [TPOT-OM-OM_Observation.oceansitesObs.v1] WHERE obs/data[at0001]/details_COMPOUND[at0002]../items[at004]/value = “hourly”

29. Scenario of Use • Query Engine (AQL/SPARQL) • In this work archetypes are represented using OWL. • Archetype/OWL governed documents are captured as knowledge graphs. • Apache Jena is used to manage the linked data based observational data instances. • Apache Jena includes Fueski which provides SPARQL endpoints. • Fueski allows the data to be queried using a semantic search approach. PREFIX sea_region: <http://digitalmist.ie/optaasdev/archetypes/tPOT-REGION.sea_region.v1.owl#> SELECT DISTINCT ?sea_region WHERE { ?sea_region sea_region:at0000.1_..... “north_sea” } ORDER BY ?sea_region

30. Scenario of Use • Conclusion • This study has shown that two level modeling can be extended to the IoT domain. • Two-level modelling allows for a rigorous definition of information objects within IoT systems. • Once mapped, modeled and published, these artefacts can enable a two-level modeling community of supporters to develop and grow within the IoT domain. • Communities can agree on further specialization of the SensorThings API archetype model for individual IoT use cases • Enhanced enhance interoperability and query-ability is based on the three : reference model, archetypes and ontological bindings.

31. Thank • You CONTACT: paul.stacey@itb.ie Damon Berry School of Electrical and Electronic Engineering TU Dublin – City Campus Paul Stacey School of Informatics & Engineering TU Dublin – Blanchardstown Campus