TIPs revisited

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

Re: TIPs revisited

#21 Post by HansTeijgeler »

Now we have reached this point, I want to re-emphasize the need for generic patterns.
In this case these generic patterns would be ClassifiedPartOfClassOfAssembly and ClassifiedPartOfAssembly, or something like that.

ClassifiedPartOfClassOfAssembly(OOI, PartType) ↔
ClassOfInanimatePhysicalObject(OOI) ∧
ClassOfInanimatePhysicalObject(Part) ∧
ClassOfInanimatePhysicalObject(PartType) ∧
ClassOfAssemblyDefinition(OOI, Part, RDS_new_0007, RDS_new_0007) ∧
SpecializationOfClassOfIndividual(Part, PartType) ∧
SpecializationOfClassOfIndividual(PartType, RDS892484261) .

Using this information the class of part can be declared:
:C1719c380-1950-11e4-8c21-0800200c9a66 rdf:type dm:ClassOfInanimatePhysicalObject, owl:Class ;
rdfs:subClassOf rdl:RDS892484261 .

ClassifiedPartOfAssembly(OOI, PartType) ↔
PhysicalObject(OOI) ∧
PhysicalObject(Part) ∧
ClassOfInanimatePhysicalObject(PartType) ∧
AssemblyOfAnIndividual(OOI, Part) ∧
ClassificationOfIndividual(Part, PartType) ∧
SpecializationOfClassOfIndividual(PartType, RDS892484261) .

Using this information the part can be declared:
:T32e2a5f0-1950-11e4-8c21-0800200c9a66 rdf:type dm:WholeLifeIndividual, dm:PhysicalObject, rdl:RDS892484261, owl:Class .
(if the individual "can be kicked" then add: dm:ActualIndividual)

NOTE - Do NOT instantiate this generic pattern as such, because its information would be too shallow, since the part type is ISO 15926-4 INANIMATE PHYSICAL OBJECT.
Always create a specialization and use that and give it a name that can be understood by an engineer who does (or advises in) the mapping.
For example a German engineer might see: OOI-hat-einen-Stellantriebstyp(OOI,PartType)
Whether the Class version or the Individual version applies is to be determined by the applicable LifecycleActivity, which often can be derived from the originating application of which data are to be mapped.
Such specializations are locally defined and should normally not be standardized or shared as a pattern, but shared only in the form of the resulting Part 8 file.

IMPLEMENTERS: PLEASE CONCUR OR COME FORWARD WITH A BETTER SOLUTION.

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

Re: TIPs revisited

#22 Post by KeithWillshaw »

Frankly Hans I dont really understand this

Let’s take your example of Actuator Type which is a specialization of the general pattern ClassifiedPartOfClassOfAssembly
with examples such as ActuatorType, Valve Seat Type etc

Essentially in the TSP what we have is this

ObjectOfInterest (Valve) ---> Object That is the Part (Actuator) ---> ClassificationOfPart (Some subclass of Actuator)

In Plain Language what we need to do is declare an object that is the Actuator, Classify it and define an assembly relationship between Valve and Actuator

What I would expect is that we would implement this using Part7 Templates as shown in the Tip mapping

So there would be a declaration for the Actuator

A ClassificationOfIndividual Template would be instantiated for the actuator

Role
No Role Name Role Type Example
1 hasClassified PossibleIndividual Generated ID for Actuator e.g. (act123)
2 hasClassifier ClassOfIndividual Subclass of ACTUATOR e.g. http://posccaesar.org/rdl/RDS6594493

An AssemblyOfOndividual Template would be instantiated for the Assembly

Role
No Role Name Role Type Example
1 hasWhole PossibleIndividual ID of Valve e.g. PCV-100
2 hasPart PossibleIndividual ID of Actuator (act 123)

The real trick is going to be recognising the fact that an actuator has already been instantiated
if we get another tip that refers to it such as ActuatorTag

I have deliberately avoided using Part8/OWL as the reality is that although Bentley are concentrating on it I know
that not all implementations will do so. There are TIP’s users that today use DTO and others who will prefer Proteus II


Regards Keith

Post Reply