CBV "component" lookup list

[VladimirAlexiev]

@mgh128 wrote: Section 7.3.7.1.2 of the current draft EPCIS 2.0 standard specifies the structure of a SensorReport, for the expression of relevant business-relevant sensor data accompanying an event.

Although some of the measurement types (e.g. temperature, relative humidity) are scalar values with no particular direction, others such as force, pressure, velocity, acceleration are vector quantities, having magnitude and direction.

To support the expression of vector quantities, SensorReport includes a field/property/attribute called 'component', which currently expects a free-text string to express a component of a vector value. For example, in Cartesian coordinates, as currently defined, the field named 'component' might often have string values such as "x", "y", "z".

In addition to Cartesian coordinate systems based on (x,y,z) cordinates, there are also cylindrical polar systems and spherical polar systems.

On last Tuesday's EPCIS/CBV 2.0 call, there was some discussion about whether we could avoid the ambiguity and inconsistency of a free-form text string by instead defining an additional CBV code list for populating the value of the 'component' field.

I took an action item to draft such a code list. So far I have prepared an explanatory diagram (attached) to illustrate Cartesian coordinates, cylindrical polar coordinates and spherical polar coordinates.

Based on this, if we decide to use a code list, I think we could define the following code values initially:

x y z azimuth rho (the cylindrical / axial radius from the Z axis in cylindrical polar coordinates) r (the radius from the origin in spherical polar coordinates) polar_angle (measured downwards from the Z axis) elevation_angle (measured upwards from the XY plane)

Additionally, we might also include from the outset:

latitude_WGS84 longitude_WGS84 elevation_WGS84

I leave it to the group to decide whether we should define a code list for populating the 'component' field.

Whether we do or not, I would advise against using values such as "theta" and "phi" to represent azimuth and polar angle (or vice versa), since mathematicians and physicists use conflicting conventions for what these Greek symbols correspond to.

If any of you can think of other potentially useful values for such a code list for 'component', please suggest them on the next call (today/tomorrow) or via this mailing list - or to me directly.

Please note that 'component' is to be used solely to distinguish between the coordinates of a vector measurement.

Please do not confuse this with a separate proposed field, 'feature', which is to be used only to specify at a semantic level which physical object or location is being sensed, since this might not be obvious from the value of the deviceID alone (at least not without retrieval of additional details / metadata about where / to what that sensor device is located/attached).

There could be scenarios in which we might want to use both 'component' (for a vector quantity such as acceleration) and a 'feature' to indicate whether the accelerometer (or other sensor producing a vector measurement) is attached to the product / logistic unit or to its container / transportation vehicle.

[VladimirAlexiev]

1. If we use words for some of the spherical and cylindrical coordinates, maybe we should use words for all of them? I looked in Wikipedia and here's what I find (first is a preferred name, and then in parentheses an alternative name)

   • https://en.wikipedia.org/wiki/Cylindrical_coordinate_system
   • axialDistance (radialDistance)
   • azimuth (azimuthalAngle)
   • axialCoordinate (height)
   • https://en.wikipedia.org/wiki/Spherical_coordinate_system
   • sphericalRadius (radialDistance)
   • azimuth (azimuthalAngle)
   • inclination (polarAngle) a. Compared to Mark's proposal, there's only one angle and the word "polarAngle" has a different meaning. b. Is it common to use both directions (from the Z axis and from the equatorial plane) for this angle?    Then I think we can adopt "inclination" (from Wikipedia) and "polarAngle" (from Mark's figure)

2. On the other hand, (x,y,z) are so prevalent for Cartesian coordinates, that we should stick to these single letters.

3. How should we spell them? I think we used UpperCamelCase for MT, so I'd suggest the same for components?  (Also, it's a common convention to use UpperCamelCase for ontology Individuals, which these are):  Eg X, Y, Z, Azimuth, AxialDistance, SphericalRadius

4. How will they look as URLs?  cbv:COMP-X, cbv:COMP-Y, cbv:COMP-Z, cbv:COMP-Azimuth, cbv:COMP-AxialDistance, cbv:COMP-SphericalRadius

5. How to spell them in JSON?

[mgh128]

Hi @VladimirAlexiev

You're correct that within a cylindrical coordinate system, there is only one angle, the azimuth or azimuthal angle, as shown in my diagram. However, within a spherical coordinate system, there are always two angles to specify, the azimuthal angle and either the polar angle, typically measured downwards from the positive Z axis or the elevation angle, typically measured upwards (in the positive Z direction) from the XY plane, both intersecting the origin.

Not sure what you mean by your remark that polarAngle has a different meaning. I'm fairly sure that my third diagram is consistent with what is shown in the diagrams and captions in https://en.wikipedia.org/wiki/Spherical_coordinate_system, though I'm happy to make improvements to the diagrams if something is ambiguous or can be improved or if we prefer Inclination to PolarAngle - but we need to be able to specify one of these (whatever we call it) if we're going to support spherical polar coordinates.

Elevation angle is less frequently used in maths and physics but is analogous to latitude, if we consider the Earth's equator to be the reference plane / XY plane, the positive Z axis to pass through the geographic North pole and the positive X axis to pass through the Greeenwich meridian. Longitude is analogous to an azimuthal angle.

Wikipedia correctly states that polar angle and inclination angle are synonyms "The polar angle may be called colatitude, zenith angle, normal angle, or inclination angle."

I have no objection whatsoever to us using axialDistance or axialRadius instead of rho for cylindrical coordinates and to using sphericalRadius instead of r for spherical coordinates - though these are more verbose for the algebraic relations I also included with the figures, but if we decide to retain that algebra (which is intended to be helpful), we can always write sphericalRedius (denoted in the algebra below as r) / axialDistance (denoted in the algebra below as rho).

I almost agree with your proposal 4, although it is missing a code value for cbv:COMP-Inclination OR cbv:COMP-PolarAngle. (the group should pick one and we'll adjust the diagram accordingly)

Not sure I understand your question 5. Aren't they just CURIEs treated by JSON-only users/applications as strings, e.g. "cbv:COMP-X", "cbv:COMP-SphericalRadius" . They would always be in quotation marks, so the hyphenation should not be problematic - it's not as though we'd use those values within an object-oriented dot notation.

[VladimirAlexiev]

Not sure what you mean by your remark that polarAngle has a different meaning

You are right: "The inclination (or polar angle) is the angle between the zenith direction and the line segment OP"

5: I mean #265

6: If we include Latitude, Longitude (in decimal degrees), maybe we should also include easting, northing (in meters, often used by UK Ordnance Survey)?

[mgh128]

Need a code list for populating component with values including:

cbv:COMP-X, cbv:COMP-Y, cbv:COMP-Z, cbv:COMP-Azimuth, cbv:COMP-AxialDistance, cbv:COMP-SphericalRadius, cbv:COMP-PolarAngle (or Inclination)

Latitude, Longitude, Elevation, Easting, Northing

Also need to consider how to handle a sensor that reports a geoURI - which value should we then use for type (MeasurementType) where the sensor only emits a URI value? or hexBinary? or boolean? or stringValue? Do we need gs1:MT-OTHER ? for these ( URI value or hexBinary or boolean or stringValue )

[VladimirAlexiev]

@mgh128 we don't need "Other" because a missing type says the same. But need to have constraint "type is required if one of the double value fields are present "

[mgh128]

We'll populate a new CBV code list for component with values for

cbv:COMP-X, cbv:COMP-Y, cbv:COMP-Z, cbv:COMP-Azimuth, cbv:COMP-AxialDistance, cbv:COMP-SphericalRadius, cbv:COMP-PolarAngle

cbv:COMP-Latitude, cbv:COMP-Longitude, cbv:COMP-Elevation, cbv:COMP-Easting, cbv:COMP-Northing

cbv:COMP-GeoCoordinates

If a sensor outputs a geoURI, it SHALL express this via uriValue and with component set to cbv:COMP-GeoCoordinates.

[mgh128]

At least one of type or exception must be populated in each SensorReport (is this only if value is populated?) If exception is not applicable, then type should be populated with in order of descending preference:

value from gs1:MeasurementType codelist value from QUDT quantity kind custom value (xsd:anyURI) ideally with an online definition

[CraigRe]

Vlad: quantitykind:DimensionlessRatio a qudt:QuantityKind ; qudt:applicableUnit unit:DeciB_M ; qudt:applicableUnit unit:GR ; qudt:applicableUnit unit:MACH ; qudt:applicableUnit unit:PERCENT ; qudt:applicableUnit unit:PPB ; qudt:applicableUnit unit:PPM ; qudt:applicableUnit unit:PPTH ; qudt:applicableUnit unit:PPTR ;

quantitykind:Dimensionless qudt:applicableUnit unit:BYTE ; qudt:applicableUnit unit:DECADE ; qudt:applicableUnit unit:GigaBYTE ; qudt:applicableUnit unit:KiloBYTE ; qudt:applicableUnit unit:KiloBYTE-PER-SEC ; qudt:applicableUnit unit:MegaBYTE ; qudt:applicableUnit unit:MegaBYTE_Memory ; qudt:applicableUnit unit:NP ; qudt:applicableUnit unit:NUM ; qudt:applicableUnit unit:OCT ; qudt:applicableUnit unit:PebiBYTE ; qudt:applicableUnit unit:PetaBYTE ; qudt:applicableUnit unit:TeraBYTE ; qudt:applicableUnit unit:UNITLESS ;

quantitykind:AreaRatio skos:broader quantitykind:DimensionlessRatio ;

quantitykind:AtomicNumber skos:broader quantitykind:Dimensionless ;

quantitykind:RefractiveIndex qudt:applicableUnit unit:UNITLESS

quantitykind:RefractiveIndex qudt:applicableUnit unit:UNITLESS

[VladimirAlexiev]

Dimensionless quantities are a universe of their own. We need Dimensionless at least for:

• "count" as Mark mentioned
• "percentage", for a real-world example "battery status" (MT-RelativeHumidity has its own type, though it's also percentage)

They are very broadly represented in Rec20. In the Rec20 excel, search for "count" or "percentage", check "Within: Workbook" and click "Find All". You'll find a bewildering plethora, and a lot of the units speak of ex:feature (eg count of rail cars, count of locomotives, count of cigarette master boxes...).

I'm not sure how would one structure type and feature to allow using all of these Rec20 units.