Device Ontology

[amedranogil]

This issue is to discuss improvements to the device ontology.

• use comments to propose individual improvements
• use "reactions" to vote on each improvement :+1: for +1; :-1: for -1
• use citations to discuss particular improvements.

[amedranogil]

Heater concept is repeated in HVAC ontology. Should it be maped in HVAC or removed from Device?

[amedranogil]

Add grouped device concept. In KNX as well as many other protocols there are virtual devices that actualy control a collection of devices (e.g: there are 2 LightControllers which can be controlloed independently, there is a third LightController which is also a group device that controlls both lights simultaneously, using a single command in the protocol)

[amedranogil]

Add automated door concept, same as windows. Also define a new enumeration (Open, Close, NoCondition) for better semantics for these devices

[amedranogil]

Define MeasureSensor which give measurements (with value and unit from the measurement Ontology). Temperature, Humidity and Atmospheric pressure sensors should be subclass of this.

[Alfiva]

If I remember correctly, there was a need to fix some hierarchy issues wtih devices. Right now when you query a device form CHE with SPARQL, the inferencer says it is of every type of device there is. I think I looked into this some time ago and it was because of a bad definition of classes in DeviceOntology, but I'd need to go thoruhg it again. What I mean is, let's take this chance fix this too.

[amedranogil]

Check duplicities and coordination with Ativity hub ontology.

[cstockloew]

It's not only the ActivityHub ont; there are other onts as well. X73, personalhealthdevice, ContinuaHealthManager, health.measurement

[amedranogil]

X73, personalhealthdevice, ContinuaHealthManager, health.measurement

I think the overlap in these ontologies have to do with other kind of devices, maybe it is more productive to set another issue for health devices ontologies.

[amedranogil]

We used to have water ontology. Now I have fluid (water) valves and pumps which are controlable but the nearest semantical model is a "switch".

EDIT: there is WaterFlowController -> wich may as well be both pumps and valves. Sooo disregard...

[saiedt]

Add grouped device concept. In KNX as well as many other protocols there are virtual devices that actualy control a collection of devices (e.g: there are 2 LightControllers which can be controlloed independently, there is a third LightController which is also a group device that controlls both lights simultaneously, using a single command in the protocol)

There is always a reason for grouping. If you look closer into it, you see that grouping is usually done based on common features, e.g. same location, same type, same color, same size, etc. (same, or a range of, or ...).

In an ontological approach, grouping is done either dynamically in terms of a query (can be a class expression, usually putting certain restrictions on certain properties) or "persistently" by defining new (sub)classes in an ontology (again using class expressions). --> For the dynamic grouping by query, you may leave it to the clients build their queries without necessarily extending the ontology; but, if you think that yu have to simplify a frequent query, then you may extend the ontology by adding new classes.

In KNX, there is no concept for

1. classes (you are always at the level of instances) --> they have to build groups as a concrete set, in terms of an enumeration, which is anyhow possible also in the ontological world;

2. queries, except for query by ID (this may not be precise enough though, because a sort of "query by example" should also be possible, if I'm not wrong) --> you support a set of predefined queries by creating the query results first and assigning them an ID.

[cstockloew]

In KNX, there is no concept for classes (you are always at the level of instances)

I think you are confusing this with something else. KNX does have groups (or classes). The destination is either a physical or group address (a bit in the DLR byte determines whether the adress is a physical or group adress). Example: physical: 1.1.1, group: 1/1/1 (dot vs. slash). For a single message sent to a group adress, multiple devices can react on that message.

But: KNX (just as example) separates the adressing from the message content, meaning that you can send any message (command) to any adress. You can send a dimming request to a washing machine (or whatever). So: how would this look like in uaal, where concrete devices have specific properties. What properties would the grouped device concept have?

There is a similarity between this discussion and the discussion we had on situation ont (and/or reasoning rules). The group adress would somehow combine multiple devices, whereas a situation would be a representation of a group of multiple triples (and a rule would be multiple class expressions without necessarily having concrete values for rdf:object). I wonder if this can somehow be considered together...

[cstockloew]

There is a problem with the property hasValue: in the super class (ValueDevice) it is defined as ObjectProperty, but some sub classes re-define it as DatatypeProperty. This is not possible. A property is either ObjectProperty or DatatypeProperty, it cannot be changed in sub classes.

[saiedt]

I think you are confusing this with something else. KNX does have groups (or classes).

Yes, groups of instances (enumerations) are indeed also classes; so are groups of groups and groups of combinations of groups and instances. But, this kind of support for classes is certainly far from the ontological full support for classes. That's what I wanted to point out. I mean, this item defines something as a requirement, that seems to be a no-op. But, maybe there is something else that Alejandro is missing and not just the ability of building groups that is already given in a much more powerful way.

[cstockloew]

building groups that is already given in a much more powerful way.

OK, I understand.

So, to define a grouped device, like a central light switch that represents the 2 light source light1 and light2, the OWL-way would be:

:CentralLight a owl:Class ;
        owl:equivalentClass  [ a owl:Class ;
                               owl:oneOf  ( :Light1 :Light2 )
                             ] .
:Light1 a :LightSource;
:Light2 a :LightSource;

This would then either (1) be defined as a new ontology, so that it can be used in a ServiceRequest, or (2) it would be given directly as request.

Which means that the ontology-definition, matchmaking, and/or request must be extended to support this, but not device ont.

Correct?

[Alfiva]

@cstockloew about hasValue: yes, this is part of the long overdue review of the ont.device to fix these things, including some weird hierarchies. But if I wanted to do seomthing like that, how would it be properly done (if at all)? I mean, defining that a Device has a hasValue property, but let subclasses specify what kind of value it is.

[saiedt]

|:CentralLight a owl:Class ; |

|owl:equivalentClass [ a owl:Class ; owl:oneOf ( :Light1 :Light2 ) ] .|

Also definable in this way:

:CentralLight a owl:Class ; owl:oneOf ( :Light1 :Light2 ) .

But maybe the purpose of this enumeration is to say 'all lights in the whole home' or 'all lights in the living room'. If so, then it is safer to avoid using enumerations because they are rigid and cannot reflect future changes.

This would then either (1) be defined as a new ontology, so that it can be used in a ServiceRequest, or (2) it would be given directly as request.

The light ontology may readily support some of the frequently used patterns, but always there may be also need for deployment-specific ontology extensions to facilitate deployment-specific use cases.

Which means that the ontology-definition, matchmaking, and/or request must be extended to support this, but not device ont.

I do not understand the need for extending the matchmaking though, but yes (see the "deployment-specific" items mentioned above.

[cstockloew]

about hasValue: if I wanted to do seomthing like that, how would it be properly done (if at all)?

Without saying that we should actually do it that way, I think the correct way in OWL would be to define two different properties, e.g. hasDataValue and hasObjectValue. Maybe with some more meaningful names, like hasLevel (for an integer) and hasStatus (for an enumerated value). But I did not yet have a look at all classes to see if it fits. Maybe it's also possible to split ValueDevice into two classes (LevelDevice and StatusDevice).

Generally, the sub classes cannot change the type, they can only restrict the property further. I see that some classes define hasValue as float and some as integer. Thus, in the super class, the property can only be defined as DatatypeProperty, but without restrictions; at least no type restriction, but you can define cardinality restrictions.

[cstockloew]

they are rigid and cannot reflect future changes. right, but if you define this in a separate ontology that is deployment-specific, then you can easily work with it. If there is a change (which probably does not happen very often), then you can unregister the ont and register a changed one.

I do not understand the need for extending the matchmaking though

Let's go with your definition: |:CentralLight a owl:Class ; owl:oneOf ( :Light1 :Light2 ) .|

How would I define a service request to turn off all lights (= turn off the CentralLight)? If the server only understands to turn off a specific lamp?

[Alfiva]

Maybe it's also possible to split ValueDevice into two classes (LevelDevice and StatusDevice).

I personally lean more towards this, but we'll see...

[amedranogil]

building groups that is already given in a much more powerful way.

I understand the semantical powers you reffer to, but the problem has to do with a limitation on the device protocol. The exporter can send the same command to many devices but if we use the semantical aggregation in the end this means that the exporter has to send a single command for each member of the group, and these commands cannot be send in paralell (many mediums of domotic devices do not allow this, and in case of my experience with the KNX installation in the Smart House Living Lab in Madrid, KNX does not behave well when you burst commands to it). De problem is not a matter of how to address the devices, the end result is (or should) the same using the group address or the semantical aggregation. What is different is the process (or experience) it is not the same that all lights repond in unison to the same command (using group address, aka multicast), than when one by one they react independently to the command (what will happen if relying on non-grouped device). One could argue the exporter should interpret the request and use the correct group address; yet all the other members of the group will still be matched. In any case the group concept is for suplying both philosophies; and to provide some support for the internal representation of the organization of resources of the exporter. In any case the group concept is not meant to be a solution for querying, but as the semantical description of the organization of devices.

[amedranogil]

about hasValue: if I wanted to do seomthing like that, how would it be properly done (if at all)?

how about subproperties? Also Eugenio has complained about the hasValue property not being semantical enough (I'll ask him to explain here).

Actually subproperties whould allow to define logical devices that are subclasses of multiple device types and still be able to report/control each part of it independently. eg: a regulated light might be sub class of DimmerController and LightController

[amedranogil]

Maybe it's also possible to split ValueDevice into two classes (LevelDevice and StatusDevice).

Remember there are other types of ValueDevice, essentially many of the Sensors, maybe Sensor should be on a different hierarchy, actually then there would be 2 properties: "hasStatusValue" (for sensor) and "setStatus" (for actuators). Actually for Actuators we should look into the different verbs that devices can perform ( on, off, open, close, set absolute value in percent, set relative value in -+percent, ...).

about hasValue: if I wanted to do seomthing like that, how would it be properly done (if at all)?

A thought I just had: maybe there is a middle layer of abstract classes in the hierarchy to define the different properties with their property types.

[cstockloew]

about hasValue: if I wanted to do seomthing like that, how would it be properly done (if at all)?

how about subproperties?

Same problem: the subproperty must be of the same type than the super property (either ObjectProperty or DatatypeProperty). I'm afraid we have to go with two props.

[amedranogil]

about hasValue: if I wanted to do seomthing like that, how would it be properly done (if at all)?

how about subproperties?

Same problem: the subproperty must be of the same type than the super property (either ObjectProperty or DatatypeProperty). I'm afraid we have to go with two props.

how about this (Only an Idea), make an ObjectProperty only, this way sensor can restrict to measurement or enumeration types; for actuators we will have to define a new class similar to mearurement but conceptually different (imposing a status insead of measuring it); then this class can actually accomodate some of the needed semantics such as absolute or relative addressing (is the integer referring to a percentage, and does this perdentage refer to the absolute setting or the variation in the change). Although now that I think about it, it does not make sense to be able to have a context event with the value as a relative change, or does it? I would certainly preffer to have always absolute status as "the current status of the device"; but that might just be a personal preference.

[Alfiva]

it does not make sense to be able to have a context event with the value as a relative change

IMHO, no, it doesn't, like it wouldn't make sense to have verb-things like "open" "light up", etc... which should become deducible from the change of status. This is the old dichotomy between status-based and operation-based context awareness. Sorry for the terms, I know there are more scientifically accurate ones, but I think it's easy to understand. I'm more on the status-based side.

[cstockloew]

This is the old dichotomy between status-based and operation-based context awareness. ... I'm more on the status-based side.

fully agreed. However, there could (additionally) be a mapping for, e.g., a speech handler because many spoken commands are like this ("open the window" instead of "make the window open"). But this may be a different discussion..

how about this (Only an Idea), make an ObjectProperty only, this way sensor can restrict to measurement or enumeration types

This is possible, although it would complicate many things. For example, LightSource--hasBrightness-->Integer would become something like LightSource--hasStatus-->LevelStatus--hasPercentage-->Integer.

I would say: the information, that hasBrightness is a percentage value, is already provided by the definition in the ont (it's an integer 0<=x<=100).

There is also a (currently abandoned) class called "Conversion" in org.universAAL.middleware.service.owls.process which AFAIK was meant to convert the values provided by a Callee to the format that the caller requires. From my understanding, the ont should be clearly defined, including the range of values. The caller should always provide the data in that format (or in that unit) - even if the caller would somehow get (or measure) the raw value in a different unit, and even if the requester actually wants the value in a different unit. The ont is the interface. If the ont defines the value to be in meter, and the caller AND the callee provide/request the value in milimeter, then the value is still transferred in meter (with a conversion on both sides) because that's the interface definition (the ont).

[cstockloew]

One could argue the exporter should interpret the request and use the correct group address; yet all the other members of the group will still be matched.

But a group adress would then only be used if the request contains exactly the members of the group. Thus, no device is adressed if it was not part of the request.

There is, however, a different aspect that needs to be considered: the context bus. If you send a command to a group adress, then the change for each element somehow has to be published to the context bus. Let's assume that you have a subscriber that has subscribed for a specific device (light1) and you have a request for a group adress (g1={light1, light2}). Then, the server must also send one (or more) appropriate events. You can only send an event for a group (g1) if the group is somehow ontologically modelled so that the bus can make the correct match (the bus knows: g1={light1, light2} and light1 elementOf {light1, light2}).

[amedranogil]

There is, however, a different aspect that needs to be considered: the context bus.

in deed, this was the other reason to propose the group, no for the context bus to reason it, but for the exporter it self (or a reasoner) to manage it, so if it has to publish a g1, then it iterates and also publishes light1 and light2 changes. BC that is also maintaining the correct state (in Che) for the members of the group this is necesary.

[cstockloew]

Add grouped device concept

hmm, it's either getting more clear or I'm getting more confused (not sure, yet).

Saied is right by saying

There is always a reason for grouping

It doesn't make much sense to have a group of devices when then command to sent to this group is not understood by all of the devices. There is still the open question:

What properties would the grouped device concept have?

I guess, the answer would be: the group represents a set of LightActuators, or a set of WindowActuator, or a set of any other kind of Actuator (is there a reason to have a group of sensors? it's only actuators, isn't it?). Thus, it appears as one of these concrete actuators and this actuator has certain properties.

Thus, the group itself is also an individual, even if it represents a group of devices. Agreed?

Normally, the low-level protocols like KNX don't use URIs, so there must naturally be a mapping from KNX-adressing to URIs. It can be done internally with no direct relation, but it can also be part of the URI, e.g.: light1 with physical adress 1.1.1 we have urn:light1:11.1 light2 with physical adress 1.1.2 we have urn:light2:11.2 g1 with group adress 5/5/1 we have urn:g1:5/5/1

If we assume all of the above, then the group would appear as a normal device. It can be retrieved by getting all lights: getControlledLights would return {light1, light2, g1}.

To find out if a device represents a group of devices, we could use the location. A single device has s specific location, like kitchen, but a group normally has a bigger location, like the appartment. However, this information might be too cumbersome, or not concrete enough. Another way would be to add the proposed class GroupedDevice and make the type of the group individual (g1) to both, GroupedDevice and the Actuator class, e.g.: g1 a LightActuator, GroupedDevice;

Another way would be to avoid GroupedDevice and use (as Saied pointed out)

the ability of building groups that is already given in a much more powerful way

Let's go back to:

|:CentralLight a owl:Class ; owl:oneOf ( :Light1 :Light2 ) .|

Although the definition is correct in terms of OWL, it creates a class called CentralLight whereas it actually should create an individual.

We can re-write this for the example above: g1 a LightActuator, [a owl:Class ; owl:oneOf ( :Light1 :Light2 ) ];

But at this point, I'm stuck in an endless owl-logic-loop. Because this does not say "g1 represents the class with the elements light1 and light2". Instead, it says "g1 is an element of the class that consists of light1 and light2", which effectively means that g1 is either light1 or g1 is light2 (but not both).

At this point, I need help for the ontological modelling.

[amedranogil]

Add grouped device concept

My current solution is like @cstockloew states: the group is an idividual of class the same as the grouped devices (or in general terms the minimum comon denominator class), and of the class GroupDevice; where GroupDevice class defines a property "groupsDevices". Also at some point I had a property, belongsToGroup for Devices to state their groups (but I did not use it). Semantically it makes sense to me, since the Grouped device is a logical device (both low level and semantically), it has a location (the common denominator location of all of its sub devices), and represents the organization of devices in the deployment. It also helps when receiving service requests. The only problem is that I have an ontology with a single class "GroupDevice" which may as well be part of the device intology, hence the proposal.

[amedranogil]

It sould be specified that device ontology is not for all devices, but for devices in the smart home environment

[amedranogil]

PanicButtonSensor should be subclass of ButtonSensor. See Amazon Dash as an example of non-PanicBuntton Button.

[cstockloew]

It sould be specified that device ontology is not for all devices

That's why the class Device is in PhWorld ont and not in device ont. There are also other onts that use Device without the device ont. How should the specification look like, javadoc?

[amedranogil]

It sould be specified that device ontology is not for all devices That's why the class Device is in PhWorld ont and not in device ont. There are also other onts that use Device without the device ont. How should the specification look like, javadoc?

maybe a rename of code and URI, to something like ont.device.home (so we can have ont.device.health, and ont.device.HVAC, ...)

[amedranogil]

SSN: Making universAAL cores already standard ontologies will be very benefitial. Although some of it overlaps with other ontologies (such as Measurement).

in fact it is not that difficoult, we could start by using SOSA which is already very similar to the upper device ontology; but we complement with our device types.

[amedranogil]

look into SAREF too