Define inverse names of EPCIS properties

[VladimirAlexiev]

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:

• The PROV Ontology has considered the same problem and defines prov:inverse, see https://www.w3.org/TR/prov-o/#inverse-names
• "Virtual inverses" are useful in GraphQL to ensure bidirectional navigation of the graph.
• Eg the Ontotext Platform has an "inverseAlias" feature, see http://platform.ontotext.com/soml/properties.html#inverses

I'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:

• Always use singular
• When the range has only one kind of relation to the domain, use merely the domain name, eg:
  • cbv:BizStep - event - epcis:EPCISEvent (inverse name of epcis:bizStep)
• When the range has several kinds of relations to the domain, disambiguate by adding more words:
  • epcis:SourceOrDestination - eventWithDestination - epcis:EPCISEvent (inverse name of epcis:destinationList)
  • epcis:SourceOrDestination - eventWithSource - epcis:EPCISEvent (inverse name of epcis:destinationList)
  • gs1:Place - eventWithBizLocation - epcis:EPCISEvent (inverse name of epcis:bizLocation)
  • gs1:Place - eventWithReadPoint - epcis:EPCISEvent (inverse name of epcis:readPoint)
  • cbv:Disp - dispToSet - epcis:PersistentDisposition (inverse name of epcis:set)
  • cbv:Disp - dispToUnset - epcis:PersistentDisposition (inverse name of epcis:unset)
• Datatype props don't have inverse names
  (because you can't navigate eg from value: 3.14 to all sensorReports having that value, and it that's not a reasonable requirement to navigate in this way)
• Object props without range don't have inverse names because there's no class to attach the virtual inverse to
  (although it would be valuable to find sensorReports about given chemicalSubstance or microorganism)

To be emitted like this (penultimate line):

epcis:bizLocation  a      owl:ObjectProperty , rdf:Property ;
        rdfs:comment      "(Optional) The business location where the objects associated with the EPCs may be found, until contradicted by a subsequent event."@en ;
        rdfs:domain       epcis:EPCISEvent ;
        schema:domainIncludes epcis:EPCISEvent ;
        rdfs:isDefinedBy  epcis: ;
        rdfs:label        "bizLocation"@en ;
        rdfs:range        gs1:Place ;
        schema:rangeIncludes gs1:Place ;
        prov:inverse      "eventWithBizLocation";
        sw:term_status    "stable" .

[mgh128]

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.

[VladimirAlexiev]

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