W3C home > Mailing lists > Public > public-wot-ig@w3.org > March 2016

TD Template

From: Charpenay, Victor <victor.charpenay@siemens.com>
Date: Wed, 16 Mar 2016 17:08:58 +0000
To: "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Message-ID: <6E3FA85ED8C35E42B0F7DE1E44FD0C9FF9FABA@DENBGAT9EL5MSX.ww902.siemens.net>
Some of you expressed the need for a kind of template mechanism for Thing Descriptions. For instance, it should be possible to define something like a "TemperatureSensor" that must have a "Temperature" as a Property and maybe a "HighTemperature" Event.

There exists several approach to model this in RDF. First, one could define a predicate like "temperatureProperty" in a custom vocabulary:
{
  "@id": "my:temperatureProperty",
  "rdfs:range": "my:TemperatureSensor",
  "rdfs:range": "qu:Temperature"
}

and a similar predicate for the Event (say "temperatureEvent").

Then in the TD, we would have:
{
  "@type": "Thing",
  "temperatureProperty": { ... runtime data such as "href" ... }
  "temperatureEvent": { ... idem ... }
}

and with some standard RDFS reasoner + some JSON-LD processing, one could give the expected shape to the TD, namely:
{
  "@type": "TemperatureSensor",
  "properties": [
    {
      "@type": [ "Property", "qu:Temperature" ],
      ... runtime data ...
    }
  ],
  "events": [ ... idem ... ]
  ...
}

This approach requires several tools and is somewhat limited. Another approach could be to define a special predicate in the TD vocabulary that would link to "template data" (I like to call it a "specification") while runtime information is put in the TD as usual. It could look like this:
{
  "@id": "my:TemperatureSensor",
  "specification": {
      "properties": [
      {
        "@type": [ "Property", "qu:Temperature" ],
        ... runtime data ...
      }
    ],
    "events": [ ... idem ... ]
    ...
  }
}

where the specification acts as a pre-populated instance of "my:TemperatureSensor". Then, a dedicated tool or a rule reasoner could be used to merge the triples from the specification and the actual instance of the temperature sensor. specification would have the following semantics (in the form of a simple rule):
{
  ?sensor type ?t .
  ?t specification ?spec .
  ?spec ?p ?o .
}
=>
{
  ?sensor  ?p ?o .
}

This approach is more flexible but requires a dedicated tool to generate the full TD.

Other RDF approaches involve OWL modeling, but I'm not sure Web developers would be ready to dive into that to model their devices.

What do you think about that? Does one of these two approaches (dedicated properties with domain/range or specification-based) seem acceptable/relevant?

Best regards,
Victor Charpenay

Siemens AG
Corporate Technology
Research and Technology Center
CT RTC NEC ITH-DE
Otto-Hahn-Ring 6
81739 München, Deutschland
mailto:victor.charpenay@siemens.com

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Russwurm, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
Received on Wednesday, 16 March 2016 17:09:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:26:56 UTC