Nullifying Values in Part7/8

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

Re: Nullifying Values in Part7/8

#11 Post by KeithWillshaw »

This issue was discussed in the Part8 Implementation Meeting on 30-7-2013 and the following options were discussed

1) Add a Status Role to existing Property Templates

Pros
Relatively Simple
Status values could be any Class Of Status

Cons
Only one value Status may be specified per property

2) Add a persistent identity to the Property and then have a separate PropertyStatus Template

Pros
Permits multiple Status per property e.g. Set by Designer and Approved For Construction and Reviewed By Client
Allow Audit Trail Metadata to be added

Cons
Requires Property to be identified by ID before writing to OWL/Endpoint
and could have performance issues

Robin Benjamins added a set of Powerpoint Slides which are attached
in Powerpoint and PDF format

Regards

Keith
Attachments
Property Status Recommendations.pdf
(300.67 KiB) Downloaded 812 times
Property Status Recommendations.pptx
(181.72 KiB) Downloaded 879 times

Andrew.Prosser

Re: Nullifying Values in Part7/8

#12 Post by Andrew.Prosser »

ok so we need some movement on this one. To properly relate status such as null or lifecycle information do we need properties to have identities?? If so it has far reaching impications on the proposed template set and current developments. Can we please continue this discussion and back it up in the other discussions with supporting template alterations and examples?? or can we progress agreed/working examples for null representation via another means??

thanks

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

Re: Nullifying Values in Part7/8

#13 Post by HansTeijgeler »

One other way to status information in general is to do that with a meta property meta:informationStatus of the template instance, with an instance of dm:Status as role filler.

Don't forget that a template is an instance of ClassOfInformationRepresentation + MultidimensionalObject.

So if we qualify that information, represented by that template instance, we have basically covered the statusing of all information in an optional, non-intrusive, manner.

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

Re: Nullifying Values in Part7/8

#14 Post by KeithWillshaw »

Andrew.Prosser wrote:ok so we need some movement on this one. To properly relate status such as null or lifecycle information do we need properties to have identities?? If so it has far reaching impications on the proposed template set and current developments. Can we please continue this discussion and back it up in the other discussions with supporting template alterations and examples?? or can we progress agreed/working examples for null representation via another means??

thanks
Thanks for raising this again Andrew, its very timely as the same issue has been raised in both HEED and EDRC meetings where it has become clear that we need to able to include status for Objects and properties and LifeCycle information beyond a simplistic Design/Materialization level

The basic support for this IS available in Part 2 in the form of

CLASS OF LIFECYCLE STAGE
A <class_of_lifecycle_stage> is a <class_of_relationship> whose members are members of <lifecycle_stage>.
EXAMPLE Planned, required, expected, and proposed can be represented by instances of <class_of_lifecycle_stage>.

The RDL already has some entries such as
AS FOUND
AS LAID
AS BUILT

and

CLASS OF STATUS
A <class_of_status> is a <class_of_class_of_individual> whose members are a <status>.
EXAMPLE An example of <class_of_status> is approval, with members: not assessed, approved, rejected.

Examples in the RDL include
DESIGN STATE
NOMINAL STATE
OPERATING STATE

Without these issues being addressed I really don't see how we can progress byond simple data transfers.

Keith

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

Re: Nullifying Values in Part7/8

#15 Post by vvagr »

Adding any kind of qualification by any means to the template instance will not help you with the basic fact -- template instance with a missing role is not a valid predicate under the P7 and can not be expanded. So there are no need for special meta property - verification code can find all template instances with missing roles and it will be obvious that they are incomplete.

If we want to move further - we need more specific requirements. In which specific cases data may be incomplete? "Found wrong", "Missing", "Delayed" - something like this. Then we've to decide whether we need a way to express the situations like "out of 5 roles one is Missing and another is Delayed". If yes - we need more elaborate way to express such situations.

But I think the best approach is the following. Let's keep template set simple - so that there will be no reason to have a template instantiated with some roles missing. Then we can define complex n-ary structures (with many relatively independent parameters) not as templates but as patterns. Patterns have no strict FOL semantics. Therefore pattern parameters can be optional. If pattern has to be expanded to templates (according to mapping) -- only fully defined templates will be instantiated, and incomplete ones - omitted.

Rule-based patterns will be even more powerful for this purpose. We can define:

IdentificationPattern(Object, Id, Context)

If Context is defined - it is expanded into ClassifiedIdentificationTemplate
If Context is missing - it is expanded into IdentificationTemplate

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

Re: Nullifying Values in Part7/8

#16 Post by HansTeijgeler »

I may have missed the point, but from the posting of Keith I got the impression that he was talking about the quality of the information.

I'll give an example from the engineering practice: Power cables have to be ordered early, because they will be in underground trenches, and these are finished as early as possible so that the rest of construction is not hindered by open trenches.

But the motors have not been finally specified at that time. So the equipment engineers give the electrical folks their best estimate of a HP rating, on the basis of which the cables are being ordered. Later their definitive HP rating is defined and marked as such.

Or another example: when you start a revamp, you (may) get all sorts of data from the plant owner. You better mark these as such, since the actual values may appear later. In the case of disputes you always have the information about the data set that you received.

I wonder why blank data are so important. They are non-information.

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

Re: Nullifying Values in Part7/8

#17 Post by KeithWillshaw »

HansTeijgeler wrote:I may have missed the point, but from the posting of Keith I got the impression that he was talking about the quality of the information.

I'll give an example from the engineering practice: Power cables have to be ordered early, because they will be in underground trenches, and these are finished as early as possible so that the rest of construction is not hindered by open trenches.

But the motors have not been finally specified at that time. So the equipment engineers give the electrical folks their best estimate of a HP rating, on the basis of which the cables are being ordered. Later their definitive HP rating is defined and marked as such.

Or another example: when you start a revamp, you (may) get all sorts of data from the plant owner. You better mark these as such, since the actual values may appear later. In the case of disputes you always have the information about the data set that you received.

I wonder why blank data are so important. They are non-information.
This is a very real and important issue. Consider the following use case

Retracting erroneous data
1) Data is published indicating that the max working pressure for a pump is 10.2 bar
2) It is discovered that this is incorrect but the correct value is unknown

I need a way to indicate that the value published was wrong

In Relational database systems this is achieved by allowing the use of null in a table

Keith

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

Re: Nullifying Values in Part7/8

#18 Post by KeithWillshaw »

vvagr wrote:Adding any kind of qualification by any means to the template instance will not help you with the basic fact -- template instance with a missing role is not a valid predicate under the P7 and can not be expanded. So there are no need for special meta property - verification code can find all template instances with missing roles and it will be obvious that they are incomplete.

If we want to move further - we need more specific requirements. In which specific cases data may be incomplete? "Found wrong", "Missing", "Delayed" - something like this. Then we've to decide whether we need a way to express the situations like "out of 5 roles one is Missing and another is Delayed". If yes - we need more elaborate way to express such situations.

But I think the best approach is the following. Let's keep template set simple - so that there will be no reason to have a template instantiated with some roles missing. Then we can define complex n-ary structures (with many relatively independent parameters) not as templates but as patterns. Patterns have no strict FOL semantics. Therefore pattern parameters can be optional. If pattern has to be expanded to templates (according to mapping) -- only fully defined templates will be instantiated, and incomplete ones - omitted.

Rule-based patterns will be even more powerful for this purpose. We can define:

IdentificationPattern(Object, Id, Context)

If Context is defined - it is expanded into ClassifiedIdentificationTemplate
If Context is missing - it is expanded into IdentificationTemplate
What I think you are addressing is a separate issue I have mentioned previously. Its common in engineering applications to allocate a Status to a property or individual such as 'Preliminary', 'Approved' , 'As Built' . This is very important as it allows sensible project decisions to be made such as not purchasing a Pump on the basis of 'Preliminary' information

Keith

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

Re: Nullifying Values in Part7/8

#19 Post by HansTeijgeler »

Keith,
Retracting erroneous data
1) Data is published indicating that the max working pressure for a pump is 10.2 bar
2) It is discovered that this is incorrect but the correct value is unknown

I need a way to indicate that the value published was wrong

In Relational database systems this is achieved by allowing the use of null in a table
That is one of the essential features of 15926: temporal parts (or class of temporal part when you deal with classes).

If, to stay with your example, the max. working pressure of:

* P-101 (the function place) has been 10.2 bar as defined for the requirements class CO_P-101, you attribute:
- the classification of P-101 with that changed requirements class to a temporal part of P-101 (usually when you publish the next formal revision/version of that class)
- the change in the requirements class CO_P-101 to a class of temporal part of CO_P-101 (using http://www.15926.org/templatespecs/CL-INDPTY-03.xml)

* myPump (as installed) has been determined to have been 10.2 bar during last night's shift you assign that to a temporal part of myPump that existed from the beginning to the end of last night's shift, and you start a new temporal part the next morning for a new value (to be determined from the DCS Historian time series of that pressure during that day shift) (using http://www.15926.org/templatespecs/TP-INDPTY-02.xml).

See for example here: http://www.15926.org/publications/SPARQL/index.htm#0050 where the VOLUME FLOW RATE of CO_RZ17801-S has changed from 8.55 to 9.3 m3/hr on 2013-09-29T00:00:00Z. This is what makes it lifecycle information. ALL information, represented with templates, is placed in time, from the beginning of its validity to the end of that validity.

Finally this: it so happens from time to time that you have an oops experience, i.e. the data entered was wrong from the very beginning. Then you end the temporal part to which this data was attributed at the same dateTime as it began, or in case of a class you deprecate the template at the same dateTime as its valEffectiveDate.

OnnoPaap
Posts: 189
Joined: Sun Jan 22, 2012 9:14 pm

Re: Nullifying Values in Part7/8

#20 Post by OnnoPaap »

Hans, could you post some little diagrams showing the changed class classifying the function place? I think this is the crux of the life-cycle information.

Post Reply