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.

[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.

[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.

[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 ?