View unanswered posts | View active topics It is currently Mon Apr 23, 2018 9:00 pm



Reply to topic  [ 22 posts ]  Go to page Previous  1, 2, 3  Next
 TIPs revisited 
Author Message

Joined: Sun Jan 22, 2012 10:02 pm
Posts: 283
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 publications/templates/TIPs/TIP0002.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:
    :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 .

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:
   :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 .

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.


Tue Jul 29, 2014 5:58 pm
Profile

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia
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:

Quote:
T0002C(OOI, ActuatorType) ↔
ClassOfInanimatePhysicalObject(OOI) ∧
∃u(
ClassOfInanimatePhysicalObject(u) ∧
ClassOfAssemblyDefinition(OOI, u, RDS_new_0007, RDS_new_0007) ∧
SpecializationOfClassOfIndividual(u, RDS418769)) .


Tue Jul 29, 2014 11:59 pm
Profile WWW

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


Wed Jul 30, 2014 7:55 am
Profile

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia
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.


Wed Jul 30, 2014 8:03 am
Profile WWW

Joined: Sun Jan 22, 2012 10:02 pm
Posts: 283
Aha, now I see! That is indeed kind of stupid of me. It should read:

Quote:
T0002C(OOI, ActuatorType) ↔
ClassOfInanimatePhysicalObject(OOI) ∧
∃ActuatorType(
ClassOfInanimatePhysicalObject(ActuatorType) ∧
ClassOfAssemblyDefinition(OOI, ActuatorType, RDS_new_0007, RDS_new_0007) ∧
SpecializationOfClassOfIndividual(ActuatorType, RDS418769)) .


Wed Jul 30, 2014 5:17 pm
Profile

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia
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.


Wed Jul 30, 2014 5:36 pm
Profile WWW

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


Thu Jul 31, 2014 9:06 am
Profile

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia
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.


Thu Jul 31, 2014 9:26 am
Profile WWW

Joined: Sun Jan 22, 2012 10:02 pm
Posts: 283
Yes, that is what Andy said as well, and what I did in http://www.15926.org/publications/templates/TIPs/TIP0009.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 .


Thu Jul 31, 2014 11:09 am
Profile

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia
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.


Thu Jul 31, 2014 10:08 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 22 posts ]  Go to page Previous  1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
eXTReMe Tracker
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.