TIPs revisited

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

TIPs revisited

#1 Post by HansTeijgeler »

This forum page is dedicated to any feedback on the proposed enhancements on TIPs T0001 thru T0492 that will appear at http://www.15926.org/publications/templ ... /index.htm during the coming months. Please register in case you want to give this feedback.

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

TIP T0002 - Actuator Type

#2 Post by vvagr »

Hans,

It looks rather strange. You are naming ClassOfPart as ActuatorType while it is really a pattern parameter.

Should be the following:

T0002C(OOI, VAR1, ActuatorType) ↔
ClassOfInanimatePhysicalObject(OOI) ∧
SpecializationOfClassOfIndividual(http://posccaesar.org/rdl/RDS418769, VAR1) ∧
Classification(ActuatorType, http://posccaesar.org/rdl/RDS1458732011) ∧
ClassOfAssemblyDefinition(OOI, VAR1, RDS_new_0007, RDS_new_0007) ∧
SpecializationOfClassOfIndividual(VAR1, ActuatorType) .

Some remarks.

Looks like we need to bring all internal constants of the pattern to the signature. Otherwise I can not see how we will be able to deal with proliferation of parts, streams, etc. So we bring in VAR1, specialization of ACTUATOR class. And ActuatorType itself is part of the signature. We need a definition, not an example.

ActuatorType we can restrict by the ACTUATOR CLASS useful for verification. By the way, we need plain Classification template (two roles, nothing fancy) for this.

Similar story for individuals:

T0002I(x, y, ActuatorType) ↔
PhysicalObject(x) ∧
ClassificationOfIndividual(y, http://posccaesar.org/rdl/RDS418769) ∧
Classification(ActuatorType, http://posccaesar.org/rdl/RDS1458732011) ∧
AssemblyOfAnIndividual(x, y) ∧
ClassificationOfIndividual(y, ActuatorType) .

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

TIP T0001 - Tag

#3 Post by vvagr »

ExpressReal in the axiom is a mistake.

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

TIP T0002 - Actuator Type

#4 Post by HansTeijgeler »

Victor,

You are right and I was wrong, but your correction isn't right either.

The FOL listing is generic and specialized, using the top class in the Actuator hierarchy, now:

T0002C(OOI, ActuatorType) ?
ClassOfInanimatePhysicalObject(OOI) ?
?u(
ClassOfInanimatePhysicalObject(u) ?
ClassOfAssemblyDefinition(OOI, u, RDS_new_0007, RDS_new_0007) ?
SpecializationOfClassOfIndividual(u, RDS418769)) .

T0002I(OOI, ActuatorType) ?
PhysicalObject(OOI) ?
?u(
PhysicalObject(u) ?
AssemblyOfAnIndividual(OOI, u) ?
ClassificationOfIndividual(u, ActuatorType)) .


Please see the updated version here: http://www.15926.org/publications/templ ... IP0002.htm

And by the way: the template expander software does not accept URIs, as you used.

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

Re: TIPs revisited - GENERAL

#5 Post by vvagr »

One quick reply before everything else. Let's avoid existential quantifiers, bring all internal variables to the signature.

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

TIP T0001 - Tag

#6 Post by HansTeijgeler »

Why would ExpressReal in the axiom be a mistake? It is a Part 2 entity type like 200 others.

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

TIP T0001 - Tag

#7 Post by vvagr »

There is Express String in the signature. Generic tag is a string, numerical tag is just one possibility. Or I misunderstood the structure of your example?

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

Re: TIPs revisited - GENERAL

#8 Post by HansTeijgeler »

Victor
One quick reply before everything else. Let's avoid existential quantifiers, bring all internal variables to the signature.
For the uninitiated: something like ∃u() in T0002.
Before doing that we must seek buy-in from the community, because it forces us to bring the intermediate OOIs (such as the stream, or in T0002: the actuator itself) into the signature of the TIP. Andy Prosser was for it (if I understood him well): one down, x to go.

PLEASE COULD THOSE WHO HAVE AN INTEREST IN THIS MATTER SPEAK UP?

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

TIP T0001 - Tag

#9 Post by HansTeijgeler »

Victor,
The FOL code of the template ClassifiedIdentificationOfClassOfIndividual is this:

Code: Select all

ClassifiedIdentificationOfClassOfIndividual(x1, x2, x3) <->
ClassOfIndividual(x1) &
ExpressString(x2) &
ClassOfClassOfIdentification(x3) &
exists u1 exists u2(
      ClassOfIndividual(u1) &
      ClassOfTemporalWholePartTemplate(u1, x1) &
      ClassOfIdentificationTriple(u2, x2, u1) &
      ClassificationTemplate(u2, x3)) .
[/size]

Now that x2 is filled in via the upper layer of T0001:

Code: Select all

    T0001C(OOI, tag) ↔
    ClassOfInanimatePhysicalObject(OOI) ∧
    ExpressString(tag) ∧
    ClassifiedIdentificationOfClassOfIndividual(OOI, tag, RDS_new_0001) .
so the parameter "tag" = x2, by virtue of the fixed sequence of the roles.

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

Re: TIPs revisited - GENERAL

#10 Post by KeithWillshaw »

HansTeijgeler wrote:Victor
One quick reply before everything else. Let's avoid existential quantifiers, bring all internal variables to the signature.
For the uninitiated: something like ∃u() in T0002.
Before doing that we must seek buy-in from the community, because it forces us to bring the intermediate OOIs (such as the stream, or in T0002: the actuator itself) into the signature of the TIP. Andy Prosser was for it (if I understood him well): one down, x to go.

PLEASE COULD THOSE WHO HAVE AN INTEREST IN THIS MATTER SPEAK UP?
OK lets clarify the issue I am most interested in

Case for Object Of Interest PUMP P-100 :

INLET PRESSURE = 120 psig
INLET TEMPERATURE = 68 degF

What this comes down to in English terms is

The Pressure In the InletStream is 120 psig
The Temperature In the InletStream is 68 degF

So to meet the TIP requirement for these from a system that doesn't have native support for streams
I need to create an ID for the Stream and use that id for both the Temperature and Pressure. There are potentially hundreds of stream properties available so this must be robust.

I also need to be able to handle the issue where the native system DOES support streams, examples of such systems include Autoplant and Aspentech Basic Engineering (aka ZYQAD). In this case I have to be able to output real stream id's. Note human readable Stream ID's are rarely globally unique as they are generated by simulation packages in the context of a single simulation run and are often no more than a simple Stream Number (S1, S2, S3 etc)

Attached is a PDF showing a snapshot of PART of an actual stream produced from AspenPlus

Note how the component specific properties are actually arrays of properties such arrays can have any number of subscripts from 1 to several hundred. All component arrays for a given stream will have the same number of subscripts BUT values for a given subscript may be null.

Right there in Stream I have 2 showstoppers for ISO 15926

a) Null Values
b) Lists / Arrays of undetermined length

Regards Keith
Attachments
Stream.pdf
(144.97 KiB) Downloaded 597 times

Post Reply