SID Location (Place) domain analysis

Location Issues

This section provides a short description of issues (from my personal point of view) and inconsistencies (or areas of misunderstanding) in the current version of the SID Location domain model and Addendum document.
1. Reusability and data integrity issues.
A lot of place attributes and characteristics are duplicated in different classes, or objects of the same class. For example, a street name (as attribute) is presented in a few classes. That could cause duplicates and mistakes. At the same time, a “streetName” attribute of an Urban Property Address (for example), means that there could be many address objects with the same value for the given attribute. This situation could lead to spelling mistakes in the name of the same street, errors in case the name of the street is be changed everywhere at the same time, mistyping and using another street name instead of the required. All those cases lead to problems with reusability and leave a room for data integrity issues.

2. Geographical address is a logical entity.
If it necessary to send a post letter, there should not be difference between post box and real address destination. So, it is not clear why the post box is a logical address, but real delivery address is not a logical one. In reality, a postal (or, any other) geographical address is a logical rather then physical entity. All those address parts (country, state, county, locality, city, town, post code, street name, etc.) are logically created by people in order to describe some “physical” place – a geographical placeholder for an “object of interest”.

3. Best practice ignorance.
Geographic Site Role is inherited from Geographic Site. That approach does not fit to “Entity” – “Entity Role” SID pattern, and does not provide real flexibility of using the Geographic Site in different roles at the same time.

4. Name attribute generalisation.
The Geographic Location class has a name characteristic, which is designed as a separate class Geographic Location Name aggregated by the Geographic Location class. A lot of other classes (i.e Geographic Site and its children classes, as well as logical components of Geographic Address – street, city, state, locality, etc.) have (or should have) the similar characteristic. It is probably worth to design such characteristics in a more generic way.

5. Post Box issue.
An aggregation between Logical Address and Geographic Address with “one” cardinality at Geographic Address side does not allow to get a simple post box without full Geographic Address (including street, house number, etc.). For example, a post box "PO Box 49920, SE5 7ZF" (post box number, post code) is a valid post address for the UK.

6. Location and Address Roles.
The approach which is used in the current version of the document is to define a location and/or address, and then define a role for it (customer billing address, CPE location). So far, a place/location/address are primary entities, to which all other business entities could be bound to. Alternative approach - is to define a placeholder with some business sense, and than bind it to a place/location/address.

Location Business Use Cases analysis

This section is dedicated to analysis of different business use cases in terms of data usage - what place/location domain data should be used, how that data could be used, what should be stressed out, etc. The majority of business process and activity steps, as well as roles, conditions, etc. were put out of scope. A few business use cases have been chosen (basically from the original SID Model Location Addendum document) and discussed to highlight to most important commonalities and data usage patterns.

UC1. Where to send a customer bill, or what address is to be put on the bill?

Why the communication provider requires this information and how does it use it? In some cases the communication provider requires to keep and use information about the billing address. It could be for legal reasons, or it could be necessary to put that address on the customer bill header, or it could be actually used as an address to which bills are to be sent by post.
There could be multiple other reasons as well, but one of the most important thing is - this post address is a logical convention commonly accepted in a particular administrative area which is (1) required for the customer to accept that the bill is not for some other person or organisation; and (2) enough for third party logistics/delivery organisation (i.e. post service) to provide bill delivery service for the communication provider.
It is also worth to mention, that in this business use case the communication provider is not really interesting in - (1) using billing address for organising face to face meeting with the customer or visiting the customer; (2) where the address is located in terms of latitude and longitude; (3) how far this address is from any other address; (4) is it an office block, a flat, a house, or a simple post box in the middle of nowhere.

UC2. How to contact a customer (for a meeting, collaterals or documents delivery, physical resources delivery - post/office/home address, shipping address)?

In addition to a customer billing address, the communication provider would like to keep information about other customer addresses as well - if the customer is an organisation it could be a registered address, an address for physical resources delivery, an address for contact meetings and collateral sending, etc.
Generalisation - all these addresses are used for intangible (information) or tangible (physical resources) items delivery according to logical conventions of the given administrative area for differentiating and ability to find specific places for human interactions. Communication provider is interesting in ability to find a point/place, rather then in finding it in the particular circumstances.
In nutshell, the communication provider has some interest in all those places, but, within the scope of this business use case, there is no interest in - (1) mutual location of those places; (2) calculation and composing of routes from one place to another (this is another task); (3) keeping information about longitude and latitude; (4) physical characteristics of those places.

UC3. Where is a CPE (or a handover/access point for a product/service)? - address/access/local details/location - Or where does the customer require a product/service?

There are a few reasons why this information is necessary for a communication provider, and how this information could be used. We also should bear in mind the difference between (1) keeping and updating relevant information and (2) how it is used in particular scenarios.
The communication provider would like to keep information about CPE (product/service access or handover point) place for plan and build and provisioning activities, QoS restrictions calculation, assurance processes, marketing, BI analysis and so on. In majority of cases address details are enough. In some cases it is necessary to keep additional information - how to find, to connect to, to maintain the equipment locally (requires additional details based on the given address information).
What is really interesting in this business use case - is two points of view on CPE (access point) place/location details - (1) internally (from inside the place entity domain) - we should take care in maintaining the most actual information of its place according to commonly agreed logical coordinate system - earth geoid or local logical community address conventions over period of time; and (2) externally - the communication provider does not really care where that point is, unless it is necessary to modify product/service characteristics or communication provider equipment configuration or to support the agreed commitments to the customer in the particular point of time.
From the first point of view - all data manipulations happens inside the place entity domain, until they begin affecting agreements between the communication provider and the customer. For example, the post code or the street name of customer premises (where the CPE or service/product access point is placed) could change, but it should not affect communication provider's commitments to the customer.
From the second point of view - the place entity domain should hide all details behind one "point of interest" element (or "product access point" element), though which, in the particular time, actual place information is fetched. For example, a product was originally provided to customer premises with some address details. The address was changed (according to new logical community address conventions), but the real premises was not changed. Communication provider commitments to the customer are to be preserved. The next time, when the address details are required, for example, for assurance purpose - arranging a visit, - a new address details are to be fetched by using the old, unmodified "point of interest" key.
Therefore, the place entity domain should hide all complexity of place/location details stewardship, and expose a key, or handle, or "point of interest" "anchor" by using which in a particular time the relevant details could be fetched by using entities associations.

UC4. Where is the nearest point of interest (hospital, police station, fuel station, shop, cinema, etc) to the CPE (or service/product access point) place?

In this business use case there is one main point of interest (CPE or service/product access point, which could be a mobile terminal), and some criteria to choose other point of interests (based on some characteristics, types, name, etc.). The nearest does not necessarily mean the shortest distance in meters. kilometres or miles. For example, it could be the most convenient or fastest for driving access.
Suppose that system which provide stewardship for place data entities and their relationships is able to answer the question in this business case. The required input information in the request:
a reference to the central point of interest (to which all other relevant objects are to be sorted based on some criteria);
a criteria to choose a list of other points of interest (or a list of references to those points of interest);
a criteria to sort the list.
The output information in the response:
a sorted list of points of interest (or list of references to those points, sorted according to the provided criteria).
It is worth to mention that in this use case, the originator of the request was not interesting in - (1) either post addresses of CPE or points of interest which were referred for sorting; (2) their coordinates based on earth geoid (latitude and longitude); (3) distance between them, etc. All those details are hidden behind the place entity domain external relationships/associations facade.
An assumption which can be concluded from this use case - non place domain entities probably should be associated only with some kind of point of interests, rather than directly with - addresses, coordinates, GIS spatial information, object geometry, etc.

UC5. Where is a communication provider equipment? (address, how to find, access details, local place, etc.)

We have a handle - reference to the point of interest, which is associated with the given peace of equipment. By using this handle we makes requests to get the following details:
a copy of a post address (in textual format);
a copy of additional details (i.e. in textual format) about access to the premises, where the given point of interest is placed;
a copy of details how to find (or where to find) a local place for the given point of interest.
It is worth to highlight again that in this use case we don't update any place entity domain data, and we are not interesting in logical (latitude, longitude) geoid based coordinates, or in that equipment (place) geometry, or any neighbour objects.
If we fulfil this use case with the same input parameters in different time, the output results could be different. This could happen because post address or logical geoid based coordinates could be changed over time, but the equipment "handle" (point of interest) is preserved unmodified for the external requester.

UC6. Where is a growth for a product usage/selling? (area, community, etc.)

This use case represents a statistical business intelligence task. Place domain entities are preserved unmodified. For area relevant for the place data domain the input parameters are:
a list of references to logical ares - names, handles, etc.
a list of references to service/product access point ("points of interest"), each of them could be provided with associated additional values (i.e. access bandwidth, revenue, etc.)
The output parameters:
a map <logical area , total value of products/revenue/utilised capacity, etc.>
One more time again - we do not interesting in areas geometry or mutual logical relationship, we do not care about address details, or places latitude and longitude. All that staff is hidden behind "point of interest" handle.

UC7. Where (in which area) do we have spare capacity for product selling growth, and how many customers/prospect customers do we have there? (define area for marketing purposes)

This use case is very similar to the previous one. At the same time it has a few preliminary steps before a request can be directed to the place domain entities and their associations.
First of all - we should define "points of interest" with (spare or used) capacity.
Second - we should define areas - "areas of interest" which will be used as resulting "baskets" for mapping.
Third - we should define a set of utilised product/service access points for a given product type - that will be another type of "points of interest"
As soon as we define all those "handles", we can compose a request to systems/platforms/capabilities which provide the relevant functionality and data stewardship.
In a similar way as we did in all previous use cases, we have build a "buffer" from "points of interests" (or "handles") between the place domain data entities and all (relatively) external entities.
It looks like that all associations between place/location domain data entities and (relatively to this domain) external data entities could be grouped to reference/keys associations to "points/areas of interest" entities on the boundary of the place/location domain. Those "points of interest" becomes a handover points or gateways for accessing place/location details.
A lot of place/location based operations can be delegated to systems/platforms/capabilities which hide complexity of place/location domain data model behind the scene, thus coherence between this domain and any other data domains could be weakened.

UC8. Where are the available resources that are designated for supporting service delivered to a customer's service address?

This use case represents a correlation between a customer's service address and a pool of resources that have been designated to support a particular specification of service, when delivered to a service address that falls within the pool's geographic serving area. For example, the North Dallas area is given telephone number blocks with area codes 214, 469, and 972; all the telephone number blocks with these matching area codes are organized into a pool that is associated with geographic place representing the bounding region, where these numbers may be assigned to customers, who reside within that region. When allocating a telephone number, the customer's service address must fall within the region in order to be able allocate resources from that pool.