View unanswered posts | View active topics It is currently Fri Dec 06, 2019 8:33 am



Reply to topic  [ 1 post ] 
 Plant Lifecycle Data Model 
Author Message

Joined: Sun Jan 22, 2012 9:14 pm
Posts: 189
The proposed Plant Lifecycle Data Model can be viewed here:
http://www.15926.org/publications/general-discussions/plant-lifecycle-model/index.htm

Summary:

In case of mapping engineered or plant data, the information is "anchored" in one of the lifecycle locations of the Plant Lifecycle Model (link above):
- Process Design
- Detailed Engineering and Plant Design
- Procurement
- Construction
- Operations
- Maintenance

This lifecycle model is a backbone model.

The methodology how to start with legacy data and map into the Plant Lifecycle Model will be worked out in the JORD mapping methodology.
Preliminary "work in progress" link : http://www.infowebml.ws/mapping-methodology/index.htm



What was already written:

OnnoPaap wrote:
About the temporal parts, question:

Looking at "Figure 51 — Instance diagram for pump 1 installed as P101" which can be found in ISO 15926-2 (see here below)
Attachment:
ISO15926-2_Figure 51 — Instance diagram for pump 1 installed as P101.png
ISO15926-2_Figure 51 — Instance diagram for pump 1 installed as P101.png [ 9.2 KiB | Viewed 2176 times ]


The Part 2 Figure suggests that the functional physical object and the materialized physical object are (always) whole life individuals.

This is not expressed in the proposed conceptual diagram. So would they always be the whole life individuals? Or could rather a version (temporal part) of the design being used?


HansTeijgeler wrote:
They can very well be temporal parts. In most instances they will be, although for materialized physical objects it depends where the whole-life individual is in your data base: at the plant or at the manufacturer's shop. In the template
Attachment:
PhysicalObjectManufacturedByTemporalPartOrganization.png
PhysicalObjectManufacturedByTemporalPartOrganization.png [ 46.08 KiB | Viewed 2176 times ]
the manufactured object is a whole-life individual.
The functional physical object is a temporal part anyway (if you approve the lifecycle model).



MagneValenSendstad wrote:
THIS IS AN E-MAIL FROM MAGNE
All,

First a general comment. In the RDL we have the rule that you should always use the most specialized class that is available to you. The same rule should apply to the selection of entity types.

In general I agree with Keith. As a first set of comments I have looked at the Procurement & Construction level. The use of entity types at the lowest level needs some comments. I assume that we are here only talking about e.g. pumps, i.e. mechanical things. Therefore I think both have to be of type materialized_physical_object and arranged_individual. This because a materialized_physical_object as a subtype of possible individual can only have composition relationships. To have an ordering you also need to be an arranged_individual.

The diagram shows an instance of temporal_whole_part between the Physical Object and the Materialized Physical Object, and between the Physical Object and the Functional Physical Object. Is the nature of these the same? Probably not, so we need to establish instances of class_of_temporal_whole_part to convey the meanings. A rough proposal would be to say that one is a “temporal part” and the other “installed at”.

Due to the conceptual level of the model we are by design intended to use RD to convey the required meaning, i.e. meaning beyond the typing. My experience is therefore that we should focus on a diagram convention that has a model instance focus instead of an entity type focus. In PCA we have agreed to use the attached diagram convention. This allows us to have the focus on the RDL instances that are required to convey the meaning, and to state the typing.

Note that I make a distinction between typing and classification. Typing relates to the entity types, and typing is the minimum level of precision one can have. Anything beyond that has to be done by classification, or where required, by specialization.

So, if forced to vote, the answer has to be “No”, but there are many good things in the model so I will be happy to continue.
Sorry if this is a bit “unpolished”, but it is late Whit Monday and we have had the weekend off here in Norway.

__________________________________________________________________________________________________
[HT] Hi Magne,

You state:
Quote:
The diagram shows an instance of temporal_whole_part between the Physical Object and the Materialized Physical Object, and between the Physical Object and the Functional Physical Object. Is the nature of these the same? Probably not, so we need to establish instances of class_of_temporal_whole_part to convey the meanings. A rough proposal would be to say that one is a “temporal part” and the other “installed at”.

As Onno already posted above, this is as defined in Figure 51 of Part 2.

You state:
Quote:
Due to the conceptual level of the model we are by design intended to use RD to convey the required meaning, i.e. meaning beyond the typing. My experience is therefore that we should focus on a diagram convention that has a model instance focus instead of an entity type focus.

[HT] It is interesting that you make the distinction between "model instance focus" and "entity type focus". There is, or rather should be, no difference. Besides that, the RDL is only a sliver of the entire 15926 pyramid (be it an important one). Part 2 entity types shall be used all the way down to the bottom in order to avoid that for each and every validation you would have to find your way up through many layers.
NOTE - I think we need to discuss this in a separate topic. I have done some work on that already.

You state:
Quote:
In PCA we have agreed to use the attached diagram convention. This allows us to have the focus on the RDL instances that are required to convey the meaning, and to state the typing.

[HT] I haven't seen that, and you haven't seen that over time I have published 235+ base templates, and that is why we have the MMT. Life is too short for me to change 235+ drawings. I think that mine are easier to read, because you don't need the acronyms. Semantically there is no difference.

You state:
Quote:
Note that I make a distinction between typing and classification. Typing relates to the entity types, and typing is the minimum level of precision one can have. Anything beyond that has to be done by classification, or where required, by specialization.

[HT] In Part 8 that distinction is also made, be it that in RDF both are using the property rdf:type. For the typing reference is made to the data model ontology, not the RDL (rightly so).


Thu Jun 07, 2012 7:30 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 1 post ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
eXTReMe Tracker
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.