cbv-Comp values: casing and geocoordinate

[VladimirAlexiev]

component field in newest context has this enumeration:

                "x": "cbv:Comp-x",
                "y": "cbv:Comp-y",
                "z": "cbv:Comp-z",
                "axial_distance": "cbv:Comp-axial_distance",
                "azimuth": "cbv:Comp-azimuth",
                "height": "cbv:Comp-height",
                "spherical_radius": "cbv:Comp-spherical_radius",
                "polar_angle": "cbv:Comp-polar_angle",
                "elevation_angle": "cbv:Comp-elevation_angle",
                "easting": "cbv:Comp-easting",
                "northing": "cbv:Comp-northing",
                "latitude": "cbv:Comp-latitude",
                "longitude": "cbv:Comp-longitude",
                "altitude": "cbv:Comp-altitude",
                "geocoordinate": "cbv:Comp-geocoordinate"

@mgh128

1. I think we agreed, and the examples include, Capitalized versions of the above barewords. Please fix either the examples; or the JSON context and CBV.ttl. @CraigRe what does the CBV doc say?
2. I have an objection against the last bareword (where the value should be geo: URL). What we discussed, and what SensorDataExample16.jsonld shows, and what WithSensorData/README.md describes is a simpler way:

	"bizStep": "sensor_reporting",
    "readPoint": { "id": "geo:42.698334,23.319941" }

Why do you want the more complex way with geocoordinate? And what would be "type" in that case?

If you agree, please remove geocoordinate from context and from CBV.ttl.

cbv:Comp-geocoordinate  a       cbv:Comp ;
        rdfs:comment      "RFC5870-compliant geographic location URI expressed via the uriValue field"@en ;
        rdfs:isDefinedBy  cbv: ;
        rdfs:label        "geocoordinate"@en ;
        owl:sameAs        <urn:epcglobal:cbv:comp:geocoordinate> ;
        sw:term_status    "stable" .

If you disagree, let's vote and then add a bit more from README into rdfs:comment (use new lines with '"""') and into rdfs:seeAlso. Citing README:

• SensorDataExample16.jsonld: Event conveying the same coordinates using the geo: URI scheme (RFC5870), which is a much shorter way.
  • However, geo: URIs can use only two fixed CRS (see RFC5870 section 8.3 and IANA geo-uri-parameters:
    • EPSG::4326, which is WGS84 (2D)
    • EPSG::4979, which is WGS84 with altitude (3D)
  • Whereas the "long-hand" approach with component and coordinateReferenceSystem can use any EPSG or OGC coordinate system

[mgh128]

Public review draft CBV §7.8.3 shows these enumerations for component lower case as above.
Sensor data examples 10, 14, 15 also use lower-case values.

Regarding geocoordinate I think I agree that this could/should be removed because it's not being used to distinguish one component from another in the way that x, y, z or northing vs easting do. I'll therefore submit a review comment asking the group to consider removing geocoordinate from this table.
I'll submit a separate review comment asking the group to consider whether the enumerated values for component should be lower-case, all-caps or only with capitalisation of the initial letter, the latter being consistent with the approach for values of type (e.g. gs1:AbsoluteHumidity , gs1:Temperature ) currently under GMD SMG review.

[VladimirAlexiev]

@mgh128 Good!
I pulled and checked, currently ALL jsonld examples use lowercase component:

cd ../JSON-simple-context/
grep component *.jsonld */*.jsonld

So I vote to keep it lowercase.

However:

• Turtle-simple-context examples use uppercase (need to be regenerated)

WithSensorData/SensorDataExample10.ttl:   epcis:component        cbv:COMP-Z 

• Turtle-simple-context/WithFullCombinationOfFields uses epcis:component <example:x> (examples WithFullCombinationOfFields don't define prefix example: #356)
• Turtle examples use mere string (bugs caused by new JSONLD context (#275) #307 bug 12)

WithSensorData/SensorDataExample10.ttl:  epcis:component  "X"

[VladimirAlexiev]

Checked again:

• Turtle-simple-context/WithSensorData are ok
• Turtle/WithSensorData are ok
• Turtle-simple-context/WithFullCombinationOfFields and Turtle/WithFullCombinationOfFields are NOK

[VladimirAlexiev]

@dakbhavesh or @RalphTro can you fix this last bullet?
Eg https://github.com/gs1/EPCIS/blame/master/JSON-simple-context/WithFullCombinationOfFields/aggregation_event_all_possible_fields.jsonld#L98

[RalphTro]

Dear @VladimirAlexiev ,
Gladly. Done!

[VladimirAlexiev]

Hmm, the last change I see in https://github.com/gs1/EPCIS/tree/master/JSON-simple-context/WithFullCombinationOfFields is on Apr 19, 2022

• Looking at https://github.com/gs1/EPCIS/blob/master/JSON-simple-context/WithFullCombinationOfFields/convert.sh, I see these examples are made from https://github.com/gs1/EPCIS/tree/master/XML/WithFullCombinationOfFields
• So you need to edit those files, eg https://github.com/gs1/EPCIS/blob/master/XML/WithFullCombinationOfFields/aggregation_event_all_possible_fields.xml#L69 and all the others.