Open VladimirAlexiev opened 2 years ago
I took a look at https://www.w3.org/TR/prov-o/#inverse-names and at column D of https://docs.google.com/spreadsheets/d/19lseUd1kHiz48VNtrHXy6kafLTlNzS1GsaYiBqdT4UA/edit#gid=138789609 - but as column D currently stands (and as you note above), it's not sufficient, since it shows epcis:bizStep and epcis:errorDeclaration sharing the same inverse name. Since these clearly would not share the same inverse property (because that would imply that they're equivalent properties), the inverse names need to be distinct.
I think we need a stronger justification for this and strong support from the group before we add this.
I prefer simpler names when accessing "virtual inverses" (denoted ..>
below):
Event --> bizStep --> BizStep
BizStep ..> event ..> Event
because that makes for nicer "symmetric" GraphQL queries, eg
event {bizStep}
bizStep {event}
which is similar to how the JSON API works.
But you're right that if people want to use these names for actual inverses then the names should be distinct:
Event --> bizStep --> BizStep
BizStep ..> eventsWithBizStep ..> Event
Inverse properties are redundant in RDF because SPARQL can always navigate in both directions no matter which direction is expressed by a property. (Eg by using an inverse property path:
?y ^epcis:prop ?x
instead of?x epcis:prop ?y
.So it's right that EPCIS does not define any inverses. However, defining the names of potential inverses is useful:
prov:inverse
, see https://www.w3.org/TR/prov-o/#inverse-namesI'd suggest that EPCIS defines the inverse name of each property. I started this as a new col
inverse name
in the props gsheet using these guidelines:epcis:bizStep
)epcis:destinationList
)epcis:destinationList
)epcis:bizLocation
)epcis:readPoint
)epcis:set
)epcis:unset
)value: 3.14
to all sensorReports having that value, and it that's not a reasonable requirement to navigate in this way)chemicalSubstance
ormicroorganism
)To be emitted like this (penultimate line):