Wot-thing-description: Modeling relations among InteractionAffordances

[fennibay]

Within a Thing, Interactions may have certain relationships among themselves, such as:

• One Property may represent the quality/reliability/stability/etc. of another Property.
• Some properties could be configuration properties for another Interaction

Introducing a relationship such as td:hasRelatedInteractionAffordance among interactions in the information model would allow modeling such relationships.

This would be useful for:

• Retrofitting TDs to existing devices, as the device may just provide different endpoints for these aspects, and we cannot cover this within the forms of a single interaction
• Keeping the data models of the interactions simple by not having to extend the data model with such additional properties. Only some consumers will be interested in these additional properties so the other consumers can just focus on the process values if they are kept in a separate interaction

TD is not domain-specific so it cannot define the specific relationship, as for instance reliability (#1002) may mean different things in different domains. But it could define this generic relationship, and domain-specific ontologies could subclass this property with rdfs:subPropertyOf.

[vcharpenay]

Describing the relationship between properties should preferably be done with SSN/SOSA. SSN/SOSA even has a module for such properties on properties. Here is an example.

{
  "@context": [
    "... TD context ...",
    {
      "ssn": "http://www.w3.org/ns/ssn/",
      "ssn-system": "http://www.w3.org/ns/ssn/systems/"
    }
  ],
  "ssn-system:hasSystemCapability": {
    "ssn:forProperty": { "@id": "_:measure" },
    "ssn-system:hasSystemProperty": { "@id": "_:quality" }
  },
  "properties": {
    "measure": {
      "@id": "_:measure",
      "type": "number"
    },
    "quality": {
      "@id": "quality",
      "@type": "ssn-system:Accuracy",
      "type": "number"
    }
  }
}

The Thing declares a 'system capability' which applies to measure and has accuracy quality.

Note that in the general case, measure and accuracy are not exactly properties of the system but property _affordances_. Sometimes, it is important to distinguish between the two, e.g. when an affordance applies to more than one physical property. Consider for instance a weather station whose affordance measure returns temperature, humidity and pressure all at once.

A paper on the TD ontology we've published last year gives a few pointer on aligning TD with SSN (see competency questions and figure 2).