A Solid-based Architecture for Decentralised Interoperable Location Data

A Solid-based Architecture for
Decentralised Interoperable Location Data

Maxim Van de Wynckel and Beat Signer

Web & Information Systems Engineering Lab
Vrije Universiteit Brussel

Current Indoor Positioning Systems (IPS)

To start with some context; The common architecture of current indoor positioning systems is a separate positioning system for each building or building site. Some positioning systems might use a common framework, which could allow the use of a single application for both buildings. But for the majority of indoor positioning systems each system is an individual deployment with its own proprietary application and without the ability to share information across systems. Most positioning system have a database containing the information about users or objects tracked by that system, but users often do not know what information is kept in those databases - or even how many databases with their information exist.

Problems With Current IPSs

Users not in control of their data
No interoperability between positioning systems and applications

There are three main problems with this common architecture. Users are not always in control of their data, they do not know what positioning systems or applications are tracking them, what exactly they are storing and in the case of external tracking do not know how to stop them from being tracked. With users becoming more privacy concious, this lack of transparancy could result in users not using a certain positioning system application. In addition there is no interoperability between systems and applications that would allow the sharing of data or even allow users to use a single application for every indoor positioning systems that is available. In order for two or positioning systems to be interoperable. The data needs to be accessible by other systems. This means that the data pertaining to a certain user should be available for all positioning systems tracking this user. The data can range from raw sensor data to processed information such as their location within a building. Next, this data needs to be readable by each system that can access this data. In essence this means that there should be a common data format to store the information. Last but definitely not least, the readable data needs to be understandable by each system. Positioning systems must be able to know if the data they are reading is sensor data or something else. In what units the data is in and how they should interpret the data.

Decentralised Interoperable Architecture

Vocabularies

Core vocabularies:

SOSA
SSN

Allignment vocabularies:

GeoSPARQL
QUDT
SSN-Systems

See paper for more details ...

Properties and Observations

http://ipin2022.solidweb.org/properties/orientation.ttl

turtle
<>
    a sosa:ObservableProperty;
    rdfs:comment "Orientation of John Doe"@en;
    rdfs:label "Orientation"@en;
    ssn:isPropertyOf profile:me.
:1651065740981
    a sosa:Observation;
    sosa:hasFeatureOfInterest profile:me;
    sosa:hasResult [
            a qudt:QuantityValue;
            qudt:numericValue 108.11512756347656;
            qudt:unit unit:DEG;
        ];
    ssns:qualityOfObservation [
            a qudt:QuantityValue;
            qudt:numericValue 12;
            qudt:unit unit:DEG;
        ];
    sosa:observedProperty <>;
    sosa:resultTime "2022-04-27T13:22:20.981Z"^^xsd:dateTime;
    sosa:usedProcedure ipin:geolocationapi.

PoC Demonstrator

http://.../properties/position.ttl

turtle
:1660049553011
      a sosa:Observation;
      sosa:hasFeatureOfInterest profile:me;
      sosa:hasResult
          [
              a geosparql:Geometry;
              geosparql:asWKT
                  "POINT Z(4.3922073 50.8206522 143.29)"^^geosparql:wktLiteral;
              geosparql:coordinateDimension 3;
              geosparql:dimension 3;
              geosparql:hasSpatialAccuracy
                  [
                      a qudt:QuantityValue;
                      qudt:numericValue 29.363000869750977;
                      qudt:unit unit:M
                  ];
              geosparql:spatialDimension 3
          ];
      sosa:observedProperty <>;
      sosa:resultTime "2022-08-09T12:52:33.011Z"^^xsd:dateTime;
      sosa:usedProcedure ipin:geolocationapi.

PoC Demonstrator

http://.../properties/position.ttl

turtle
:1660049449839
  a sosa:Observation;
  sosa:hasFeatureOfInterest profile:me;
  sosa:hasResult
          [
              a geosparql:Geometry;
              ipin:inDeployment ipin:deployment_pl9_3_58;
              geosparql:asWKT
                  "POINT Z(4.3922260 50.8204372 84.49)"^^geosparql:wktLiteral;
              geosparql:coordinateDimension 3;
              geosparql:dimension 3;
              geosparql:hasSpatialAccuracy
                      [
                          a qudt:QuantityValue;
                          qudt:numericValue 3.716614723104883;
                          qudt:unit unit:M
                      ];
              geosparql:spatialDimension 3
          ];
  sosa:observedProperty <>;
  sosa:resultTime "2022-08-09T12:50:49.839Z"^^xsd:dateTime;
  sosa:usedProcedure ipin:qrscanner_checkin.

PoC Demonstrator

http://.../properties/position.ttl

turtle
:1660049553011
      a sosa:Observation;
      sosa:hasFeatureOfInterest profile:me;
      sosa:hasResult
              [
                  a geosparql:Geometry;
                  geosparql:asWKT
                      "POINT Z(4.3922073 50.8206522 143.29)"^^geosparql:wktLiteral;
                  geosparql:coordinateDimension 3;
                  geosparql:dimension 3;
                  geosparql:hasSpatialAccuracy
                          [
                              a qudt:QuantityValue;
                              qudt:numericValue 29.363000869750977;
                              qudt:unit unit:M
                          ];
                  geosparql:spatialDimension 3
              ];
      sosa:observedProperty <>;
      sosa:resultTime "2022-08-09T12:52:33.011Z"^^xsd:dateTime;
      sosa:usedProcedure ipin:geolocationapi.

PoC Demonstrator

sparql
SELECT ?posGeoJSON ?datetime ?accuracy {
    ?profile a sosa:FeatureOfInterest ;
            ssn:hasProperty ?property .
    ?observation sosa:hasResult ?result ;
                sosa:observedProperty ?property ;
                sosa:resultTime ?datetime .
    ?result geosparql:hasSpatialAccuracy ?spatialAccuracy ;
            geosparql:asWKT ?posWKT .
    BIND(geof:asGeoJSON(?posWKT) AS ?posGeoJSON)
    ?spatialAccuracy qudt:numericValue ?value ;
                    qudt:unit ?unit .
    OPTIONAL { ?unit qudt:conversionMultiplier ?multiplier }
    OPTIONAL { ?unit qudt:conversionOffset ?offset }
    BIND(COALESCE(?multiplier, 1) as ?multiplier) # Default 1
    BIND(COALESCE(?offset, 0) as ?offset) # Default 0
    BIND(((?value * ?multiplier) + ?offset) AS ?accuracy)
} ORDER BY DESC(?datetime) LIMIT 20

Conclusion and Future Work

Novel architecture for decentralising location data
- User remains in control of their data
Interoperability between systems and applications
- Handover of tracking between systems
- Single navigation application
- High-level decision fusion
Vocabulary extensible with additional semantics