Models for Models (OIMs)

Post Reply
Message
Author
Pavel Selchukov
Posts: 12
Joined: Tue May 15, 2012 7:06 am

Models for Models (OIMs)

#1 Post by Pavel Selchukov »

The problem that we are trying to solve is OIM management.

Example. We have two separate models PIPELINE VALVE OIM (1.jpg) and PIPING SYSTEM OIM (2.jpg).

As in http://www.15926.org/publications/gener ... /index.htm proposed we use a Classification relationship between model (ESOC) and its members.

Lets try to suppose that we want to use in PIPELINE VALVE OIM some components of PIPING SYSTEM OIM. So we have a relationship between PIPELINE VALVE NOZZLE and PIPING POINT (3.jpg).

The Question - is new relationship an object of both OIMs?

Next case - uniting of OIMs. We have to unite two OIMs to third OIM (4.jpg).

The Question - what types of relationships are between OIM 1, OIM2, OIM3 and between objects of these OIMS?

Any thoughts?
Attachments
1.jpg
1.jpg (32.82 KiB) Viewed 14971 times
2.jpg
2.jpg (16.27 KiB) Viewed 14971 times
3.jpg
3.jpg (28.05 KiB) Viewed 14971 times
4.jpg
4.jpg (35.39 KiB) Viewed 14971 times

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

Re: Models for Models (OIMs)

#2 Post by OnnoPaap »

I would suggest to have the OIMs all separated.
One for Pipeline valve, one for valve body, one for valve case, etc.
That way it is much better manageable.

Then I would suggest to have the template ClassOfDirectConnectionDefinition for the connection relationship. The same template to be mentioned in the OIM of each end.

Between the class OIMs is an class of assembly definition relationship see ClassOfAssemblyDefinition. Because it is a class relationship there are cardinalities involved.

See, I think we need to work with templates in OIMs, otherwise we keep simplifying the models what would be incorrect.

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

Re: Models for Models (OIMs)

#3 Post by vvagr »

According to the proposal at http://www.15926.org/publications/gener ... /index.htm classes like PIPELINE VALVE or NOZZLE PIPING POINT can not be called "OIM components". Real OIM components are "temporary" subclasses of a special set of UrClasses, which are in turn subclasses of generic PIPING SYSTEM, PIPELINE VALVE NOZZLE, PIPING POINT. They all are classes of individuals, of course.

Relationships, classes of relationships between these "temporary subclasses", or template instances involving them -- are not "members" or "components" of OIM (in the sense of definition discussed). Relationships or template instances are extracted from your storage based on the "temporary" classes of individuals registered as members of OIM.

Therefore merge of two OIMs is not a problem - you just combine two sets of "temporary" classes (of individuals!), if you are sure that they are from the same temporary state of your design process. If you have correctly determined time stamps - you will successfully extract all relevant relationships or template instances between members of an united OIM.

Logically it is nice solution, but search for relationships or template instances where at least one role is occupied by a member of a given ESOC can be very difficult and time consuming task for practical realisation. Therefore it will be probable necessary to do what Pavel has in mind - somehow bring together member relationships and template instances of the OIM. The problem is, as we've identified before, with template instances. We've to rely on metadata (annotation properties) here, as we can not use data structures (Part 2 ontology).

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

Re: Models for Models (OIMs)

#4 Post by vvagr »

If we understand Hans proposal verbatim, it is also worth to notice that each OIM ESOC consists from information about one and only one item of the system. It is not correct to say that several elements of a pipeline are elements of an OIM1.

This restriction looks unnecessary to me, an approach can be easily extended to include sets of elements in one OIM.

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

Re: Models for Models (OIMs)

#5 Post by HansTeijgeler »

Hi Pavel,

Please attach a better copy of your jpg files. I can't read them.

Regards,
Hans

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

Re: Models for Models (OIMs)

#6 Post by Pavel Selchukov »

Here are diagrams of better quality.
Attachments
1.jpg
1.jpg (85.93 KiB) Viewed 14956 times
2.jpg
2.jpg (44.4 KiB) Viewed 14956 times
3.jpg
3.jpg (69.65 KiB) Viewed 14956 times
4.jpg
4.jpg (90.83 KiB) Viewed 14956 times

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

Re: Models for Models (OIMs)

#7 Post by Pavel Selchukov »

Hans, please, just say that Victor understands your conception correctly and we have another cycle of deprivation of part2 Class of Relationship.

Victor, please, if merging of these two OIMs is not a problem for you, could you propose a 15926 diagram that illustrate that? I just hope you don't propose just to collect all elements (members) of OIM1 and OIM2 into OIM3:)

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

Re: Models for Models (OIMs)

#8 Post by vvagr »

Pavel, the deprivation of part2 Class of Relationship happened some years ago - with the introduction of templates. Relationships can regain their place though - once we learn to work with data expanded from templates.

As I've mentioned in my second comment to this thread, merging of OIMs in the original Hans proposal has no sense at all - an OIM is an information model of a single object by definition.

It is possible to extend original proposal to include in OIM information about several objects. In this case merge will be indeed done by collecting all elements (members) of OIM1 and OIM2 into OIM3. With timestamp metadata checks, of course.

What problems you can see in that?

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

Re: Models for Models (OIMs)

#9 Post by HansTeijgeler »

Hi Pavel and Victor,

I was a bit puzzled by your "deprivation" for which Google Translate gives the following (near)-synonyms: robbery, mugging, privation, spoliation, dispossession, loss, waste, cost, bereavement, disadvantage, dismay, shock, abnegation, nightmare, deposition, deposit, and removal.

But I understand from it that you love the ClassOfRelationship. If you look through the templates for class (http://www.15926.org/15926_template_spe ... 6f712ac8b) you will see that I used subtypes of ClassOfRelationship all over the place in those templates.

The paths that are shown on the diagrams of Pavel are a kind of configuration paths, with composition and connection templates. Each object has its information, including these composition and connection templates, in the form of one or more OIMs of that object. The links between these information clouds are indeed those composition and connection templates, because they are a part of the OIM at each side.

If you want you could even define OIMs (ESOCs (EnumeratedSetOfClass)) of which other OIMs are a part, but that brings us at (or over) the limits of the model since you would have to classify a ClassOfClass with another ClassOfClass. Sounds gloomy to me. Composition is not possible, because that only can be used for ClassOfIndividual and its subtypes.

A possible way of handling combinations of OIMs would be to define a union of the applicable "OIM holder" classes, using the template UnionOf2Classes (http://www.15926.org/templatespecs/CL-C ... 1346800323). If more than two, we need to make a template for that. That is not much work.

I think it is better to navigate from one OIM to the other via template instances that they have in common.

So far my two cents of wisdom. :)

Regards,
Hans

Post Reply