Context and Rules in Information Views

Post Reply
hunter.blacker
Posts: 6
Joined: 31 Jul 2012, 13:04

"Information is data in context."

As I have modelled Data Objects and Information Views, I have come across a couple of needs to better represent the Information Views.

First, the Information_Concept class supports the Business_Domain class relationship as a way to provide context. However, I need to expand on the context when describing the Information_View, and there does not appear to be a class for capturing contextual information.

Here is an example. In my CRM system, there are many addresses captured for a Customer. Some addresses are Primary Residence, Ship To, Bill To addresses with clearly defined meanings. However, there is a separate address associated with the Customer which is the favored address that the Customer prefers all transactions to use unless otherwise specified. This address may switch while the Customer is away on business, at a vacation rental, etc. We store all addresses and reorder the addresses in the CRM to reflect the Customer's current preferred address. Therefore, I would like to add the contextual meaning to that particular Information_View used in retrieving/displaying this address. Other than adding a phrase in the name of the Information_View, do you have any suggestions for how best to capture this contextual information?

Second, in integrations between systems, I have business rules which explain how to translate Information_View_Attributes from one system to the other. The business rule is not tied to either the source or the target Information_View, but it is employed between the source and target. I would like to have some way to represent this logic and associate it with Information Views through some additional relationship class used when the two Information Views are used in a transaction. (I'm thinking of a relationship class like the Application_Provider_Role which creates an instance of an Application_Provider acting as a particular Application_Service.)

Here is an example. My CRM represents street address as a single field. My MDM represents street address as individual components of street number, street direction, street name, etc. When sending the MDM Information_View to the CRM system, I would like to have a way to capture that the concatenation of the street number, street direction, street name, etc. must be performed in order to meet the requirements of the CRM Information_View. Do you have any suggestions for how best to capture these business rules and their relationships to Information Views?

Thanks,
Hunter
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

On your first question, I think I would create a new Information View called "Customer Preferred Address" and map it to the relevant Customer and Address Data Objects (which will be related as Data Attribute types in the Customer object).

In terms of where the contextual information about which address attribute to choose when providing this Information View, we normally add this to the description of the Information View. The description field is where we capture additional aspects of the definition of any element that is not covered by creating a relationship. The out-of-the-box views use the description field on every summary page to give us a clear definition, e.g. like in a data dictionary. The point here is that the description field is important and is not just an optional nice to have - in particular with Information and Data elements.

That's at the object / view level of granularity. However, if we model at the attribute level and in this case define an Information View that is providing a 'report' of a Customer details, we can describe the attributes that make up the view and for Information View Attributes, we can capture the 'Data Derivation Definition' where we can specify the calculation or any logic that needs to be applied in order to populate an instance of that View Attribute. This is a separate field of the View Attribute Class in addition to the description field.

Within Essential, we are dealing with meta data so these definitions or descriptions are not required to be 'computable' in any way as we're not dealing with the instances of the data.

I think this last bit about the Information View Attributes also applies to your question about integration. Applications exchange Information things in integration scenarios. The Application Services deal with Information Views and the Application Providers operate on Information Representations, which at the attribute level have fields available to describe the transformation / derivation logic/rules that you have.

There are some quite subtle but very powerful relationships between Application Providers, Information Representations and Data Representations that help us understand what is happening to the Data elements as they are being used by Information things as the Applications go about their business. These relationships have evolved over time to their current state from what we have needed in order to give us high-fidelity in our models to support Data Management activities accurately.

Jonathan
Essential Project Team
Post Reply