Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Definitions of sensor characteristics - e.g. "Sensitivity" #220

Open
oldskeptic opened this issue Mar 26, 2024 · 8 comments
Open

Definitions of sensor characteristics - e.g. "Sensitivity" #220

oldskeptic opened this issue Mar 26, 2024 · 8 comments
Assignees
Labels

Comments

@oldskeptic
Copy link
Contributor

The current definition of ssn-system:Sensitivity reads as "the quotient of the change in a result of Observations and the corresponding change in a value of an ObservableProperty being observed, under the defined conditions. As an ActuatorProperty Sensitivity is the quotient of the change in a command of Actuation and the corresponding change in a value of an ActuatableProperty".

However:

  • Example B.9 DHT22 Description makes use of sensitivity as a "Deadband" property.
  • Example B.11 IP68 Smart Sensor makes use of sensitivity as the minimum power level at which the receiving node is able to clearly receive the bits being transmitted.

Obviously, I have a similar use case for the GPS Receiver examples (#190), can we resolve this to prevent term confusion?

@oldskeptic oldskeptic added bug Something isn't working ssn example labels Mar 26, 2024
@oldskeptic oldskeptic self-assigned this Mar 26, 2024
@rob-metalinkage rob-metalinkage changed the title Definition of Sensitivity Definitions of sensor characteristics - e.g. "Sensitivity" Apr 10, 2024
@oldskeptic
Copy link
Contributor Author

Another term is also "BatteryLifetime" which was imported from ssn-system but needs more documentation.

@maximelefrancois86
Copy link
Contributor

@dr-shorthair
Copy link
Collaborator

dr-shorthair commented Apr 24, 2024

@alexrobin @oldskeptic @maximelefrancois86 @rob-metalinkage
we really need a review and critique of the whole System Capabilities section -
https://w3c.github.io/sdw-sosa-ssn/ssn/#System-capabilities

Re-factor into registers / catalogs ??

@dr-shorthair
Copy link
Collaborator

Potential overlap with W3C Devices and Sensors WG work?

@alexrobin
Copy link
Collaborator

I would really like to keep these defs, but they can be moved to a separate namespace.
The Connected Systems SWG could maintain these if it's outside the scope of the OMS SWG.

@oldskeptic
Copy link
Contributor Author

Following up to yesterday's teleconference, @rob-metalinkage was suggesting that this should be tied to external catalogs. I see the benefits of this, however very few people have published "solid" RDF/OWL2 catalogs besides QUDT; we still are at the talking stage for CRS or TimeZone RDF catalogs and it's been several years.

I'm not throwing stones but pointing out that there is limited bandwidth and it's not always clear what the 95% solution is. I'd like to document what we have while making the path to external catalogs clear.

If the incubator pages that @maximelefrancois86 dug up are the direction that Sosa was intending to take for sensor characteristics, I'd like to use them to document the terms already exist.

I am low on coffee this morning, so I will foolishly volunteer to write a side catalog / ontology / vocabulary for consumer grade batteries.

@dr-shorthair
Copy link
Collaborator

I would really like to keep these defs, but they can be moved to a separate namespace. The Connected Systems SWG could maintain these if it's outside the scope of the OMS SWG.

They are in a discrete namespace - ssn-system: - so quarantined from the main sosa: ns already. Possibly no change required except to improve the textual definitions. Thanks for the offer @oldskeptic ;-)

@dr-shorthair
Copy link
Collaborator

Maybe this issue is a sub-topic of #233 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants