Consumer grade sensor example.

[oldskeptic]

This is a first example for the use of a InkBird-IBS-TH2 as commonly available on Amazon. This example comes in two parts: the device definition and a specific device instance that is being used to distribute a beverage. I've run it into the checker a few times but I likely made a typo or two, some of the "in use" URI's won't resolve for a few days.

I am trying to create a third example of a specific device instance marked up as an ssn:Deployment, but I wanted to get the review process started.

[rob-metalinkage]

examples are explicitly fragements include in spec now - we should have a separate place for informative examples with use case descriptions

sosa: versions of predicates should be used - to see if we have ssn: usages still required.

[sgrellet]

+1 on the separation between Sensor Type VS Sensor Instance (same wording as in OMS) thanks to the 2 files content.
Highly important to document that fine line.

I feel we should rather introduce proximateFeatureOfInterest than subtyping the observable property (re: rdfs:subClassOf equipment:airRelativeHumidity)

To me 'airRelativeHumidity' is the same observable property, be it in the beer pack our outside.
It's the proximateFeatureOfInterest role to precise 'airRelativeHumidity' of what.

OTOH some may say it helps associate the property to the feature.

[avillar]

Quick note: instead of using ("minting") full URIs for the sensor instances, blank node id's could be employed (i.e., <thisBatterySensor> -> _:thisBatterySensor).

[oldskeptic]

@avillar > Quick note: instead of using ("minting") full URIs for the sensor instances, blank node id's could be employed (i.e., <thisBatterySensor> -> _:thisBatterySensor).
I'm using <SerialNumber/Sensor> to communicate instance issue directly; this is an example of an in-use sensor, so I want to avoid blank node and point to example.com instead.

[KathiSchleidt]

Then why do we have 2 mentions of thisXXXSensor in line 56 of the instance doc?

sosa:hosts <12345/BatterySensor>, <thisHumiditySensor>, <thisTemperatureSensor> ;

[oldskeptic]

@sgrellet

I feel we should rather introduce proximateFeatureOfInstance than subtyping the observable property (re: rdfs:subClassOf equipment:airRelativeHumidity)To me 'airRelativeHumidity' is the same observable property, be it in the beer pack our outside. It's the proximateFeatureOfInstance role to precise 'airRelativeHumidity' of what. OTOH some may say it helps associate the property to the feature.

I don't have a reference for aproximateFeatureOfInstance, but I've gotten myself turned around a few times, so noting things here.

Right now we have:

<airTemperatureOfProduct> rdfs:subClassOf equipment:airTemperature ;
    ssn:isPropertyOf <00001/acmePorterSixPack> .

The alternative is to use something like

equipment:airTemperature ssn:isProxyFor <00001/acmePorterSixPack> .

which means the air temperature everywhere determines the product temperature, so we're really trying to say that the air temperature in the six pack is the proxy for the temperature of the six pack, which would be?

equipment:airTemperatureInProduct ssn:isProxyFor <00001/acmePorterSixPackTemperature> .    
<00001/acmePorterSixPackTemperature> ssn:isPropertyOf <00001/acmePorterSixPack> .

which becomes messy because I'm trying to define the air temperature within the box which is the proxy for the temperature of the box, which is the proxy of the temperature of each of the beer bottles, which is the proxy for the beer within each bottles. While scientifically this is rational way to do it, it's a level of pedantic that I don't see being very popular.

Willing to change, need a better solution.

[oldskeptic]

Then why do we have 2 mentions of thisXXXSensor in line 56 of the instance doc?

sosa:hosts <12345/BatterySensor>, <thisHumiditySensor>, <thisTemperatureSensor> ;

Because the contributor is an unreliable sort. ;) Fixed.

[ldesousa]

@oldskeptic I like this example because the domain/context is straightforwards to understand, beer, temperature, batteries. However, there are some relevant issues to address:

• Properties and FoIs are at times swapped (I noted only some, needs a full review).
• Various subjects of SOSA predicates are classes instead of instances (needs full review too).
• GeoSPARQL is not used in a complete manner.
• Ontology file needs to be identified as such (InkBird-IBS-TH2.ttl).

I also suggest adding a comment referring to the ontology at the top of the graph file.

[ldesousa]

This is good. However, I would rather have each of the subjects declared above as instances of SOSA classes.

[oldskeptic]

@ldesousa Please review?

[dr-shorthair]

Yes, I also prefer the a-box data to be implemented as individuals rather than as classes.

But I guess we are in part-number vs serial-number territory here, datasheet vs deployed sensor, etc.
Not sure there is a single answer.

[dr-shorthair]

The correct name for the property is proximateFeatureOfInterest
It is in OMS - https://docs.ogc.org/as/20-082r4/20-082r4.html#_association_proximatefeatureofinterest .

In SSN the corresponding predicate is hasFeatureOfInterest.
This is the original predicate that was always intended to point to the proximate FoI - https://w3c.github.io/sdw-sosa-ssn/ssn/#OMS-Alignment-Property .

In ssn-ext we introduced hasUltimateFeatureOfInterest to cover the other usage.
This has now been added to SSN for the new edition.
By implication the original predicate covers the 'proximate' case.

[oldskeptic]

@ldesousa @sgrellet Please re-check.

[ldesousa]

Generally looks good. A few doubts on my side here and there. Let's try getting approved ahead of next meeting.

[ldesousa]

Could this be a SamplingProcedure instead?

[oldskeptic]

I am unsure what is the right thing to do here. The document is about the operating characteristics of the entire platform and reports the precision and accuracy of both sensors.

Common sense implies that the platform is "sampling" the ambient air, but this document is not about that.

Making a note of this for tomorrow's teleconference.

[dr-shorthair]

I've been taking a closer look at the InkBird example, also with the proposed addition of SystemKind in mind.
I confess I'm a bit baffled by the patterns used.

Looking at https://w3c.github.io/sdw-sosa-ssn/ssn/#overview-and-examples I would expect the general pattern to look something like this:

<ABCD> a sosa:System , sosa:Sensor , gs1:Product , equipment:Equipment ;
    gs1:pip <https://inkbird.com/products/hygrometer-ibs-th2> ;
    sosa:observes <airRelativeHumidity> ;
    system:hasSystemCapability [ 
        a system:SystemCapability ;
        system:hasSystemProperty [
            a system:MeasurementRange ;
            schema:maxValue "100"^^unit:PERCENT ;
            schema:minValue "0"^^unit:PERCENT ;
        ] ;
        system:hasSystemProperty [
            a system:Resolution ;
            schema:value "2"^^unit:PERCENT ;
        ] ;

    ] ;
    system:hasSurvivalRange [
        a system:SurvivalRange ;
        system:hasSurvivalProperty <EFGH> ;
    ] ;
    system:hasOperatingRange [
        a system:OperatingRange ;
        system:hasOperatingProperty <IJKL> ;
    ] ;
.

I've used blank-nodes so that the pattern is clear, but these could be spilled out into named nodes of course.

It is true that a content model for the classes carrying the actual values is not provided, so for system:MeasurementRange I have followed @oldskeptic and used schema:maxValue and schema:minValue etc
And I like the use of gs1:pip to link to an external spec sheet, though I think it could be dcterms:source or even dcterms:isFormatOf.

Else this could be formulated as <ABCD> a system:SystemKind . in which case this RDF document is the specsheet (though a dcterms:source link to an external source is still warranted of course).

But in the current examples @oldskeptic seems to have weaved a complex web that does not actually leverage the System Capabilities module in the way it was designed.

Or am I missing something @alexrobin @kjano ?

[oldskeptic]

@dr-shorthair I based most of this on the 'DHT22 Description' example. I think we need to document a little better how these patterns are supposed to work. Wrt to #220 and today's teleconference we may need to revisit or properly label some of this.

And I like the use of gs1:pip to link to an external spec sheet, though I think it could be dcterms:source or even dcterms:isFormatOf.

gs1:pip is the commercial "glossy" description that attaches to gs1:Product and/or schema:Product. The specsheet is technical in nature and I'd like to attach it to the sensor themselves.

[dr-shorthair]

@dr-shorthair I based most of this on the 'DHT22 Description' example. I think we need to document a little better how these patterns are supposed to work.

I've had a go at simplifying DHT22 a bit - see https://github.com/w3c/sdw-sosa-ssn/blob/complete-examples/ssn/rdf/examples/dht22.ttl

Could this be a better template for InkBird-IB-TH2 ?

[oldskeptic]

This PR on hold until we resolve a few other issues.

[oldskeptic]

This PR is going to be broken up into smaller ones for simplicity.