Support for isA for sensor data

[domguinard]

Hi,

As we are progressing with our implementation we noticed that the SensorDataExample1.jsonld has a isA property but this does not seem to be allowed according to the JSON schema:

"sensorElement": {
			"type": "object",
			"properties": {
				"sensorMetadata": {
					"$ref": "#/definitions/sensorMetadata"
				},
				"sensorReport": {
					"$ref": "#/definitions/sensorReportList"
				}
			},
			"required": ["sensorReport"]

Is this an omission or an error in the example?

Happy to correct and submit a PR once answered.

[mgh128]

Hi Dom,

Testing with https://www.jsonschemavalidator.net/ , https://github.com/gs1/EPCIS/edit/master/JSON/WithSensorData/SensorDataExample1.jsonld appears to validate against https://github.com/gs1/EPCIS/edit/master/JSON/EPCIS-JSON-Schema.json

probably because in SHACL and JSON Schema we're taking an 'open shape' approach to validation, so it doesn't throw a validation error if something additional / unexpected is present.

Of course we could declare the "isA" or "type" aliases of @type within the "properties" of sensorElement (within the JSON Schema) and maybe we should?

isA / type (as an alias of JSON-LD @type) is primarily needed to declare the class of the data object in JSON-LD.

For event types, such as ObjectEvent, AggregationEvent etc., we absolutely must do this because an eventList can contain a mix of these event types and there's otherwise no straightforward way of determining which event type we're dealing with, especially as an AssociationEvent is structurally very similar to an AggregationEvent.

For SensorMetadata, SensorReport and possibly SensorElement we probably don't need to do that because we can make use of the rdfs:range of related properties to infer that the value of sensorMetadata property is always a SensorMetadata object etc.

Looking at https://github.com/gs1/EPCIS/edit/master/JSON/WithSensorData/SensorDataExample1.jsonld I'm wondering whether we can actually eliminate the declarations "isA":"epcis:SensorElement" .
Looking at https://github.com/gs1/EPCIS/blob/master/Ontology/EPCIS-SHACL.ttl , there is no occurrence of
sh:targetClass epcis:SensorElement ; even though there are occurrences of sh:targetClass epcis:SensorMetadata ; and sh:targetClass epcis:SensorReport ; (even though our sensor examples such as https://github.com/gs1/EPCIS/edit/master/JSON/WithSensorData/SensorDataExample1.jsonld don't explicitly assert "isA" : "epcis:SensorMetadata" or "isA":"epcis:SensorReport") - so we appear not to be depending on it for SHACL validation purposes.

We can probably reformulate the SHACL to use https://www.w3.org/TR/shacl/#targetObjectsOf instead of https://www.w3.org/TR/shacl/#targetClass so that instead of writing

epcis:SensorMetadataShape
    a sh:NodeShape;
    sh:targetClass epcis:SensorMetadata ;

we'd write:

epcis:SensorMetadataShape
    a sh:NodeShape;
    sh:targetObjectsOf epcis:sensorMetadata ;

I can do some further testing to determine if we can/should omit the "isA" declaration for "epcis:SensorElement" and if we should make adjustments to the SHACL file.

[dakbhavesh]

Hi @mgh128, looks like we can remove the isA property from SensorDataExample1.jsonld as none of the other sensor events contains it. This possibly a one-off case that seems to be missed out on removing isA property. sensorMetadata and sensorReport fields are well defined in EPCIS-JSON-Schema.json hence it's straight forward to validate the JSON/JSON-LD based sensor events using schema.

[VladimirAlexiev]

#278 on using targetObjectsOf (not inferring isA using RDFS reasoning)

[CraigRe]

Agreement to remove isA from examples (sensorReport, sensorMetadata), but not from the event type.