Class Model

old topics

MMT SIG approved?

Poll ended at Tue May 29, 2012 7:52 am

Yes
1
20%
Yes with comments
2
40%
No
0
No votes
No with comments
1
20%
Blank vote
1
20%
 
Total votes: 5

Message
Author
KeithWillshaw
Posts: 77
Joined: Tue May 15, 2012 8:48 am

Re: Class Model

#11 Post by KeithWillshaw »

[HT Said]
> Much more than I have written in:
> - http://www.15926.info/plant-design/index.htm
> - http://www.15926.info/functional-vs-mat ... object.htm
> - http://www.15926.info/functional-physic ... /index.htm
> - http://www.15926.info/cradle-to-grave/index.htm
> I cannot bring to the table.
> If that does not convince you, I rest my case.

I have been through these documents and you make some very good points
with regard to the importance and nature of the Tag Code

I agree that the tag is in itself not that important.

However we still have to model both a functional and physical object that may
or may not have a tag number and what I am struggling with is why do we think it
appropriate to model it as a CLASS prior to installation and as an Individual
afterwards ?

I would argue that we have separate but related physical and functional objects well before
we bolt a pump onto its baseplate. On typical offshore projects the process
of procurement of major plant items proceeds in parallel with detailed design.
I have personallyy worked ona major gas compression project where we
ordered the compressors before the P&ID's were finalized let alone the 3D model.



There are some important aspects of the CLASS proposal that are not clear to me
from the documents and I need to clearly understand these before making any
decisions. One of the major ones is this.

If we accept that a functional plant item such as a specific PUMP should be modelled
as a class does this mean that the CLASS that represents P-101 has to be defined
in our Reference Data Library with a url and unique reference ID just as we do with
the CLASS CENTRIFUGAL PUMP ?

The implications of this are obvious in terms of maintaining and propagating the Reference Data

[HT Said]

> In response to your 4+ points:
> Re 1) - You misread me. I didn't say that for a given plant there are unlimited classes.
> But no matter how you store the lifecycle information of a plant, you end up with petabytes of data.

If I misrepresented you then I apologize for that. I understand that petabytes of data
will be acquired in the course of a plant lifecycle the issue in my mind is the
balance between having to actively maintaining Reference Data and Repositories


> Re 2) - That clean point is installation, see Part 2 fig. 51

As I mentioned earlier in the thread I thinks this is arguable. Procurement and
testing of the physical object occurs long before installation. As an example
in the case of a pump the actual shop performance test data of the physical
item being bought will be available long before installation.

> Re 3) - See http://www.infowebml.ws/mapping-methodology/index.htm

I looked at this carefully and I still have some problems with this, let me give you a use case

We are approaching the end of the detailed design phase and the client gas requested
we transfer data that essentially amounts to the Equipment List

Lets say he requires the following information

Tag Number - Normal Operating Pressure - Purchase Order Number - Purchase Status - Serial No


Clearly here we are transferring data about both the functional and physical object
so when we get to P-100 does this imply we have to define both in our Part 8 file
then associate the Design properties with the CLASS that represents P-100 and the
Physical Properties with the Individual that represents P-100 ?

IF so does this change after installation ?


> Re 4) - How do you do that in iRING?

Well within the current iRING protocols both the physical and functional objects
are individuals so the templates used dont change when we reach some particular milestone.

This does not imply that the templates currently used are correct or adequate
for lifecycle modelling. I would be the first to agree that we need to handle
the temporal aspects much better than we do at present.


> Furthermore:

> Quote:
> Its relatively easy to mak rules such as PID = Class BUT as PID's remain important and are updated long after the plant is commissioned is this a valid distinction ?

> [HT] - A distinction between what? Nobody said that you have to do away with P&IDs and other documents.
> It so happens that in the Part 2 data model we model documents as instances of ClassOfInformationObject,
> of which the contents are defined with instances of ClassOfInformationRepresentation.
> If the document deals with plant design, the objects on that document represent instances of Class.
> That remains the case until the end of the plant when all records are destroyed.

I was somewhat imprecise here. I am not speaking of the PID as a document but rather
alluding to the objects modelled as that part of the detailed design process commonly
referred to as the PID.


> Finally:

> Quote:
> Additionally an increasing number of owner operators are wanting to operate a consolidated Data Management
> system that acts as an asset register and which issues tags and stores approved changes.
> Its not clear to me how using a Class for a tagged item instead of an individual fits into this requirement.

> [HT] - ISO 15926 does not replace application software, so the issue of tags etc stays where it is now.
> But these data are mapped from such applications to the ISO 15926 Part 8 format and stored in
> federated or consolidated triple stores. Storing lifecycle information means a kind of sedimentation.
> At a later date you can do data mining and see what exactly happened in the plant.
> And by the way, if you look at the far righthand bottom corner of
> http://15926.org/publications/general-d ... /index.htm you can
> see that the assets are instances of MaterializedPhysicalObject.

Clearly ISO 15926 does not replace application software but the way we model data at
the design stage as against that from the procurement and construction phase impacts
the way we map data from the master Asset Register to the ISO 15926 world.

My problem here is practical not philosophical. My asset register is initially
populated at the design stage and contains data derived from the design, procurement
construction and operational phases. Much but not all of the data produced in the
detailed design remains important long after installation and commissioning, clearly
its subject to change so we need to consider termporal aspects but the notion of
passing some properties of the Asset in the form of Classes and others as Individuals
seems confusing to me and quite hard to manage.

If this is indeed required then we can look at the implementation issues in
greater detail but at this point I just do not see the end to go down this route.

If I am missing something important please let me know.

Regards Keith

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

Re: Class Model

#12 Post by HansTeijgeler »

Hi Keith,

You wrote: I am struggling with is why do we think it appropriate to model it as a CLASS prior to installation and as an Individual afterwards
[HT] The manufacturer of the materialized physical object designs his pump model as a class with, hopefully for him, many members. Likewise we have a functional physical object (function place) that we design as a class. As I wrote, you can build more than one plant from a plant design, such as happens when you use a design from a process licensor.

You wrote: I have personally worked on a major gas compression project where we ordered the compressors before the P&ID's were finalized let alone the 3D model.
[HT] Yes, it is common practice to purchase long-lead equipment in order to meet the schedule. So you map their data and store that in a façade. Later you derive from a P&ID how they are to be interconnected (at class level :) ). What's the problem? You don't design the plant with 15926, you put on record what you designed.

You wrote: If we accept that a functional plant item such as a specific PUMP should be modelled as a class does this mean that the CLASS that represents P-101 has to be defined in our Reference Data Library with a url and unique reference ID just as we do with the CLASS CENTRIFUGAL PUMP ?
[HT] Hell no! It is simply stored in your project façade, and yes, obviously with a URI and UUID, like all data in an RDF environment. That ClassOfP101 then is a subclass of the Centrifugal Pump in the RDL.

You wrote: As I mentioned earlier in the thread I thinks this is arguable. Procurement and testing of the physical object occurs long before installation. As an example in the case of a pump the actual shop performance test data of the physical item being bought will be available long before installation.
[HT] Those activities are done to the materialized physical object that is supplied by the manufacturer. Any testing you do to an installed object (e.g. instrument loop checking) are done to the physical object that is a temporal part of both that materialized physical object and the functional physical object ("function place").

You wrote: Lets say he requires the following information
Tag Number - Normal Operating Pressure - Purchase Order Number - Purchase Status - Serial No
Clearly here we are transferring data about both the functional and physical object so when we get to P-100 does this imply we have to define both in our Part 8 file then associate the Design properties with the CLASS that represents P-100 and the Physical Properties with the Individual that represents P-100 ?
IF so does this change after installation ?
[HT] Is this mixed bag of data really what's on an Equipment List? Anyway, it starts with this subgraph of the lifecycle model: http://www.15926.info/cradle-to-grave/i ... m#purchase. The ClassOfInanimatePhysicalObject, that is the class of temporal part of both the design class and the supplier class, gives you a perfect handle for a SPARQL query that can fetch that data, valid at a given date-time.
Does that change after installation? No, why would it? The installation is a logical consequence of above dual class of temporal part.

You wrote: I was somewhat imprecise here. I am not speaking of the PID as a document but rather alluding to the objects modelled as that part of the detailed design process commonly referred to as the PID.
[HT] I still don't understand you. I've been in engineering all my life, but never referred to objects as "PID". I would guess that you mean the objects that normally are shown on a P&ID, right? If so, then all you do with a P&ID is give a graphical representation of such objects, and they way these objects are to be interconnected, but they ARE not the objects.

I hope this cleared up some.
Regards,
Hans

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

Re: Class Model

#13 Post by HansTeijgeler »

Sorry for the typo, I clicked the Submit instead of the Preview button
Hans

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

Re: Class Model

#14 Post by vvagr »

We don't have to mix this topic with general "design with classes" vs. "design with individuals" modeling question!

There are some cases where we clearly need tags as classes in design (designing a "typical project" is one of the most important cases). There are other cases when we have to do class versioning in other information management processes, for example in part catalog modeling, where we're clearly dealing with classes, not with individuals. Of course in individual plant life cycle the tag is modeled as individual.

Methodology and templates discussed here are obviously required by some modelers.

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

Re: Class Model

#15 Post by vvagr »

Hans,
[HT] Agreed, please start that new topic.
I think this new topic requires systematic changes of on the typing and relationships you are touching below. I believe you have them ready? Probable you start that, and I'll add my reasons - why it doesn't really contradicts FOL view of the standard.
[HT] I copy what the p7tm ontology, as attached to Part 8 states:

Code: Select all

    <owl:Class rdf:about="#TemplateStatement">
        <rdfs:label>TemplateStatement</rdfs:label>
        <owl:equivalentClass>
            <owl:Class>
                <owl:unionOf rdf:parseType="Collection">
                    <rdf:Description rdf:about="#BaseTemplateStatement"/>
                    <rdf:Description rdf:about="#MetaTemplateStatement"/>
                </owl:unionOf>
            </owl:Class>
        </owl:equivalentClass>
        <rdfs:comment>A template statement is an instance of a template. Example: Given a template F with signature specifying the roles R1, R2 of types, resp., T1, T2. If a and b are individuals, then F(a,b) is a template statement.</rdfs:comment>
    </owl:Class>
This does not reveal any relationship to the Part 2 data model (neither BaseTemplateStatement nor MetaTemplateStatement do that).
That's exactly what I mean. Probable we've to preserve an identity of #TemplateStatement, but add the missing statements on its relationships with data model entities.
Post 2
1. Why there is a ClassOfInformationRepresentation between hasTemplate and hasOIM role occupiers in CompositionOfOIM template definition? Is it not enough to say that Template Statement in hasTemplate role is connected to OIM by ClassOfCompositionOfIndividual?
[HT] Logically you could do that, but this solution makes explicit that a TemplateStatement is, also according Part 8, a specialization of ClassOfInformationRepresentation (and of MultidimensionalObject) and therefore can be a part of another ClassOfInformationRepresentation. The signature is the same in either case.
I don't understand this. The relationships you refer to are parts of necessary template ontology we've discussed above, but what can be the semantics of a particular Template Statement #1234 being subclass of COIR #3456? What other subclasses can be there?

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

Re: Class Model

#16 Post by HansTeijgeler »

Hi Victor,
I think this new topic requires systematic changes of on the typing and relationships you are touching below. I believe you have them ready? Probable you start that, and I'll add my reasons - why it doesn't really contradicts FOL view of the standard.
[HT] I will do that.
I don't understand this. The relationships you refer to are parts of necessary template ontology we've discussed above, but what can be the semantics of a particular Template Statement #1234 being subclass of COIR #3456? What other subclasses can be there?
[HT] You are right. I'll change the template.

Regards,
Hans

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

Re: Class Model

#17 Post by HansTeijgeler »

Hi Victor,

Here is the modified template:

Image

Regards,
Hans

glenworrall
Posts: 4
Joined: Thu May 17, 2012 10:50 am

Re: Class Model

#18 Post by glenworrall »

Hans,
I have to admit that I have a concern if you see P-101 as being part of the RDL.

When we reviewed the workflow of creating project data as classes, this meant we put a load on the modelling team of project as opposed to the design team.

As you may be aware for any design project, the creation of specifications and other base data is seen as a delay to the project, but for non-standard designs, which most projects tend to be, especially if they are joint ventures where ISO 15926 can play a larger part, then this will be seen as an unnecessary process.

Further, the loading of an RDL with project data will again place a burden on the RDL for future projects, and increase the cost of cancelling a project.

There are many scenarios where adding the project data to the RDL has an impact on the project.

I am also concerned that you may believe that a PUMP specification can be defined from day 1. Again there are projects which use a standard design where this will be possible, but there are many projects where the pump is classified as the project progresses with HAZOP reviews etc altering the requirements. Only when the specification is of sufficient quality will the vendors be approached to assign a "defined" standard to the project specification of the pump. It seems you are advocating a workflow where we can assign a defined specification from the RDL, or have I misread that also.

I hope this email triggers responses from project engineers on what they consider to be "project" data and what is determined as "reference" data.

There may be some benefits of storing the project data in the RDL (I am not sure there are any let alone many), but there are plenty of drawbacks (based on working practices of today’s projects).

Victor :
“We don't have to mix this topic with general "design with classes" vs. "design with individuals" modeling question!”
My concern is to ensure that we do not only enable “design with classes” which is what Hans is promoting. I fully understand that a manufacturer will assign a class that is a sub class of PUMP. I am not sure the design team will work that way. Further, if we promote this, then followers of ISO 15926, think that the “design as class” is best practice, when in reality “design as individual” is common practice and therefore adoption of ISO 15926 is seen as too difficult. I know as I have had this conversation.

I am all for implementing “design as class”, but after we have proven “design as individual” and therefore we hit a bigger footprint of design teams. Further “design as individual” can be utilised for the “design as class”, I am not sure the opposite is true.

Glen Worrall

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

Re: Class Model

#19 Post by HansTeijgeler »

Hi Glen,
I have to admit that I have a concern if you see P-101 as being part of the RDL.
[HT] I said "Hell no!", so how on earth can you say that P-101 is part of the RDL?
When we reviewed the workflow of creating project data as classes, this meant we put a load on the modelling team of project as opposed to the design team.
[HT] Is is neither. Once you have written a mapping add-on to your application software, you can forget about it.

All other conclusions you drew are based on misreading what I wrote.
My concern is to ensure that we do not only enable “design with classes” which is what Hans is promoting. I fully understand that a manufacturer will assign a class that is a sub class of PUMP. I am not sure the design team will work that way. Further, if we promote this, then followers of ISO 15926, think that the “design as class” is best practice, when in reality “design as individual” is common practice and therefore adoption of ISO 15926 is seen as too difficult.
[HT] The design team will use the software they always use. Where did you get the idea that engineers are supposed to populate templates?
I am all for implementing “design as class”, but after we have proven “design as individual” and therefore we hit a bigger footprint of design teams. Further “design as individual” can be utilised for the “design as class”, I am not sure the opposite is true.
[HT] I don't know what you mean with that footprint, but if you pay some attention to the example of mapping Line List data (see http://www.infowebml.ws/mapping/mapping-linelist.htm), you should agree that it isn't as bad as you think. In fact it is quite easy, once you are willing to make that paradigm shift. But by all means, I cannot stop you from wasting your time.

I suggest that we stop discussing this subject here. You get all the chance to continue the discussion one we discuss the Lifecyle Model.

Regards,
Hans

glenworrall
Posts: 4
Joined: Thu May 17, 2012 10:50 am

Re: Class Model

#20 Post by glenworrall »

Sorry Hans, I guess I am confuused. I read your statement Hell No ...

Then you wrote
That ClassOfP101 then is a subclass of the Centrifugal Pump in the RDL.
Which suggests that there is a Class P-101 in the RDL ...

Am I misreading this ?

However, I do agree that we shoudl take a better example such as the Fluid in your piping example which may have a lifecycle. I think perhaps your example of P-101 has created some mis-focus.

Locked