Proposal: refactor the iotschema base model

[vcharpenay]

My proposal is to refactor the iotschema base model to be closer to SOSA/SSN and to minimize potential errors when annotating TD documents. The proposal is based on a 2020 paper in which I reviewed annotations from the W3C implementation report.

The main elements of my proposal are the following:

1. the vocab has 3 base classes: PhysicalObject (refinement of sosa:FeatureOfInterest), System and Property. PhysicalObjects have Properties and Systems observe and act on them.
2. the vocab gives all possible observable/actuatable Properties for any PhysicalObject. Sub-classes of PhysicalObject have more specific Property types.
3. it may be interesting to include a class Phenomenon (such as wind, or movement)
4. the vocab is designed to minimize the total number of classes
   • for example a property may be "parameterized" by another property (e.g. the target value of a homeostatic System is parameterized by some Property of a PhysicalObject)
   • similarly, a capability class may be equivalent to a parameterized System class that observes/acts on specific PhysicalObject classes

[vcharpenay]

1. overview of the base classes and their relationship (mostly derived from SOSA/SSN):

Typically, a temperature sensor does not have a temperature property; it observes the temperature of some physical object. In the TD ontology, one would still say that the sensor has an affordance to read/write a property.

[vcharpenay]

2. I suggest the following ontology design pattern, such that there's a property hasD for each possible definition C hasProperty D. For instance:

Here, because every rigid body has at dimensions (one or more length values), one would define the following property:

:hasLength
  a rdfs:Property ;
  rdfs:subPropertyOf :hasProperty ;
  domainIncludes :RigidBody ;
  rangeIncludes :Length .

Having such properties allows for a more object-oriented modeling of "Things" (physical objects and systems). That ontology design pattern was applied in SEAS, for example.

[vcharpenay]

3. sometimes, the properties observed by a sensor are not directly properties of a physical object (hence the abstract notion of "feature" of interest in SOSA/SSN). It is typically the case when a weather station measures wind strength. Wind is not a physical object.

SOSA/SSN includes an example that models a weather station as a system measuring properties of a portion, or "sample" of the atmosphere. It also includes an example for wind speed but the example doesn't state any hasProperty-relation about the observed windSpeed.

Here, a class Phenomenon might therefore help. Wikidata defines a phenomenon as an "observable fact or event". It would be better to keep iotschema simple, though, and to not introduce any notion of time in the vocab.

[vcharpenay]

4. currently, some iotschema classes are redundant with combinations of other classes. For instance, the set of classes { Temperature, Humidity TargetTemperature, TargetHumidity } could be factorized as TargetProperty forProperty { Temperature, Humidity.

Here is a possible modeling:

And here is how a TD would declare a target property:

{
  "@context": [
    "https://www.w3.org/2019/wot/td/v1",
    "https://iotschema.org"
  ],
  "id": "tag:example-thermostat",
  "@type": "Sensor",
  "properties": {
    "desired": {
      "type": "number",
      "@type": "TargetProperty",
      "isTargetOf": "_:actual"
    },
    "actual": {
      "@id": "_:actual",
      "type": "number",
      "@type": "Temperature"
    }
  }
}

[vcharpenay]

The same applies to capabilities: most capability classes could also be classes of PhysicalObject. Yet, tagging a device with the capability AmbientAir would be ambiguous: is the "Thing" a weather station (a System) or the portion of air being observed (a PhysicalObject, or more precisely a PhysicalBody)?

In contrast, in the following example, it is straightforward to infer the device's capability:

{
  "@context": [
    "https://www.w3.org/2019/wot/td/v1",
    "https://wot-schema.org"
  ],
  "id": "tag:example-sensor",
  "@type": "Sensor",
  "properties": {
    "temp": {
      "type": "number",
      "@type": "Temperature",
      "isPropertyOf": {
        "@type": "AmbiantAir"
      }
    }
  }
}

I acknowledge that it is often useful to have a list of capabilities (or Functions, as SAREF calls them) attached to some device but I suggest to focus first on properties and physical objects before looking for a solution about capabilities.

[vcharpenay]

Feedback from last webconf (June 17th):

• SetPoint would be more accurate than TargetProperty (based on how it is used in the example).
• the notion of "sample" (name from SOSA/SSN) turns out to be useful when it refers to e.g. "portion of air". Alternative names": Quantum (but a portion may not be "atomic", as the name suggests), Quantity (but the meaning would be different from the meaning of qudt:Quantity), Extent (derived from the notion of "extensive properties", but the term might be too overloaded).
• actions/events are not mentioned here but here are some ideas:
  • use a small number of classes, e.g. a a starting point: sub-classes of saref:Command that are defined for a single property value
  • include durative actions (e.g. for dimming) and periodic events, i.e. basic temporal entities.

[danicic]

I like the proposal very much. Here few comments.

Element #1. It is good. Location is missing though, but it exists in the current model. Is it meant to be a sub class of PhysicalObject, e.g., as SSN/SOSA would suggest (attached to features of interest)? E.g., in ISO 15926, Location is not PhysicalObject. Instead, they are both direct sub classes of Object. Example: room temperature could be described as Temperature (Property) of Air (TBD) at Loc1 (Location). Building Element from W3C Linked Building Data Community Group could be a sub class of Location etc. Further, there are locations that have nothing to do with PhysicalObjects.

Element #3. Sample usually suggests a measurement sample. If it is a sample of matter, then let us call it Matter or as we discussed in the last web conf: Quantum, Quantity or Substance. E.g., Wind is a wave that is a propagating dynamic disturbance (change from equilibrium) of one or more quantities. WindSpeed: Air is sub class of Quantity (Matter or Substance) and Speed is its Property.

A general comment: I like your intention to minimize the total number of classes. I see that few (standardized) models nowadays tend to get unnecessary large. They define terms and couple them together in order to define other terms. Thus, terms get larger too. So defined terms are difficult to understand by humans (hard to be discovered, even harder to be appropriately used). But even worse is the fact that such terms are not "understandable" by machines. Coupling terms together does not bring to the semantics of terms. Semantics is defined by a semantic formalism. iotschema.org to the large extend uses RDF(S) semantics. Realizing iotschema.org with RDF and RDFS we can create a model for IoT applications that is understandable by both humans and machines, and is slim and easy for use. In this regard, let us refactor the current model.

[marziman]

Hello @vcharpenay @danicic

did this refactoring happen? We would like to join and are interested to achieve IoT modeling with schema.org

[DavideRossi]

Any progress on this? iotschema seems a bit of abandonware which is a pity since SOSA/SSN (besides the original sin of being an OWL ontology) turns out to have issues aligning with WoT concepts. The idea of merging forces with WebThings project (https://github.com/iot-schema-collab/iotschema/issues/86#issuecomment-1041912971) seems very interesting too, but yet again, I see no progress there. @danicic @vcharpenay @benfrancis @marziman any hope to join forces and try to make this whole thing move forward?

[marziman]

Hello @DavideRossi we started to merge it in our own way. We are using iotschema now and we try to go with that. It would be really good if @danicic and the maintainers can say something, so we can try to proceed all together.

[vcharpenay]

Thank you for showing interest in that. We conducted a project last year that led to this issue. I still have to do the refactoring, though. I haven't got to that yet, for lack of time.

If you're willing to contribute, there's something quick that might be useful to converge: describe what you would do as a WoT Consumer with iotschema annotations. Would you use annotations for data validation? For UI generation? For automatic mash-up generation? For discovery? Etc.

From these descriptions, we can derive several things:

• what formalism to use (may a stricter meta-schema than schema.org be necessary?)
• how complex can the annotation process be (is it OK to go beyond @type tagging and include relations such as forProperty?)
• a test suite

I have my own needs but the schema would be most useful if it fits existing platforms (WebThings, OpenHAB, etc).

[DavideRossi]

Well, my domain is research so my point of view is biased. I'm interested in the ability to find things by performing semantic queries, leveraging the "semantic search" defined in the WoT Discovery draft. Basically stuff like: "find the thing that measures the temperature of that room". And use this as a basic mechanism for automatic mash-ups. Right now using SSN/SOSA, BOT and a mix of other ontologies.

[benfrancis]

Currently the WebThings platform just uses semantic annotations (currently using capabilities from the schema repository at https://webthings.io/schemas) to generate a user interface for interacting with a Thing. That UI is built using web components which implement each of the capabilities, properties, actions and events. See the screenshots below for some examples:

That does include use for validation since the generated UI validates user input against the data schema.

In the future I can imagine schemas being used for discovery, e.g. for semantic search capabilities when we implement the Directory Service API. We don't currently provide any search functionality.

Note that in addition to WebThings Gateway and the WebThings Framework there's currently work taking place on WebThings Cloud (for managing multiple buildings over the internet) and a native mobile WebThings App (for directly interacting with web things, including without a gateway). Both of these projects will also use the same set of capability schemas for generating user interfaces, and potentially for providing semantic search.

As noted in #86, WebThings schemas currently provide more in the way of constraints than those at iotschema.org, e.g. by defining mandatory properties/actions/events for certain device capabilities and being more prescriptive about things like data types, units and media content types. It would be great if any re-factoring of the iotschema.org base model could make consolidating webthings.io/schemas with iotschema.org easier, rather than harder!

[DavideRossi]

Semantic constraint are a touchy argument. I'm not even thinking of going into open-world vs closed-world arguments to avoid fideistic positions, I'd like to see pragmatism at work, at least here. In general, I would say that if you want fine-level constraints you do not need an ontology but you need a data model. Ontologies are created to promote shared understanding, data models are created to constraint the structure of data. schema.org is really in the middle of the two things: it's obviously an ontology (the focus is on shared understanding) but they say they have a "data model" (https://schema.org/docs/datamodel.html). This RDFS-based "data model", however, is not very good at addressing closed-world constraints (which is OK, shared understanding is hampered by detailed constraints). To make a long story short: forcing constraints into a schema.org ontology seems inappropriate. A solution could be that to define a schema.org IOT ontology AND a one or mode data models that are "compliant" with the ontology. In practical term this mean developing a typical RFDS-based schema.org IOT ontology and one or more SHACL datamodels. A TD that uses the ontology does not necessarily take advantage of the extended features that are reserved to the TDs that ALSO respect the data model(s). So, for example, if a TD adopting the iot.schema.org vocabulary is also valid with respect a the WebThings SHACL datamodel, then you can take advantage of extended capabilities such as dynamic UI generation. @vcharpenay you know this stuff quite well, any thought on this topic?

[benfrancis]

@DavideRossi wrote:

Semantic constraint are a touchy argument. ...

I have some comments on that, but they're getting a bit off topic for this issue so I've posted them in https://github.com/iot-schema-collab/iotschema/issues/86#issuecomment-1108558400