role-relative class definitions are bad

[VladimirAlexiev]

https://ns.mh1.eu/epcis/ defines two classes thus:

BizLocation: A Business Location is a uniquely identified and discretely recorded location that is meant to designate the specific place where an object is assumed to be following an EPCIS event until it is reported to be at a different Business Location by a subsequent EPCIS event. As with the Read Point, the EPCIS Capturing Application determines the Business Location based on whatever means it chooses. Conceptually, the Business Location is designed to identify 'where objects are following the EPCIS event'. ReadPoint: A Read Point is a discretely recorded location that is meant to identify the most specific place at which an EPCIS event took place. Read Points are determined by the EPCIS Capturing Application, perhaps inferred as a function of logical reader if stationary readers are used, perhaps determined overtly by reading a location tag if the reader is mobile, or in general determined by any other means the EPCIS Capturing Application chooses to use. Conceptually, the Read Point is designed to identify 'where objects were at the time of the EPCIS event'.

Such definitions are more appropriate for the properties bizLocation and readPoint but not for the classes.

A BizLocation is something with a GLN: a company, its site, a warehouse, room, or door. Yes, events are related to locations, but the main function of a business or location is different: it is to "run" (trade and transport) goods, not to generate events.

The problem is not just definitional. The problem is that if you look at classes from the point of view of their role in some event, rather than their absolute "worth" or "role in the real world", you'll create sub-optimal classes:

• How's a ReadPoint different from a BizLocation? A reading can be taken at any BizLocation, so I think there isn't much of a difference.
• You could define it as a subclass: "ReadPoint is a finer-granularity (most specific) BizLocation, where readings are usually taken, eg by stationary readers"
• But do you really need such class? What extra props would it have compared to BizLocation?

[VladimirAlexiev]

Two rules of thumb:

• Consider each entity used as object (the target of a relation) in its own right, and which are its innate attributes;
  • Consider the relation Event-object separately, and which attributes belong to it. These are attributes not innate to the object, and can legitimately vary from one event to another.
  • A good example is #215 where type is innate to BizTransaction (or better called BizTransactionDocument) and is not an attribute of the relation.
• Every time you see blank nodes in the Turtle representation, suspect there may be some modeling error

[CraigRe]

"wontFix" pending... please provide concrete drafted input ASAP. (thanks!)

[VladimirAlexiev]

@CraigRe I think @mgh128 can confirm that there are no classes BizLocation and ReadPoint in the ontology. Both props point to gs1:Place. I'm not sure what definition that class has (or will have) but obviously it cannot be two different definitions.

Do you want me to make a list of classes where the definition has this defect?