Plant Lifecycle Data Model

old topics
Locked

Do you understand and approve this model?

I don't understand the model and need further clarifications; therefore I abstain for the moment
0
No votes
I understand the model, but I don't agree with it and I will offer a better alternative
0
No votes
I understand the model and approve it.
2
100%
 
Total votes: 2

Message
Author
HansTeijgeler
Posts: 283
Joined: Sun Jan 22, 2012 10:02 pm

Plant Lifecycle Data Model

#1 Post by HansTeijgeler »

Dear MMT members,

I propose a high-level data model, covering a plant from conceptual process design to a real-world implementation, for your approval.

The documentation can be found at http://15926.org/publications/general-d ... /index.htm.

Please respond via this forum thread.

Regards,
Hans

vvagr
Posts: 282
Joined: Mon Feb 27, 2012 11:01 pm
Location: Moscow, Russia
Contact:

Re: Plant Lifecycle Data Model

#2 Post by vvagr »

I don't think it's a good practice to mix rdf: and rdfs: predicates into a Part 2 or Part 7 diagram!

HansTeijgeler
Posts: 283
Joined: Sun Jan 22, 2012 10:02 pm

Re: Plant Lifecycle Data Model

#3 Post by HansTeijgeler »

Hi Victor,

You are right, but I used rdf:type instead of the Classification relationship in order not to clutter the diagram too much.

But other than that you agree with the diagram?

Regards,
Hans

vvagr
Posts: 282
Joined: Mon Feb 27, 2012 11:01 pm
Location: Moscow, Russia
Contact:

Re: Plant Lifecycle Data Model

#4 Post by vvagr »

At this conceptual level it will be enough to use usual three types of arrows for classification, specialization and part-whole relationships! The diagram will be much easier to read.

I can not find any problems with the diagram, but I need some time to reconcile it with you description of engineering process itself. I'm still not very familiar with engineering part of all this domain.

Pavel Selchukov
Posts: 12
Joined: Tue May 15, 2012 7:06 am

Re: Plant Lifecycle Data Model

#5 Post by Pavel Selchukov »

I think all is fine with this model.

Annotations are sufficient.

OnnoPaap
Posts: 189
Joined: Sun Jan 22, 2012 9:14 pm

Re: Plant Lifecycle Data Model

#6 Post by OnnoPaap »

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)
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 24937 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
Posts: 283
Joined: Sun Jan 22, 2012 10:02 pm

Re: Plant Lifecycle Data Model

#7 Post by HansTeijgeler »

Hi Onno,

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 [img]PhysicalObjectManufacturedByTemporalPartOrganization.png[/img] the manufactured object is a whole-life individual.
The functional physical object is a temporal part anyway (if you approve the lifecycle model).

Regards,
Hans
Attachments
PhysicalObjectManufacturedByTemporalPartOrganization.png
PhysicalObjectManufacturedByTemporalPartOrganization.png (46.08 KiB) Viewed 24936 times

OnnoPaap
Posts: 189
Joined: Sun Jan 22, 2012 9:14 pm

Re: Plant Lifecycle Data Model

#8 Post by OnnoPaap »

I guess this model is the basis of the instanced data. To be approved first so that we can build on its model.

I have re-instated the poll and voted approved.
Last edited by OnnoPaap on Tue May 29, 2012 11:46 am, edited 1 time in total.

HansTeijgeler
Posts: 283
Joined: Sun Jan 22, 2012 10:02 pm

Re: Plant Lifecycle Data Model

#9 Post by HansTeijgeler »

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.

Regards,
Magne
__________________________________________________________________________________________________
[HT] Hi Magne,

You state:
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:
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:
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:
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).

Regards,
Hans

Admin
Site Admin
Posts: 32
Joined: Wed Jan 18, 2012 8:50 pm

Re: Plant Lifecycle Data Model

#10 Post by Admin »

LOCKED this topic.

A new topic has been started having a summary of the discussions of this topic.

See http://15926.org/viewtopic.php?f=3&t=17

Locked