I am trying to model an information reference model/semantic model (eg the TMForum SID) within Essential. My current thinking was to use the following classes:
Business Domain: 5+/-2 classes representing the business domains eg.(Customer domain, Service domain, Product domain)
Information Concept: high level information elements within each domain eg: Customer(now as a concept), customerSLA, CustomerOrder, CustomerInteraction...
Information View: logical information entities with logical attributes ie(Person, organisation, Address, Contact Medium)
I plan to use information view elements so represent the information model classes (with the notion that (for instance) a party class is composed of both an individual and organisation class and has an association to a geographic address -- my end goal is to have the viewer generate a uml class model showing the supertypes, subtypes,relationships and attributes
Questions
1- Is this how you are meant to use the information domain?
2- I don't see any way that you can relate information view elements to each other (using the various cardinalities defined in Idef/UML/etc.
3- would it be better to use the data objects for this (i would not like to since we have a logical data entity (Location) which contains the information Elements (Country, City, State, Road... and i would like to have this difference clear between the two views?
4- We also model the information "elements" which are used by the processes e.g.(Person Attendance Register, Person Skill Report etc). These are modeled also as information views -- how do you differentiate these "information elements" from the "information entities/classes" defined above?
Thanks!
Logical Information Framework eg: SID
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Thanks for your post - a really interesting topic.
I think it might help if I explain how the Information and Data classes are intended to be used.
The first thing to note is that we manage the Information things separately from the Data things, whilst maintaining the links. When using these classes we need to use the definitions of what these are consistently.
I like the phrase "Information is Data in context" to help decide when an element is one or the other. Data things should have consistent semantics regardless of the perspective from which we are looking at it. In contrast Information things have different semantics depending on the context. For example, an Order is a Data element because it contains the facts about who ordered what, when. However, we can create Information elements such as "orders by product" or "orders in the last month" that provide a perspective of a set of the Order data instances, in the context of the product that was ordered or the timeframe in which they were ordered.
It often helps to think about the data objects as the building blocks from which we construct our information, and we can define this directly at the object level of detail or via the Information View attributes (if we need to understand the derivation rules by which each Information View Attribute is constructed from the relevant Data Attributes of the Data Objects. Any Information View should be capable of supporting a business process - that is, they should all make sense from a business process perspective, whereas the data elements won't necessarily.
In addition to defining how a Information View is composed from the relevant data elements, we can also take an object-level perspective and described the sub-components that make up an Information View. Things like the cardinality of these sub-components is not something that we capture at this level - rather that is effectively derived from the Data Object Attributes that are being used.
We've only talked about Information Views and Data Objects. These are used to capture our implementation-neutral logical definition. The corresponding Information Representation and Data Representation classes are there to capture the various implementations (still in logical terms) for each View and Object.
In your opening example, I think what you have as Business Domains are actually Information Concepts or even Data Subjects. In fact, Customer and Product are data things, so would be Data Subjects.
The next level down - Customer, CustomerSLA, CustomerOrder, CustomerInteraction - look like our upper-logical things, e.g. Data Object and Information Views. CustomerOrder would probably be a Data Object but you could have Information Views such as CustomerOrdersByPeriod, CustomerInteractionsOpen. By the way, it's OK to have elements that have the same name - e.g. we could have a Data Subject called 'Customer' and a Data Object called 'Customer'. The forms in Protege will warn us that we've re-used the name by turning it red, but we know they're different objects because they are instances of different classes. It would be a problem, of course, to have two Data Object instances with the same name!
Moving on to the 'logical information entities' you describe, these look like Data Objects and there may be some Information Views along side these.
With the Data Objects, we can define the attributes of each object, each of which has a type that is either one of our primitives or of a type defined by another Data Object instance. So a Customer object can have an address attribute of type Address. Each of these attributes also has a cardinality defined, so in this way we can build up the data model. The intention with the meta model is to support Information and Data Architecture rather than data modelling using UML or IDEF (note that we can define links to such data models created in other tools from any element in the repository). This means that we capture things like the supertypes using the Conceptual layer relationships and the upper-to-lower logical relationships. So, we can define all the types of Product Item Data Objects by mapping them to the Product Data Subject. Similarly, we can understand all the types of Product Item data objects that exist in the architecture by finding all the Data Representations of 'Product Item'.
From all of this content we should have enough content to render graphical data models showing the super types, attributes and relationships for a given scope (which could be all elements!).
What you've captured in terms of the information elements (Question 4) that support your processes sounds like it is in line with how we defined the meta model.
I'm not sure I understand your concern in question 3 in that I'm not sure I understand the distinction that you are trying to make. It's certainly normal to want to classify sets of the Information or Data instances and we can make use of the Taxonomies to do that. We often use such classifications to scope the elements that we'll use in a particular View in Essential Viewer.
I'm not familiar with the details of the TMForum SID but hopefully this helps provide some guidance for how Information and Data things are managed in the Essential Meta Model.
Jonathan
I think it might help if I explain how the Information and Data classes are intended to be used.
The first thing to note is that we manage the Information things separately from the Data things, whilst maintaining the links. When using these classes we need to use the definitions of what these are consistently.
I like the phrase "Information is Data in context" to help decide when an element is one or the other. Data things should have consistent semantics regardless of the perspective from which we are looking at it. In contrast Information things have different semantics depending on the context. For example, an Order is a Data element because it contains the facts about who ordered what, when. However, we can create Information elements such as "orders by product" or "orders in the last month" that provide a perspective of a set of the Order data instances, in the context of the product that was ordered or the timeframe in which they were ordered.
It often helps to think about the data objects as the building blocks from which we construct our information, and we can define this directly at the object level of detail or via the Information View attributes (if we need to understand the derivation rules by which each Information View Attribute is constructed from the relevant Data Attributes of the Data Objects. Any Information View should be capable of supporting a business process - that is, they should all make sense from a business process perspective, whereas the data elements won't necessarily.
In addition to defining how a Information View is composed from the relevant data elements, we can also take an object-level perspective and described the sub-components that make up an Information View. Things like the cardinality of these sub-components is not something that we capture at this level - rather that is effectively derived from the Data Object Attributes that are being used.
We've only talked about Information Views and Data Objects. These are used to capture our implementation-neutral logical definition. The corresponding Information Representation and Data Representation classes are there to capture the various implementations (still in logical terms) for each View and Object.
In your opening example, I think what you have as Business Domains are actually Information Concepts or even Data Subjects. In fact, Customer and Product are data things, so would be Data Subjects.
The next level down - Customer, CustomerSLA, CustomerOrder, CustomerInteraction - look like our upper-logical things, e.g. Data Object and Information Views. CustomerOrder would probably be a Data Object but you could have Information Views such as CustomerOrdersByPeriod, CustomerInteractionsOpen. By the way, it's OK to have elements that have the same name - e.g. we could have a Data Subject called 'Customer' and a Data Object called 'Customer'. The forms in Protege will warn us that we've re-used the name by turning it red, but we know they're different objects because they are instances of different classes. It would be a problem, of course, to have two Data Object instances with the same name!
Moving on to the 'logical information entities' you describe, these look like Data Objects and there may be some Information Views along side these.
With the Data Objects, we can define the attributes of each object, each of which has a type that is either one of our primitives or of a type defined by another Data Object instance. So a Customer object can have an address attribute of type Address. Each of these attributes also has a cardinality defined, so in this way we can build up the data model. The intention with the meta model is to support Information and Data Architecture rather than data modelling using UML or IDEF (note that we can define links to such data models created in other tools from any element in the repository). This means that we capture things like the supertypes using the Conceptual layer relationships and the upper-to-lower logical relationships. So, we can define all the types of Product Item Data Objects by mapping them to the Product Data Subject. Similarly, we can understand all the types of Product Item data objects that exist in the architecture by finding all the Data Representations of 'Product Item'.
From all of this content we should have enough content to render graphical data models showing the super types, attributes and relationships for a given scope (which could be all elements!).
What you've captured in terms of the information elements (Question 4) that support your processes sounds like it is in line with how we defined the meta model.
I'm not sure I understand your concern in question 3 in that I'm not sure I understand the distinction that you are trying to make. It's certainly normal to want to classify sets of the Information or Data instances and we can make use of the Taxonomies to do that. We often use such classifications to scope the elements that we'll use in a particular View in Essential Viewer.
I'm not familiar with the details of the TMForum SID but hopefully this helps provide some guidance for how Information and Data things are managed in the Essential Meta Model.
Jonathan
Essential Project Team
