Open mlagally opened 4 years ago
Horticulture requirements refer to another unit standard: https://genivi.github.io/vehicle_signal_specification/rule_set/data_entry/data_unit_types/
Arch call on 3.9. Some domains have very specific units, it may not be ideal to force specific metric systems. We should adopt well known unit ontologies, it may depend on specific use cases.
Finite set of unit extensions and a standardized prefix to unambiguously identify the unit. Also require a way to specify a version and a fixed context string that can be statically parsed.
I don't agree that units should be mandatory for every property (taking the title literally) as that doesn't always make sense.
I do agree that requiring that Consumers conforming to the Core Profile support a particular ontology for units could be a good idea, since that would aid interoperability. The challenge will be in picking one.
In WebThings we use the long written form of SI units (e.g. hectopascal, percent, kelvin, ampere, micrograms per cubic metre, hertz, watt, degree celsius, volt, second).
Is ISO 80000-3 referenceable? See:
Comments before the previous one seem to suggest allowing but restricting to multiple ontologies. It is not possible to satisfy everyone, that is why the base TD spec is and will be completely open about it. Given that profile is for a subset of cases, I don't think that we should lose time trying to find something that satisfies all and pick one or not pick anything at all and be open.
Makes sense.
My further comment from https://github.com/w3c/wot-thing-description/issues/1202#issuecomment-961862277:
My ideal solution would be that by default unit values are parsed as an SI string (ISO 80000-3), but that this can be extended with semantic markup with a prefix where specialist units are needed. This maintains the idea that by default a Thing Description is plain JSON, but can be extended with semantic annotations.
This came up again in https://github.com/w3c/wot-profile/pull/195 when discussing what unit ontology to use in example Thing Descriptions in the specification.
I note that the QuantitativeValue
type at schema.org has a unitCode
member whose value is a UN/CEFACT Common Code (3 characters), which cover approximately 1,000 different units.
If we can't agree on an external ontology like QUDT or OM for units then an alternative could be a constraint that says values of unit
have to be CEFACT codes. That's probably easier to specify than the current WebThings approach of using the long form of SI units and it might be less ambiguous, but the downside is that it would always require translation into a human-readable form and 1,000 units is a lot for Consumers to translate. (See #196).
@benfrancis, @egekorkan I don't think this blocks publication of the 1.0 release, however we should revisit the ontology / metric question in scope of the 1.1 release.
Arch call on 27.8.: This is important to enable interop, need to also select a unit scheme, e.g. qudt. A unit scheme that is widely adopted is higly preferable.
OneDM took SenML units, aligning could be useful, this is simpler. OneDM intends to align with IETF, aligning is pragmatic to enhance interop across standards.
Qudt implementation could be very costly.
Proposed Spec Language: You must use SenML units if the unit exists there. You may only use an extension point if the unit does not exist in SenML. In the case of an extension the use of QUDT is (mandatory|recommended).
SenML: https://tools.ietf.org/html/rfc8428 QUDT Ontologies Overview: http://www.qudt.org/pages/QUDToverviewPage.html