Clarification on the use of the "Thing" entity

[doublebyte1]

We have been integrating STA 1.1 in a project and some questions came up about how to adapt the STA model to the use case.

The project consists in a series of neuroscience experiments. which involve a human walking with a backpack packed with sensors. The concepts of datastreams, observations and sensors seem pretty straightforward, but what should be represented as a Thing has been raising some internal discussions.

• Should the Thing be the backpack equipped with sensors? It is important to state that the thing does not stay immutable all the time. It can be updated with more or less sensors, and it can have a different human carrying it each time.
• Would it make sense to consider a Thing as a particular configuration of sensors and human? In that case, we would have multiple things.
• Instead of assigning the Thing to a physical object, would it make sense to assign it to a experiment/run, instead? In reality this a bit similar to the previous option, but we could have a more defined time-space window to link to the experiment.

We were wondering if anyone else has experienced similar use cases, and what the best approach would be to represent our use case in the STA data model. Thanks in advance!

[doublebyte1]

@glopesdev @PascalLike feel free to add your thoughts to the discussion.

[liangsteve]

This answer is for v1.1., as you are using v1.1. V2.0 might be more strict or more clear. Depends on your view.

When we design the model, our view is that what's a THING depends on your perspective. If your perspective is from a IoT device management, your THING naturally is your IoT device. And your FeatureOfInterest might be the different persons who wear the IoT devices.

But if you are managing an experiment with different test subjects (persons), it might be more natural to have a PERSON as a THING. As for your experiment, you care about the DATASTREAMS of that test subject. The IoT devices are means (Procedures) to get the observations for the Datastreams of that Thing (person).

Here is something even better. We use it all the time. Look at SensorThings as a pipeline of different Datastreams. Why don't you have two or three different SensorThings, and link them together as a data pipeline? You maintains different perspectives in this case. It's common for large operations, you have different persona needing different perspectives. THING means different THING for them. Hope this help.

[humaidkidwai]

To build on top off what @liangsteve answered, think of what do you want to measure or rather what is of interest to you in your use case?

Is the backpack of sensors a means for you to measure various parameters of the human carrying it?
In this case, I would model the Thing as the Person carrying the backpack. The FeatureOfInterest in this case can be the individual human features you intend to characterize. Additionally, if you want to answer questions such as what happened to the subject and where did it happen, you should allow FeatureOfInterest to track the location (see #33). (This could be a potentially important question you might be seeking to answer if you are modelling the Person as the central component of your application). Sensors may be added/removed, thus mutability should not be a concern at this point.
To summarize, your STA instance will be producing a bunch of Datastreams that describe FeaturesOfInterest (of the person who is the test subject) by deploying Sensors that produce Observations by measuring the relevant ObservedProperties

Is the human carrying the backpack a means for you to measure various features of interest in the vicinity of the human carrying it?
This may be the case if the person carrying the backpack is just a platform for you to mount your Sensors and the person(s) carrying it is of little to no interest to you.
As Steve put it, when your goal is to establish the IoT device (backpack in your case) as the central component of your application and you intend to observe Feature(s)OfInterest around the IoT device, your backpack becomes your Thing. Hence, you will end up with Datastreams of Features around the backpack of sensors that may be of interest to you.

[hylkevds]

Thank you for this really interesting use-case description.

I don't have much to add to what Steve and Humaid added above regarding the version 1.1 modeling. I would probably choose the experiment/run as Thing, since that probably makes the data easiest to process afterwards.

Looking forward to Version 2.0, this "what is my thing" issue is one of the main issues we've been trying to solve (or at least improve on). I think this would be a great example in the spec for V2.

• In v1.x only the Thing has time series (Datastreams), but in V2 a Datastream can be attached to both a Thing and a Feature. This means the backpack could be the thing, while the human is a Feature. If the backpack is put on by a different human, new datastreams can be created for this new run, attached to the same Thing, but the new human.
• The deployment concept allows tracking which sensor is attached to which Thing. so if a sensor is added to or removed
  from a thing, this configuration change can be tracked.

Of course this doesn't help you right now, but it should make things quite a bit better in the future.

[PascalLike]

Thank you all for your response and valuable suggestions!

Our current orientation is to consider a Thing as the experiment/run because it seems the one that best lends itself to the organization of experiments.
Even if our use case is based on an unusual mix of health sensors and environmental sensors and used in separate experiments, it shows how versatile STA can be for wearable devices domain, such as modern smartwatches. With future developments, it seems that it will be even possible to produce shared wearable devices, much to the delight of hardware manufacturers :)