TIPs revisited

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

Re: TIPs revisited

#11 Post by HansTeijgeler »

Keith,

This will need some time, because you put forward big issues, but not about the question we had in this thread: Would Bentley oppose a situation in which the intermediate OOIs, like stream, would be in the signature of the TIP, together with those "parameters". Please let us know.

This does not mean that I try to escape from your questions. :-)

As you can see from http://www.15926.org/publications/templ ... IP0002.htm the use of an existential quantifier ∃u means that any intermediate OOI has to be declared automatically by the mapping software.

For your INLET PRESSURE = 120 psig that could be:

Code: Select all

    :C525306c0-1746-11e4-8c21-0800200c9a66 rdf:type dm:ClassOfInanimatePhysicalObject, owl:Class ;
        rdfs:subClassOf rdl:RDS398549 ; # fake ID for ISO 15926-4 STREAM CLASS
        meta:valEffectiveDate "2014-07-10T00:00:00Z"^^xsd:dateTime .
[/size]
That shouldn't be too difficult, since all ingredients are there. Then you do have your stream, that you may or may not give a tag. If not, you use the UUID (or something else). You, or we, might add a rule for the generation of a template that tells, in the case of your INLET PRESSURE, that the stream at the relative location of the inlet port is meant. Something like:

Code: Select all

	:T525306c1-1746-11e4-8c21-0800200c9a66 rdf:type tpl:ClassOfRelativeLocationDefinition, owl:Thing ;
		skos:prefLabel "A member of CO_P-11100A_S is contained in a member of CO_P-11100A." ;
		tpl:hasClassOfLocated :C525306c0-1746-11e4-8c21-0800200c9a66 ; # above declared stream class
		tpl:hasClassOfLocator :CO_P-11100A-INLETPORT ;
		tpl:hasLocationType rdl:RDS459835 ; # fake ID for UPSTREAM
		tpl:hasCardinalityOfLocated rdl:RDS_new_007 ; # 1:1
		tpl:hasCardinalityOfLocator rdl:RDS_new_007 ; # 1:1
		meta:hasLifecycleActivity rdl:RDS9704537 ; # MECHANICAL ENGINEERING
		meta:valEffectiveDate "2014-05-28T11:25:00+00:00"^^xsd:dateTime .
[/size]
The use of ports is another story, that we have to finish, one way or the other.

Your task would be to remember that relationship, because when INLET TEMPERATURE = 68 degF comes along, you better use the above, rather than creating duplicates. NOTE - The stream at the outlet is a different thing, with its own UUID. These IDs are immutable, all time-related stuff sits inside the template instances.

Let us discuss the other stuff: 1) Lists and arrays, and 2) NULL values, from your posting in separate topics. I will take the action.

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

TIP T0002 - Actuator Type

#12 Post by vvagr »

Hans,

Concerning Actuator Type - what is wrong in my definition? ActuatorType which is a target of this TIP is a member of RDL entity ACTUATOR CLASS.

And you've lost ActuatorType from your new definition completely:
T0002C(OOI, ActuatorType) ↔
ClassOfInanimatePhysicalObject(OOI) ∧
∃u(
ClassOfInanimatePhysicalObject(u) ∧
ClassOfAssemblyDefinition(OOI, u, RDS_new_0007, RDS_new_0007) ∧
SpecializationOfClassOfIndividual(u, RDS418769)) .

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

Re: TIPs revisited

#13 Post by HansTeijgeler »

Victor,

It is interesting that you say that Acuator Type is the "target" (whatever is meant with that) of this TIP. It shows how ill-defined TIPs are, because to me that target is the actuated device (e.g. control valve), with as a second possibility the actuator itself. The "parameter" Actuator Type tells what type of actuator the latter is, or what type of actuator the actuated device has.

Furthermore we deal here with ACTUATOR and its subclasses, not with ACTUATOR CLASS which is a ClassOfClass that has been put in the RDL for some unclear reason.

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

Re: TIPs revisited

#14 Post by vvagr »

Hans,

Forgive my poor English. I should have said something like that "Assignment of the Actuator type is the goal of this TIP".

Nevertheless I can not explain why AcuatorType is now missing from your TIP definition. It is in the signature, but it is absent from statements in the expansion.

ACTUATOR CLASS is exactly the ClassOfClass required to express restriction on the entity occupying the AcuatorType role of the TIP. If we add the statement

Classification(ActuatorType, http://posccaesar.org/rdl/RDS1458732011)

we make semantics of the pattern explicit and allow for data verification and pattern search in data received.

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

Re: TIPs revisited

#15 Post by HansTeijgeler »

Aha, now I see! That is indeed kind of stupid of me. It should read:
T0002C(OOI, ActuatorType) ↔
ClassOfInanimatePhysicalObject(OOI) ∧
∃ActuatorType(
ClassOfInanimatePhysicalObject(ActuatorType) ∧
ClassOfAssemblyDefinition(OOI, ActuatorType, RDS_new_0007, RDS_new_0007) ∧
SpecializationOfClassOfIndividual(ActuatorType, RDS418769)) .

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

Re: TIPs revisited

#16 Post by vvagr »

No, you do not need ∃ActuatorType if ActuatorType is explicit in the signature.

Let's start from the beginning. ActuatorType is an RDL class referred in the signature. And we need an element (scolem constant) which represents actuator of our OOI, therefore part of OOI, specialization of ACTUATOR and specialization of an ActuatorType. I've called it VAR1.

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

Re: TIPs revisited

#17 Post by HansTeijgeler »

Yep:

T0002C(OOI, ActuatorType) ↔
ClassOfInanimatePhysicalObject(OOI) ∧
ClassOfInanimatePhysicalObject(Actuator) ∧
ClassOfInanimatePhysicalObject(ActuatorType) ∧
ClassOfAssemblyDefinition(OOI, Actuator, RDS_new_0007, RDS_new_0007) ∧
SpecializationOfClassOfIndividual(Actuator, ActuatorType) ∧
SpecializationOfClassOfIndividual(ActuatorType, RDS418769)) .

T0002I(OOI, ActuatorType) ↔
PhysicalObject(OOI) ∧
PhysicalObject(Actuator) ∧
ClassOfInanimatePhysicalObject(ActuatorType) ∧
AssemblyOfAnIndividual(OOI, Actuator) ∧
ClassificationOfIndividual(Actuator, ActuatorType) ∧
SpecializationOfClassOfIndividual(ActuatorType, RDS418769)) .

Now better?

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

Re: TIPs revisited

#18 Post by vvagr »

Hans,

Much better :-)

Now let's return to the signature. If we add Actuator to the signature of the pattern, we'll be able to combine basic TIPs about actuator (ActuatorType, ActuatorSeismicClass, do not know what else can be required) in such a way thet mapping will generate only one actuator, not a single one for each TIP used.

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

Re: TIPs revisited

#19 Post by HansTeijgeler »

Yes, that is what Andy said as well, and what I did in http://www.15926.org/publications/templ ... IP0009.htm.

But that means that those extra OOIs, that are not represented in the source software, have to be generated in some way, and that seems to be the problem.

Any OOI could, in an RDF environment, be declared using the information about it in the FOL listing:

T0002C(OOI, ActuatorType) ↔
ClassOfInanimatePhysicalObject(OOI) ∧
ClassOfInanimatePhysicalObject(Actuator)
ClassOfInanimatePhysicalObject(ActuatorType) ∧
ClassOfAssemblyDefinition(OOI, Actuator, RDS_new_0007, RDS_new_0007) ∧
SpecializationOfClassOfIndividual(Actuator, ActuatorType) ∧
SpecializationOfClassOfIndividual(ActuatorType, RDS418769)) .

:C1719c380-1950-11e4-8c21-0800200c9a66 rdf:type dm:ClassOfInanimatePhysicalObject, owl:Class ;
rdfs:subClassOf rdl:RDS418769 .

T0002I(OOI, ActuatorType) ↔
PhysicalObject(OOI) ∧
PhysicalObject(Actuator)
ClassOfInanimatePhysicalObject(ActuatorType) ∧
AssemblyOfAnIndividual(OOI, Actuator) ∧
ClassificationOfIndividual(Actuator, ActuatorType) ∧
SpecializationOfClassOfIndividual(ActuatorType, RDS418769)) .

:T32e2a5f0-1950-11e4-8c21-0800200c9a66 rdf:type dm:PhysicalObject, rdl:RDS418769. owl:Class .

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

Re: TIPs revisited

#20 Post by vvagr »

Yes, they have to be generated and they should be generated in any case - if we don't instantiate TIP as a single template but instantiate all templates it consists of.

If we combine several TIPs in a single pattern describing data model of a native application - signature with all scolem constants declared explicitly is a way to avoid duplication of parts, streams and the like.

As for the creation of data - if in some system actuator really exists, then just simple check for duplicates in the maping engine will be enough.

Post Reply