SDMN — Semantics of Location and descendants

Firstly I would expect to see Locations in the Party model, and shared by all other BPM+ specs. This is probably intended; just noting it here.

The documentation of Location is:
Location is an abstract class where its concrete specializations identify a particular place or position. Locations are contained within a SDMNPackage and can be referenced by DataItems.

Better wording of the first sentence:
Location is an abstract class whose concrete specializations identify a particular place or position.

Semantically, it should possibly say 'a particular addressable place ...', since this part of the model is about locations that can be identified by address. There arguably should be a derived attribute, function or even data property to carry such an address. If derived, it would be a stringified form of a structural address.

Addresses are likely to take different structural forms, e.g. street address, geo-spatial (lat/long) address, cadastral map references and so on.

There is a sub-type for NetworkAddress, which is not a 'location' in the physical sense. I would call it a kind of address rather than a kind of location.

On the other hand, GeoSpatialExtent is documented as: A location that is a volume in the world such as a container or a room. This is arguably a kind of location - although perhaps an object - presumably movable - is also intended. It is not clear how it is addressed. If movable things are intended, then the 'address' is some sort of identifier of the container, e.g. truck, plane, test-tube in a lab etc.

A useful resource for thinking about some of these types is BFO2.0, which can be found here: http://gbadske.org/Files/BFO2-Reference.pdf - see p3 for the is-a hierarchy.

Another reference is how we do this in openEHR, which separates 'place' from 'address'. See https://specifications.openehr.org/releases/UML/latest/index.html#Diagrams___19_0_3_8fe028d_1648920292880_630012_5562

Proposed Change:

The Locations part of the model needs to be adjusted to correctly distinguish between 'places' and 'addresses', and also between physical and informational entities. It appears that the real need of the model is to be able to form references to any kind of entity.

It might therefore be clearer to change DataItem.locationRef to DataItem.locator, meaning a reference that can be resolved to find the target entity. The Location class could also be renamed to Locator, and the subtypes could be as follows:

* PhysicalLocator
    * SpatialLocator - locators for entities fixed in space
        * PlaceAddress, meaning a building, site, home etc address
        * GeospatialLocator, meaning lat/long, possibly altitude as well 
        * possibly type(s) for any other common types of map / cadastral reference
    * ObjectLocator: locator for movable objects
* DataLocator, meaning a (probably) URI resolvable to obtain a data item

The type SpaceTime is not a Locator as such, it just adds a time period, presumably to indicate validity. It would be better to remove this type and add the two attributes startTime and endTiime as optional attributes in Locator.

Properties in other classes that are currently named 'locationRef' could potentially be renamed 'locator'.