capture SenML units

[VladimirAlexiev]

Sensor Measurement Lists (SenML) is an important spec for sensor data.

• https://www.rfc-editor.org/rfc/rfc8428#section-12.1 is an embedded SenML Units Registry
• https://www.rfc-editor.org/rfc/rfc8798.html adds more units

The IANA Sensor Measurement Lists (SenML) ar authoritative (but the footnotes in the above two docs are more clear):

• https://www.iana.org/assignments/senml/senml.xhtml#senml-units
• https://www.iana.org/assignments/senml/senml.xhtml#secondary-units

Proposed actions:

• Add a new prop qudt:senML. Most of the time this would be the same as qudt:symbol but not always, eg

unit:BIT-PER-SEC
  qudt:symbol "b/s" ;
  qudt:ucumCode "bit/s"^^qudt:UCUMcs ;
  qudt:senML "bit/s". # ADDED

• Map SenML units to QUDT units.
  Please note that a few units will have 2 senML:

unit:FRACTION qudt:senML "/", "%".
unit:NUM qudt:senML "count", "beats".

• Decide what to do about deprecated senML units (marked with "*").
  Eg above, "/" and "count" are ok but "%" and "beats" are deprecated.
  • Some are deprecated for a good reason, eg "%" is misleading
  • Others are deprecated only because it's a derived unit, eg "gram"
  • We could append "*" in qudt:senML but that can hardly be called normalized semantic data
  • I think we should simply disregard the deprecation flag
  • Merely omitting these units is nok since RFC8428 says

Units marked with an asterisk are NOT RECOMMENDED to be produced by new implementations
but are in active use and SHOULD be implemented by consumers that can use the corresponding SenML units that are closer to the unscaled SI units.

• Create a few new units, eg

unit:V-A_Reactive-SEC
  dcterms:description "volt-ampere-reactive second (Reactive Energy)";
  qudt:senML "vars".

• Or even a few new quantityKinds, eg
  • %EL Percentage (remaining battery energy level)
  • EL seconds (remaining battery energy level)

[steveraysteveray]

This issue raises a more general one. There are many, many standards out there to address representation and interoperability in various domains. Some of them have taken the time to enumerate the units, (and quantity kinds) that are used in that domain to support their work. They do not claim to list all units - just the ones that they need.

In contrast, there are a few collections of units that aspire to list units across all domains, like UNECE, UCUM, IEC61360... For those collections, we have defined relations that point to the counterparts of our units. But for the former category, which I believe includes SenML, I'm not convinced we should be creating cross references to each of those collections. Rather, we would prefer those collections would have cross references to subsets of QUDT, possibly in the form of a Profile (which we are in the process of defining).

I'd be interested in the thoughts of others on this. I don't want to sound difficult on this, but I have worked on a number of standards committees that define/redefine their own lists of units for their purposes, at the cost of cross-domain interoperability.

[jhodgesatmb]

There is no single, universally-accepted, standard for units, perhaps because there are so many systems of units (both current and historical). ISO 80000 is adopted by several mentioned by @steve.ray qudt.org ***@***.***>. QUDT has encountered several that match what he is saying here and I agree that it would not be in the best interests of QUDT to point to every model and vocabulary. It has been suggested in previous discussions that domain-specific models and vocabularies be migrated/harmonized by their subject matter experts to QUDT, or that bridge models be created that allow those models and vocabularies to interoperate with QUDT. We have several papers and examples illustrating how to go about this task (though they may not be addressable in the QUDT website).

…

On Fri, Oct 11, 2024 at 9:12 AM steveraysteveray ***@***.***> wrote: This issue raises a more general one. There are many, many standards out there to address representation and interoperability in various domains. Some of them have taken the time to enumerate the units, (and quantity kinds) that are used in that domain to support their work. They do not claim to list all units - just the ones that they need. In contrast, there are a few collections of units that aspire to list units across all domains, like UNECE, UCUM, IEC61360... For those collections, we have defined relations that point to the counterparts of our units. But for the former category, which I believe includes SenML, I'm not convinced we should be creating cross references to each of those collections. Rather, we would prefer those collections would have cross references to subsets of QUDT, possibly in the form of a Profile (which we are in the process of defining). I'd be interested in the thoughts of others on this. I don't want to sound difficult on this, but I have worked on a number of standards committees that define/redefine their own lists of units for their purposes, at the cost of cross-domain interoperability. — Reply to this email directly, view it on GitHub <#981 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATQRWK33NNUZFZX4A5OIOLZ272FBAVCNFSM6AAAAABPUCZJIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBXG4ZDKOJQGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Jack

[VladimirAlexiev]

I only posted this because SenML seems to be widely used. Adding links to it would allow one to semantize sensor readings and map the units to QUDT.
I agree coreferencing (bridge) modules are a good idea. But I think we should make it rather than waiting for the SenML people to make it. After all the semantic community is not so large.

I'll try to make time to extract the new units and qk. @steveraysteveray , is "battery life" a valid qk?

[jhodgesatmb]

The reason I encourage model owners to build bridge ontologies is that they, like the models, must be maintained, and that is an onerous task I wouldn’t recommend. That said, I have built many bridge ontologies.Jack Hodges, Ph.D.Arbor StudiosOn Oct 12, 2024, at 11:15 AM, Vladimir Alexiev ***@***.***> wrote: I only posted this because SenML seems to be widely used. Adding links to it would allow one to semantize sensor readings and map the units to QUDT. I agree coreferencing (bridge) modules are a good idea. But I think we should make it rather than waiting for the SenML people to make it. After all the semantic community is not so large. I'll try to make time to extract the new units and qk. @steveraysteveray , is "battery life" a valid qk? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>