In a recent post here on this blog the Master Data Management domain usually called locations was examined and followed by excellent comments.
Also in the DAMA International LinkedIn group there was a great discussion around the location domain.
The comments touched two subjects:
- Are locations just geographic locations or can we deal with “digital locations” as eMail addresses, phone numbers, websites, go-to-meeting ID’s, social network ID’s and so as locations as well?
- How do we model the relations between parties, products and locations?
Sometimes I like to use the word places instead of locations as we then have a P-trinity of parties, products and places.
I’m not sure if places have a stronger semantic link to geography than locations have. Anyway, my thoughts on the location domain were merely connected to geography. The digital locations mentioned also in my eyes are more related to parties and not so much products. The same is true for another good old substitute for a location or address being a mailbox (like “Postbox 1234”), which is a valid notion for the destination of a letter or small package, and often seen in database columns else filled with geographic locations.
So, sticking to places being physical, geographic locations: How do we model parties, products and places?
First of all it’s important that we are able to model different concepts within each domain in one single way. A very common situation in many enterprise data landscapes is that different forms of parties exist with different models, like a model for customers, a model for suppliers, a model for employees and other models for other business partner roles.
The association between a party entity and a location entity is in most cases a time dependent relation like this consumer was billed on this address in this period. The relation between the party and the product is the good old basic data model, that we invoiced this and this product on that date. The product and place relation is very industry specific. One example will be that an on-site service contract applies to this address in this period.
Time, often handled as a period, will indeed add a fourth P to the P-trinity of party, product and place.
Liliendahl on Data Quality 
LOL, i read that title and though: he had a great weekend!
Interesting to think of a PO Box as not being tied to a geography. It is tied to a geography in the US (they do not move between post office) but it’s more of a general area than a specific location. So a Post Office serving town XYZ is presumed to represent companies/people in that area.
Trickier are the commercial box companies (Mailboxes Etc) which don’t follow the rules that we presume in the USPS. You can spot these by the address “PMB 123”. I find them a bit confusing.
-XC
Thanks Cliff, I actually had a great weekend 🙂
It’s true. A PO box address will usually have a postal code and city beside telling about the area, though I have seen different use around the world.
I like the fact that we can connect the digital location into the mix. I think what industry is grappling with is the use case for the information and how much can they rely on it to get insights. In the digital world or for online organization Digital Location is the best bet to use instead of geography as it provides more insight and information than merely the geographical location.
Also I completely agree with the fact that similar entities should follow similar model to encourage uniformity.
On the period dimension – I think it is most useful for trends and insights.
So the model needs to reflect the use of the entity.
Thanks for joining Rohin. My experience with the time or period dimension is that you will need it sooner or later, so to speak.