MeasurementType vs QuantityKind; "feature"

[VladimirAlexiev]

Related to #246; draft at https://milecastle.media/dev2021/voc_epcis_extras/MeasurementType

In the weekly telco yesterday, the group decided to mirror ~71 QUDT QuantityKinds (out of ~850) into a GS1 namespace, therefore:

• reusing the QUDT work,
• while providing GS1 control over the stability of those URLs and associated data.

1) @mgh128 showed a comparison of the two lists: could you please provide a link? 2) Could you also list the discrepancies or omissions here, to facilitate discussion? (and posting to the QUDT github project) 3) I disagree with the following MeasurementTypes:

• altitude: that's just length (similarly, we don't have height, width, depth, thickness etc)
  • and we have speed but not speed of ascent or speed of descent
• latitude, longitude: that's just angle 4) Following the line of thinking of 3, I think that sensorReport has a major omission: type says what's the quantity kind, but not what has been measured. Eg:
• How would you express width vs depth? length is defined thus "The linear magnitude of any thing, as measured end to end. Length, width, depth, height, diameter are all measured in units of length."
• How would you express humidity of atmosphere vs humidity of a food sample?
• How would you express mass of product (net) vs mass of packaging (tare) vs mass of both (gross)? Packaging might be tracked as a separate EPC (eg GIAI, GRAI) but I think that often it's not. 5) SSN/SOSA have a prop featureOfInterest to describe this.
• One can use it either for a generic entity (eg "atmosphere" or "product") or a specific entity (eg "room 101" or "outside air conditioner 102")
• AFAIK there's not an extensive lookup list of such features, so I think we'd have to use URLs for it. 6) A small matter of terminology: given 3 and 4 I think that "MeasurementType" is ambiguous, and I propose we use "QuantityKind" after QUDT.

In summary, I propose to change sensorReport as follows:

"@context": ["https://gs1.github.io/EPCIS/epcis-context.jsonld",{"ex": "http://ns.example.com/epcis/feature/"}],
...
"sensorReport" : [
  {"kind": "gs1:QC-Temperature", "feature": "ex:atmosphere", "value": 26.0,  "uom": "CEL"},
  {"kind": "gs1:QC-Temperature", "feature": "ex:product",    "value": 27.0,  "uom": "CEL"},
  {"kind": "gs1:QC-Humidity",    "feature": "ex:atmosphere", "value": 12.1 , "uom": "A93"},
  {"kind": "gs1:QC-Humidity",    "feature": "ex:product",    "value": 15.0 , "uom": "A93"},
  {"kind": "gs1:QC-Mass",        "feature": "ex:packaging",  "value":  1.0,  "uom": "KGM"},
  {"kind": "gs1:QC-Mass",        "feature": "ex:product",    "value": 25.0,  "uom": "KGM"},
  {"kind": "gs1:QC-Mass",        "feature": "ex:total",      "value": 26.0,  "uom": "KGM"}]

• change "type" to "kind": because epcis:type is already overloaded with cbv:SDT vs cbv:BTT
• change "gs1:MT" to "gs1:QC"
• allow a single-optional field "feature" of "@type":"@id"
• postulate that two sensorReports in the same event at the same "time" cannot have the same combination of "kind" and "feature"

cc @mgh128 @CraigRe @shalikasingh @RalphTro. Please add here other colleagues who commented on these issues.

[mgh128]

The documents I showed yesterday are at https://docs.google.com/document/d/1a5v1dtAiQRgHXQ_lUTSrv7JACLuzwFsODSyps0mnBX0/edit?usp=sharing and https://docs.google.com/spreadsheets/d/19lseUd1kHiz48VNtrHXy6kafLTlNzS1GsaYiBqdT4UA/edit?usp=sharing

I highlighted the discrepancies in yellow in the first document on pages 3-6

The main issues were:

• Our 'Dimensionless_concentration' needs to be split into two, QUDT's MassRatio and VolumeFraction
• Our 'Molar_concentration' needs to be split into two, QUDT's AmountOfSubstancePerUnitVolume and MolalityOfSolute
• QUDT appears to be using the same quantity kind (DoseEquivalent) for both millisievert and millisievert per hour, whereas we used separate measurement types 'Effective_dose' and 'Effective_dose_rate'.
• QUDT does include a quantity kind for Altitude but not for Latitude / Longitude, so it seems inconsistent. ( I agree that we could use Angle and use the component field to express which angle is the Latitude and which is the Longitude ) As a point of principle, I don't think the same measurement type / quantity kind should be used for two properties or unit that do not have the same dimensionality.
• QUDT uses quantitykind:InformationEntropy for unit:BYTE but uses quantitykind:Dimensionless for unit:KiloBYTE
• For volumetric flux, QUDT has unit:MilliL-PER-M2-DAY but does not specify a corresponding quantity kind (no triple asserted for qudt:hasQuantityKind). In terms of dimensionality, it looks like a speed or velocity, but it's a volumetric flow rate, a volume flowing through a cross-sectional area per unit time.
• We plan to adjust the draft for gs1:MeasurementType to align with QUDT nomenclature, e.g. changing Magnetic_vector_potential to MagneticVectorPotential and changing Charge to ElectricCharge etc.

Regarding your bullet point 3, I agree that we can use component to express which angle, which length the measurement corresponds to. As discussed yesterday, I'm not sure whether we can enumerate everything we'll need into a code list or whether we allow free text.

Regarding your bullet point 4, I think it is important to distinguish between which component (latitude, longitude, length, width, depth, height, x, y, z, r, theta, phi) versus which object (the product, the atmosphere, the container for the product, etc.), so there is probably a case for supporting component for the former and your proposed feature for the latter.

I have no strong objections to us renaming the proposed class from gs1:MeasurementType to gs1:QuantityKind , especially if we're aligning with / mirroring a subset of the QUDT Quantity Kind values. However, I don't understand why you propose gs1:QC-Temperature rather than gs1:QK-Temperature etc.

I disagree with your final bullet point. You appear to be overlooking the component field. As noted above, I think there is a use for type (or kind if the group prefers; I agree with your reasoning not to further overload type), component and feature, so I'd rewrite your final bullet point as:

• two sensorReports in the same event that share the same value of time SHALL NOT have the same combination of kind, feature and component.

[VladimirAlexiev]

Altitude vs Latitude, Longitude

https://github.com/qudt/qudt-public-repo/issues/379

Effective_dose_rate (DoseEquivalentRate)

It's missing: posted https://github.com/qudt/qudt-public-repo/issues/380. I don't see DoseEquivalent used for "mill-Sievert-per-hour", where do you see that?

I don't think the same measurement type / quantity kind should be used for two properties or unit that do not have the same dimensionality

Completely agree. I also commented in https://github.com/qudt/qudt-public-repo/issues/379 that related quantity kinds should also have the same dimensionality (except "abstract" quantity kinds like Density that has concrete realizations MassDensity vs VolumeDensity with different dimensionality).

quantitykind:InformationEntropy for unit:BYTE but uses quantitykind:Dimensionless for unit:KiloBYTE

https://github.com/qudt/qudt-public-repo/issues/381

volumetric flux, QUDT has unit:MilliL-PER-M2-DAY

https://github.com/qudt/qudt-public-repo/issues/383. I cannot find unit:MilliL-PER-M2-DAY in QUDT 2.1, can you cite the definition of that unit in the posted issue?

gs1:QC-Temperature rather than gs1:QK-Temperature

Lapsus lingua

changing Charge to ElectricCharge

Great!

You appear to be overlooking the component field.

You are right! And I'm not sure we need two of them. Can you give some examples where both would be needed? I'm ok to call it component or feauture, as soon as we give realistic examples of using this (or these) field(s).

[mgh128]

Sorry - I meant: unit:MicroSV-PER-HR qudt:hasQuantityKind quantitykind:DoseEquivalent . even though unit:MicroSV qudt:hasQuantityKind quantitykind:DoseEquivalent . That's the problem.

Within https://raw.githubusercontent.com/qudt/qudt-public-repo/master/vocab/unit/VOCAB_QUDT-UNITS-ALL-v2.1.ttl I found at lines 15057-15065

unit:MilliL-PER-M2-DAY a qudt:Unit ; dcterms:description "Unavailable"@en ; qudt:conversionMultiplier 0.0000000000115740740740741 ; qudt:hasDimensionVector qkdv:A0E0L1I0M0H0T-1D0 ; qudt:ucumCode "mL.m-2.d-1"^^qudt:UCUMcs ; rdfs:isDefinedBy http://qudt.org/2.1/vocab/unit ; rdfs:label "Millilitres per square metre per day"@en ; .

Thinking about scenarios where we might want to use feature and component, might we need them if feature is packaged product vs unpackaged product and component is length / height / depth / width

Having said that, the GS1 Web vocabulary already has the following dedicate properties:

https://www.gs1.org/voc/inPackageDepth https://www.gs1.org/voc/inPackageDiameter https://www.gs1.org/voc/inPackageHeight https://www.gs1.org/voc/inPackageWidth

https://www.gs1.org/voc/outOfPackageDepth https://www.gs1.org/voc/outOfPackageDiameter https://www.gs1.org/voc/outOfPackageHeight https://www.gs1.org/voc/outOfPackageWidth

I will try to make the adjustments/alignments to the draft preview at https://milecastle.media/dev2021/voc_epcis_extras/MeasurementType this week. Thanks for posting the QUDT issues.

[VladimirAlexiev]

feature is packaged product vs unpackaged product component is length / height / depth / width

This is one good way of breaking them up. I think we'll need a bigger complement of features, eg "product, packaging, packaged product"; "indoors, outdoors", etc.

gs1.org/voc/inPackageDepth gs1.org/voc/inPackageDiameter gs1.org/voc/inPackageHeight gs1.org/voc/inPackageWidth gs1.org/voc/outOfPackageDepth gs1.org/voc/outOfPackageDiameter gs1.org/voc/outOfPackageHeight gs1.org/voc/outOfPackageWidth

I think they took the wrong turn, because where does this combinatorial explosion end? schema.org has a tiny complement of concrete features, and a generic PropertyValue node where you can combine several attributes to achieve more combinations.

---

I've been thinking about the namespace. Instead of:

@prefix gs1: <https://gs1.org/voc/>.
gs1:QK-Length

It's slightly better to use

@prefix gs1_qk: <https://gs1.org/voc/quantitykind/>.
gs1_qk:Length

because:

• namespace guidelines discuss "slash vs hash" and say "use hash for small collections of things (eg small ontologies), but use slash for big collections of things.
• you could define @prefix gs1_qk: <https://gs1.org/voc/QK-> but nobody recommends dash as last namespace char
• specs like Linked Data Platform treat the slash as you would in a file system: delineating folders and files.
• clearly gs1_qk: holds very different things from gs1: so they should be two different namespaces
• the namespace is proper prefix of each term URL, so you can say nicely

  gs1_qk: a owl:Ontology.
  gs1_qk:Length a :QuantityKind; rdfs:isDefinedBy gs1_qk: .

• your local name remains pure ("Length") rather than ugly ("QK-Length")

BTW, which spelling do you like better visually: gs1_qk:, gs1-qk:, or gs1qk: ?

[VladimirAlexiev]

We need more examples (realistic!) and clearer definitions when to use component and when to use feature.

@RalphTro @CraigRe @jmcanterafonseca-iota @shalikasingh Please comment.

[RalphTro]

Hi @VladimirAlexiev and @mgh128 ,

so, to sum up, there are two major suggestions on the table: (a) rename type to kind in sensorReport (b) rename "gs1:MT" to "gs1:QK" (c) introduce new (optional) property feature in sensorReport

As to (a) and (b) given the time pressure we are facing : is this in your opinion a must or nice-to-have? :-)

As to c) I remember a discussion many, many months ago where the group discussed the richness/the extent of context data that should be embedded in EPCIS events (whose primary purpose is business-relevant visibility events). E.g., for some companies, it may be interesting where/how the sensor is attached, in which distance, etc. etc. Back then, we agreed that IF users want to convey/point to such data, they could do so by referring to a file accessible via the `deviceMetadata' field. The deviceMetadata specification could leverage the W3C SSN Ontology. We considered a specification of such files out of scope of the work of this group though. So, I am not saying that this suggestion does not make sense. The decisive question is where to draw the line as there are potentially many more attributes (see https://www.w3.org/TR/vocab-ssn/) we could take into consideration! When we closed the discussion on the set of data attributes, we considered the existing set of properties a balanced trade-off.

If the group sees a need to re-open this discussion though: Is there already a code list available we could recommend users to populate the feature field? I noticed that Vladimir sees an issue as to how existing GS1 Web vocabulary properties (e.g. https://www.gs1.org/voc/inPackageDepth) were defined.

[mgh128]

My view is that (a) and (b) are not essential. (a) would allow a more precise definition since type is already overloaded to express event type, business transaction type, source destination type. If the group decides to rename (a) and (b) it should literally be a 5 minute search-and-replace action affecting any prototype files using any text editor or SDK that is capable of multi-file search and replace.

Regarding (c), from the examples Vladimir has provided so far, feature refers to what is being measured, e.g. the product, its packaging, the container. I think this has value, because these might not be in equilibrium, e.g. not in thermal equilibrium. It's just as important to be precise about which object/location is being monitored as precision in the measurement value. In contrast, our examples for component are to support vector values, such as those that might be obtained from an accelerometer for a shock sensor. Combining these, if there were a need to distinguish between the x,y,z components of accelerometer readings on the product versus its container, then we would need both component and feature.

Can we think of other realistic examples (mainly for vector measurements) that need feature and component ?

Regarding https://www.gs1.org/voc/inPackageDepth I don't expect to see those terms being redefined, even if they are semantically inelegant, since they're already in use. Yes, we could reformulate these to have a single property to express linear measure, expecting a class that indicates a component and a feature. To me, that feels clunky. Even the GDSN data model doesn't do that, even though it takes a more cumbersome approach for expressing telephone numbers etc., while the GS1 Web vocabulary takes a simpler approach of separate properties.

[mgh128]

@VladimirAlexiev - not sure if you have taken a look at https://www.gs1.org/voc/AllergenTypeCode regarding uses of hash, slash or hyphen. Plenty of large code lists already in the GS1 Web vocabulary.

Do we seriously want a separate CURIE prefix for each one of them?

Isn't it actually easier for developers if we avoid an explosion of CURIE prefixes for large code lists? If so, then the guidance on a preference for slash over hash would appear to only encourage such an explosion of CURIE prefixes - or did those who wrote the guidance not consider this consequence?

[VladimirAlexiev]

Resolved about "feature": let's give some examples using "ex:feature", and once we have industry uptake and some agreed code lists, maybe EPCIS 2.1 can adopt it as an epcis:feature:

• the examples about temperature, pressure and mass above
• a rail example about measuring different kinds of Voltage in the engine
• a rail example about measuring brake pressure of 1000 wheels

Resolved about "QK": "quantitative" is a bit limiting since we also have categorial (qualitative) measurements, namely stringValue, uriValue, booleanValue. So "MT" stays.

Resolved about "kind": we'll keep "type" in JSON but translate it to epcis:measurementType in RDF.

[RalphTro]

Dear @VladimirAlexiev , This is just to let you know that I, following your suggestion, added a first illustrative example to explain the usage of the component property as part of a sensorReport taking the example of velocity. I also included a user extension for the feature property we discussed in this week's call (where we decided to not consider it a standard field until there is a well-established code list we can point users to). Is this in line with what you have in mind?

Here is the file: https://github.com/gs1/EPCIS/blob/master/JSON/WithSensorData/SensorDataExample10.jsonld

Feel free to adjust it as you see fit and let me know - happy to adjust the corresponding/equivalent XML file afterwards.

[VladimirAlexiev]

@RalphTro

• Pls shorten the prefix to "ex"
• "example:feature": "example:velocity" is not good because "gs1:MT-Speed" already says that. We need to find an example of two things traveling at different speeds, and I can't think of a realistic example.
  • We can give the examples shown above (atmosphere/product temperature, and product/packaging/total mass)
• I can't edit examples directly, have to submit a PR, because I'm not a member of the "gs1" github org. Given that @mgh128 has been very late in approving MRs (25 days!), I'd appreciate if you give me such rights

[mgh128]

@VladimirAlexiev (Cc: @RalphTro @CraigRe @AHearnGS1 )

Like most members of the EPCIS/CBV 2.0 work group you appear as a contributor and we welcome your contributions, most of which are very helpful and intended to make the standard more robust and more credible.

You appear to be asking why you have not been given direct Write access to the repository.

Looking at https://github.com/gs1/EPCIS/settings/access you see that @CraigRe and @mgh128 are Admins, while @RalphTro , @joelvogt , @domguinard and @dannyhaak have direct write access because they are core team editors for the chapters on sensor data, REST / Open API interface, JSON/JSON-LD and validation.

Even though I am listed as an Admin, I do not have the authority to make unilateral decisions about who else should have direct write access without first checking with Greg Rowe and Andrew Hearn @AHearnGS1 .

Then you complain that I have been very late in approving MRs (membership requests) and quote 25 days, even though until 27 calendar days ago, you have not signed GS1 IP policy or opted into the work group.

I could also point out that several other members of the work group (including @shalikasingh @dakbhavesh and others) have been active contributors over a much longer period and I do not remember any of them complaining about not having direct write access.

If you have a problem with any of this, discuss it directly with @AHearnGS1 because:

1. I don't have the authority to unilaterally grant your direct write access without his approval
2. I have already spent plenty of time reviewing and responding to your numerous issues, including time that Craig and I have both spent on 1:1 calls with you to try to prioritise the concerns you have raised and try to keep the discussions on calls focused and at a level to which most members of the group can engage in constructive discussion, even though only a few of us in the group are giving much consideration to semantic interpretation as Linked Data.
3. I don't tolerate any kind of unfair criticism

Have a good weekend

[RalphTro]

@VladimirAlexiev: As to your suggestion, I propose the following: (a) I can add another JSON-LD example to explain the usage of a 'feature' property leveraging "ex:atmosphere" and "ex:product" (b) For the time being, leave the new example as-is, but remove the feature property here. Based on this we would at least have one example in which the usage of 'component' is illustrated. In this regard - I checked the group's Business Requirements Analysis Document (BRAD) and I did not find any use case pointing in this direction, so, as for now, I also am not in a position to think of a more realistic example.

Hope that I have some bandwidth to work on this next Tuesday. Kind regards, Ralph

[mgh128]

@RalphTro , @VladimirAlexiev - I have now updated the example to use the shorter CURIE prefix, ex:

[RalphTro]

Thanks, @mgh128 !

@VladimirAlexiev: replaced the feature value with a more realistic value (now: product to make clear that velocity was measured at product level), see https://github.com/gs1/EPCIS/blob/master/JSON/WithSensorData/SensorDataExample10.jsonld, and added another jsonld example with temperature-related with two sensor reports - one measured at product packaging level, the other reflecting atmospheric temperature (used the word ambiance instead of atmosphere for that), see https://github.com/gs1/EPCIS/blob/master/JSON/WithSensorData/SensorDataExample13.jsonld. How do you like this?

[VladimirAlexiev]

@RalphTro I like them; I'll add another for mass of product/package/total. Need to be updated in view of #265, eg

"type": "Speed", "value": 4.5, "component": "X"

which will get RDFized as

epcis:measurementType cbv:MT-Speed; epcis:value "4.5"^^xsd:double; epcis:component cbv:COMP-X

[RalphTro]

Great, @VladimirAlexiev! Happy to update the prefixes once #265 is closed/there is final consensus in our group.

As to the data type of value ("^^xsd:decimal") - I think that should be "double", shouldn't it?

[mgh128]

Yes, I think we agreed to replace all xsd:decimal and xsd:float with xsd:double

[VladimirAlexiev]

added SensorDataExample12.jsonld: Uses custom prop ex:feature to report 3 mass readings of a SGTIN: tare (ex:packaging), net (ex:product), gross (ex:total)

@RalphTro Who can we ask to make a couple rail examples about ex:feature:

• a rail example about measuring different kinds of Voltage in the engine
• a rail example about measuring brake pressure of several different wheels

[RalphTro]

Thanks, @VladimirAlexiev ! Turning to your question: I think simplified, semi-realistic examples to explain the functional principle are absolutely sufficient for our cause: in this regard, note that the first release of the EPCIS standard only contained TWO simple message examples, for just one event type. :-) So, the message samples that come with the EPCIS Implementation Guide PLUS what we have on GitHub is already getting far ahead of what is expected from this group. That said, @beceecc and @CraigRe were involved in EPCIS-related development activities in rail and may be interested in discussing/jointly developing some simple examples (potentially with subject matter experts from industry) as this might speed up things in future initiatives/projects. From a timing perspective, this could happen after motioning the two standards to PCR. I think that this discussion can take place outside our ordinary EPCIS calls, glad to support this. @beceecc + @CraigRe : feel free to chime in if sounds appealing to you.

[VladimirAlexiev]

Ok, assign to @CraigRe and @beceecc and they can resolve, or add Rail examples then resolve. Cheers!

[beceecc]

The solution outline I am aware of uses a different approach than the ex:feature property. The type of measurement - e.g. inside temperature, outside temperature, axle temperature... - is linked to the sensor ID via master data. If the existing examples for ex:feature are not sufficient we could of course transform this to be included in the sensorReading itself via ex:feature. This would not reflect the real world approach though. Please let me know whether we need it, then I would contact some domain experts to provide me with meaningful types of voltage measurements.

[RalphTro]

Dear @beceecc , Thanks a lot for your explanation. If the respective accessing clients have access to the sensor master data, I think this solution approach is fine, too (it seems to work in practice anyway already :-)). In light of this, my take is the following: If it does not really help you/the end users you are in contact with, I think we do not need to spend time for developing these examples. If the rail sector submits a corresponding work request to develop a guideline for sharing sensor data through EPCIS, we can revisit this discussion and identify the most appropriate solution approach for indicating a feature property.

@VladimirAlexiev: from my POV, all things in this issue seem to be addressed. If the example on https://github.com/gs1/EPCIS/blob/master/JSON/WithSensorData/SensorDataExample13.jsonld is fine for you, I will add the corresponding XML equivalent and we can close this issue.

[VladimirAlexiev]

@beceecc So you mean that deviceID determines what is being measured?

@RalphTro Close this