Normal Operating Temperature

[OnnoPaap]

I have a request to Hans.

Hans would you please make an example for this case:

Line number	Normal Operating Temperature
3"-HT-1001	60 °C
6"-HT-1002	85 °C
4"-SW-90	Amb.

I ran into this example today and I was wondering how the JORD mapper should deal with it, but first what it should result in template-wise.

[HansTeijgeler]

I take the first one:
Use the template ClassOfIndirectPropertyWithPointValue

hasUrClass : 3"-HT-1001
hasPossessorType : an ICS (information carrying subclass) of 3"-HT-1001
hasDefined : the ID that is used to classify instances of the IndirectProperty relationship at the level of PossibleIndividual
hasIndirectPropertyType : the (not yet existing) ID for the ClassOfIndirectProperty named "Normal Operating Temperature" (the WIP incorrectly types this as a SinglePropertyDimension)
hasBasePropertyType : http://rdl.rdlfacade.org/data#R41192093771 "Temperature" (the JORD RDL is down)
valPointValue : 60
hasScale : http://rdl.rdlfacade.org/data#R74877992703 "Degree Celsius" (the JORD RDL is down)
hasCardinalityOfPossessorType : the (not yet existing) ID for the Cardinality of 1:* (infinity) (larger than 1 in case of more than one operational mode)

NOTE: Preferably the Normal Operating Temperature is attributed to the contained stream, not to the pipe.

[vvagr]

Hans,

Role naming conventions are very inconsistent! I'd be happy to see some uniform approach. And there is one, but it is not applied to ClassOfIndirectPropertyWithPointValue in question (and to many others).

Role names should be:

hasUrClassOfPosessor
hasPosessor

[OnnoPaap]

To Hans: The crux was the last one not the first (however interesting).
It needs modeling of the concept "ambient temperature".
The problem is with engineers using data fields for notes, but valid notes to that specific object.
Another valid value here is HOLD.

Line number	Normal Operating Temperature
28"-SW-91	HOLD

At the moment Hans is having a second knee operation (he had the first one a couple of weeks ago)
He is in the hospital.
Hang in there Hans!
So we will wait for him to return to his laptop, hopefully happy.

To Victor:
That is exactly a remark that we can make when we go through the approval cycle of the templates.

[vvagr]

Sorry for distraction. Now on topic.

HOLD should become an annotation property for incomplete template instance (with some roles missing).

Ambient temp. requires separate modelling, something like:

EXISTS x,
PropertySpace(x),
Specialization(hasSuperclass=AMBIENT TEMPERATURE, hasSubclass=x),
ClassOfIndirectProperty(hasClassOfPosessor=4"-SW-90, hasPropertySpace=x)

Though I'd say that there is a mistake in RDL, AMBIENT TEMPERATURE is more like ClassOfPropertySpace and it should be Classification.

For the simple example we can assume that all values are valid numbers. For real life the most important question is the machinery of mapping pattern selection.

I think that the problem of engineers using data fields for notes can not be solved with prevailing approach to mapping. We have a whole article on that in appendices to our TabLan mapping description.

The short summary is this: you can not describe any real mapping as a declarative data transformation. You heed a full programming language to map a data source imperatively. There you can describe something like:

Code: Select all

if DB1_table2_temperature[i] is double:
     tpl.ClassOfIndirectPropertyWithPointValue(....)
if DB1_table2_temperature[i] is string:
     if DB1_table2_temperature[i]=="Amb.":
             tpl.AmbientTemperatureAsProperty(...)
     else tpl.Annotation(....)

[HansTeijgeler]

Hi guys,

I'm back again, by the way Onno: from my first operation, the second comes in January.

To Victor:
Almost by definition one cannot be consistent on all the aspects of a template when writing some 240 of them over a period of time.
But yes, you are right, I will correct any inconsitencies on this subject of name giving.
But to some extent I have been consistent, in that using a name like your hasUrClassOfPossessor has only been used in cases where there would be a possibility for confusion. If you want all property names to be unique, then follow my suggestion to extend them with a number, such as hasUrClass067 like GMail does with names (e.g. John.Smith085@gmail.com).

To Onno:
Please don't ask catch-questions and tell me straight away what you really want to know.

To Victor:
I do think that Ambient Temperature is a Property, because I can use a thermometer to measure it. The point here is that the value cannot be entered and has to be obtained at a point of measurement. And even when there is no thermometer, the ambient temperature is of course there.
On the other hand, your suggestion of a PropertySpace is a good one, because during design we only want to indicate that the temperature is that of the air around the object, and that is, over a longer period in time, a PropertySpace. Since the definition of a ClassOfIndirectProperty is:

A <class_of_indirect_property> is a <class_of_relationship> that indicates that a member of the <class_of_individual> can possess a member of the <class_of_property> as an <indirect_property> of this type.

we see here an example of an exceptional occurance of where that "member of the <class_of_property>" is the "ambient temperature" PropertyRange that has been defined for the project site.
So, in conclusion, Ambient Temperature is, in this context, a ClassOfIndirectProperty where the hasBasePropertyType property points at the ID of the Ambient Temperature Range that you have defined for the project site.

To Onno:
The fact that engineers, and engineering programs for that matter, haven't adapted to the new era of 15926 is a pity, and their company will suffer from it when the lifecycle information has to be turned over to the owner/operator. But don't sacrifice principles for the sloppiness of others.

[vvagr]

Hans,

If you want all property names to be unique, then follow my suggestion to extend them with a number, such as hasUrClass067 like GMail does with names (e.g. [email protected]).

No! I don't want it! It will be a nightmare to parse and map. Please don't do it!

Please notice that hasPossessorType is even more confusing then hasUrClassOfPossessor.

[vvagr]

Hans,

"Ambient Temperature of 15 degrees Fahrenheit" is a Property, because you can use a thermometer to measure it.

As you say, over a longer period in time, real ambient temperatures forms a continuum, therefore design-time values of "Tag P-101 Anbient Temperature" (which is scolemized x in my FOL statement) form a PropertySpace.

That means that the best way to describe it semantically it is to go one one level higher and define "Ambient Temperature" as a ClassOfPropertySpace.

You can define it as a PropertySpace and use a specialization, this flexibility always exists at upper levels of our ontology. But one problem is a continuity. For "Tag P-101 Anbient Temperature" I can assume continuity, but for all ambient temperatures for all pieces of equipment in all possible worlds - I can not.

[HansTeijgeler]

Please notice that hasPossessorType is even more confusing then hasUrClassOfPossessor.

What you point at is a Class and Classes don't "possess" anything, their members do. I am most willing to change that to hasPossessor, but I am puzzled by your being confused.

That means that the best way to describe it semantically it is to go one one level higher and define "Ambient Temperature" as a ClassOfPropertySpace.

<<<CORRECTED>>> No quite so. Ambient Temperature is a ClassOfIndirectProperty of which the PropertySpace could be classified with a ClassOfPropertySpace, although I wouldn't know how to call the latter.

For "Tag P-101 Ambient Temperature" I can assume continuity, but for all ambient temperatures for all pieces of equipment in all possible worlds - I can not.

Is there any situation where you can assume a discontinuity in the range of the ambient temperature? For example that it changes in zero seconds from 16 to 19 degrees Celsius?

Going back to an earlier statement made by me:

we see here an example of an exceptional occurance of where that "member of the <class_of_property>" is the "ambient temperature" PropertyRange that has been defined for the project site.

I must say that this is in fact not that exceptional. The point is that, in the tradition of leaving off a lot of explicit information in documents, we leave off explicit information here as well. If we say that the design pressure is 100 barg, we leave off the tolerances within which the actual design pressure may deviate from what we specify. That +/- tolerance constitutes the PropertySpace. Unfortunately the Part 2 model does not have the means to define a mid value.
And in case we state, for example, a Maximum Allowable Working Pressure, we in fact define the upper boundary of a non-specified PropertySpace.

[vvagr]

Hans,

My mistake, I'm sorry. hasClassOfPosessor is the right name for role in question, not hasPosessor (which is wrong) or hasPosessorType (which is confusing).