How to model LISTs?
Posted: Wed Dec 04, 2013 2:02 pm
This topic starts with an unfinished discussion that popped up during a totally different discussion.
Please continue it here.
========================================================================
KEITH WILLSHAW wrote on 2013-12-03:
This does not appear to provide any way forward with the REAL hole in the current Part7/8 implementation which is the handling of lists. The real world is FULL of list data, in the engineering world we base many key documents on lists. We start at the simulation with lists of components in a stream, progress to equipment and instrument lists in preliminary design to complex multidimensional lists on things like pump curves and heating and cooling curves at the detailed design phase and end up with spares lists in the operations and maintenance field.
__________________________________________________________________________________________________________________________________
MATTHEW WEST wrote on 2013-12-03:
Dear Keith,
I’m not sure why lists should be a particular problem. In general, they will be the result of a query. For example, for the components of a mixture, you have a (class of) relationship between the mixture (physical_object) and a particular molecular component (class_of_molecule), say class_of_component_of_mixture, and you make that relationship for the relevant class_of_molecule. Retrieving the list is then a simple query of which class_of_molecule have that class_of_relationship to the particular mixture in question.
I would expect a similar approach for other lists.
Am I missing something?
__________________________________________________________________________________________________________________________________
HANS TEIJGELER wrote on 2013-12-03:
You are mistaken there as far as ISO 15926 is concerned. You can use the MultidimensionalObject for that, as is done in Part 2 where we have multidimensional_number, multidimensional_number_space
multidimensional_property, multidimensional_property_space, and multidimensional_scale. It is OWL that does not know the List construct. Anyway, as Matthew indicated in his response to you, there are ways to model that without a list. But I would even toss up the idea to simply use the MultidimensonalObject + a classifying ClassOfMultidimensonalObject for that. Just give me a random example.
__________________________________________________________________________________________________________________________________
KEITH WILLSHAW wrote on 2013-12-03:
Please note that I did not say that 15926 cannot handle lists, my point was that Part7 and Part 8 do not do so. I am well aware of the MultiDimensional Object as for OWL not handling lists I am aware that the standard ontology does not support ordering because it used the rdf:list for its own serialization
This does not however make the business need to store list data go away.
As for examples here are a few simple ones:
Others have been doing some work on these issues e.g.
Nicholas Drummond, Alan Rector, Robert Stevens, Georgina Moulton, Matthew Horridge, Hai Wang and Julian Sedenberg (2006). Putting OWL in Order: Patterns for sequences in OWL. OWL Experiences and Directions (OWLED 2006), Athens, Georgia, USA.
__________________________________________________________________________________________________________________________________
MATTHEW WEST wrote on 2013-12-03:
Dear Keith,
MW: I’m going to keep pushing back on the need for ordered lists, until I see a real requirement. So let’s start where you finished:
KW: Now some of these can be retrieved by a series of queries but handling the complex of relationships generated when we are dealing with lists of hundreds
or even thousands of ordered Things is a nightmare.
MW: I dispute that there is anything particularly complex here. If you have modelled the data correctly, there should be a single relation to query in each case to select the data, and then the same or another one to determine the order for display. This is what computers are supposed to be good at!
KW:
As for examples here are a few simple ones:
- List of Piping Components in Piping Network Segment
[MW>] Use the composition relation to discover which components are part of the PNS, then presumably order them by the order they are connected by the pipework from end to end.
- List of Compounds and Mole Fraction for each in a fluid stream
[MW>] Use the relation between stream and instance of class_of_molecule to determine the list of components. You probably want to order by size of the mole fraction (which might change from simulation to simulation, so I really would not want a defined list here).
- List of Points in a Curve or Polyline
[MW>] Use composition to get the members, use connection to order them.
- List of Cable Tray/Rack support points used to define a cable route
[MW>] Use composition and connection again.
- List of geometric primitives in a symbol
[MW>] Why does the order matter?
- List of matched Properties on a heat exchanger heating/cooling curve
[MW>] Obtain members of curve, order by size along a chosen axis.
MW: The danger of using a list in these cases (and especially instead of the underlying relationships) is that you risk losing or confusing the underlying meaning.
KW: Now some of these can be retrieved by a series of queries but handling the complex of relationships generated when we are dealing with lists of hundreds or even thousands of ordered Things is a nightmare.
[MW>] It should only be a nightmare if you have to deal with hundreds or thousands of different types of relation. Hundreds or thousands of one or two types of relation should be straight forward.
Further, if you really have lists of hundreds or thousands, they are not very useful for users in that form. More likely their real requirement is to find particular things in that list – better to support that need directly, rather than make them search manually within a list that you have ordered in a particular way.
__________________________________________________________________________________________________________________________________
HANS TEIJGELER wrote on 2013-12-03:
Apparently Matthew West couldn't convinve you. I agree with Matthew, but on the other hand I can see your requirement for some kind of a shortcut. Take the segments and inline components that are bounding such line segments, such as orifice plate assemblies, control valves, etc. I am borrowing a sketch made by Duhwan Mun:
Let's say that Line RZ17801 has three components:
- line segment RZ17801-4-S1 in the role of hasFirst
- control valve LV-101 in the role of hasSecond
- line segment RZ17801-4-S2 in the role of hasThird.
You could think of a template that has a signature with three predicates:
- hasFirst ClassOfInanimatePhysicalObject
- hasSecond ClassOfInanimatePhysicalObject
- hasThird ClassOfInanimatePhysicalObject
and voilá, you have your list. Or is that too simple?
If anything changes there, you will have to redo the entire list, that's the only consequence. As such that could be an advantage in case of snapshot updates of entire P&IDs, where you replace entire lines with all their segments and other components. That makes finding out what is new and what a replacement much easier (IFF the P&ID software remembers the UUIDs !).
__________________________________________________________________________________________________________________________________
KEITH WILLSHAW wrote on 2013-12-04:
This is a very simplistic example. The reality is that I don’t know how many components will be in a segment ahead of time. I only know there will be 1 to n.
Note that in your example what we would actually show for would be a single PipingNetworkSegment from Nozzle N1 to the Reducer outlet with an inserted Valve and a Reducer. Typically the line segments you show are actually dynamically generated i.e. when the valve is inserted what was one line segment becomes 2 line segments.
As such they would not have a persisted ID whereas the Valve and Reducer along with other piping components would. In fact in some systems the line segments do not actually exist in the database, they are implied as existing between ordered piping components. They have no intrinsic business value being simply a graphical representation of connectivity.
Since I cannot have a template with empty roles in order to go down the route you suggest I would have to have a large number of templates with numbers of predicates ranging from 1 to n and them pick the correct template at run time. Since they have different numbers of roles they are not of course simply specializations.
An ordered list is just a much simpler and more elegant solution. Part2 gives us the means to handle this in the form of the MultiDimensionalObject which as I am sure you know is defined as follows
“A <multidimensional_object> is an <abstract_object> that is an ordered list of <thing>. The significance of the <multidimensional_object> is determined by being a member of a <class_of_multidimensional_object> that indicates the role played by each of its elements.”
As I mentioned in my earlier post this is a relatively simple example. When we get into handling Stream Cases and we have multiple ordered lists of properties or Pump curves we have more complex cases.
This is in fact exactly the basis for the definition of MultiDimensionalProperty in Part2
“A <multidimensional_property> is a <property> that is also a <multidimensional_object>.
EXAMPLE A pump flow head characteristic is a multidimensional object. It consists of a continuum of Q, H property pairs, where Q is the flow rate and H is the flowing head difference. Each pair of properties Qa and Ha, where Qa is a particular flow rate and Ha a particular head, is a multidimensional property [Qa, Ha].”
It does not seem unreasonable to me to ask for a means of implementing these fundamental constructs instead of fudging it some other way.
__________________________________________________________________________________________________________________________________
Please continue it here.
========================================================================
KEITH WILLSHAW wrote on 2013-12-03:
This does not appear to provide any way forward with the REAL hole in the current Part7/8 implementation which is the handling of lists. The real world is FULL of list data, in the engineering world we base many key documents on lists. We start at the simulation with lists of components in a stream, progress to equipment and instrument lists in preliminary design to complex multidimensional lists on things like pump curves and heating and cooling curves at the detailed design phase and end up with spares lists in the operations and maintenance field.
__________________________________________________________________________________________________________________________________
MATTHEW WEST wrote on 2013-12-03:
Dear Keith,
I’m not sure why lists should be a particular problem. In general, they will be the result of a query. For example, for the components of a mixture, you have a (class of) relationship between the mixture (physical_object) and a particular molecular component (class_of_molecule), say class_of_component_of_mixture, and you make that relationship for the relevant class_of_molecule. Retrieving the list is then a simple query of which class_of_molecule have that class_of_relationship to the particular mixture in question.
I would expect a similar approach for other lists.
Am I missing something?
__________________________________________________________________________________________________________________________________
HANS TEIJGELER wrote on 2013-12-03:
You are mistaken there as far as ISO 15926 is concerned. You can use the MultidimensionalObject for that, as is done in Part 2 where we have multidimensional_number, multidimensional_number_space
multidimensional_property, multidimensional_property_space, and multidimensional_scale. It is OWL that does not know the List construct. Anyway, as Matthew indicated in his response to you, there are ways to model that without a list. But I would even toss up the idea to simply use the MultidimensonalObject + a classifying ClassOfMultidimensonalObject for that. Just give me a random example.
__________________________________________________________________________________________________________________________________
KEITH WILLSHAW wrote on 2013-12-03:
Please note that I did not say that 15926 cannot handle lists, my point was that Part7 and Part 8 do not do so. I am well aware of the MultiDimensional Object as for OWL not handling lists I am aware that the standard ontology does not support ordering because it used the rdf:list for its own serialization
This does not however make the business need to store list data go away.
As for examples here are a few simple ones:
- List of Piping Components in Piping Network Segment
List of Compounds and Mole Fraction for each in a fluid stream
List of Points in a Curve or Polyline
List of Cable Tray/Rack support points used to define a cable route
List of geometric primitives in a symbol
List of matched Properties on a heat exchanger heating/cooling curve
Others have been doing some work on these issues e.g.
Nicholas Drummond, Alan Rector, Robert Stevens, Georgina Moulton, Matthew Horridge, Hai Wang and Julian Sedenberg (2006). Putting OWL in Order: Patterns for sequences in OWL. OWL Experiences and Directions (OWLED 2006), Athens, Georgia, USA.
__________________________________________________________________________________________________________________________________
MATTHEW WEST wrote on 2013-12-03:
Dear Keith,
MW: I’m going to keep pushing back on the need for ordered lists, until I see a real requirement. So let’s start where you finished:
KW: Now some of these can be retrieved by a series of queries but handling the complex of relationships generated when we are dealing with lists of hundreds
or even thousands of ordered Things is a nightmare.
MW: I dispute that there is anything particularly complex here. If you have modelled the data correctly, there should be a single relation to query in each case to select the data, and then the same or another one to determine the order for display. This is what computers are supposed to be good at!
KW:
As for examples here are a few simple ones:
- List of Piping Components in Piping Network Segment
[MW>] Use the composition relation to discover which components are part of the PNS, then presumably order them by the order they are connected by the pipework from end to end.
- List of Compounds and Mole Fraction for each in a fluid stream
[MW>] Use the relation between stream and instance of class_of_molecule to determine the list of components. You probably want to order by size of the mole fraction (which might change from simulation to simulation, so I really would not want a defined list here).
- List of Points in a Curve or Polyline
[MW>] Use composition to get the members, use connection to order them.
- List of Cable Tray/Rack support points used to define a cable route
[MW>] Use composition and connection again.
- List of geometric primitives in a symbol
[MW>] Why does the order matter?
- List of matched Properties on a heat exchanger heating/cooling curve
[MW>] Obtain members of curve, order by size along a chosen axis.
MW: The danger of using a list in these cases (and especially instead of the underlying relationships) is that you risk losing or confusing the underlying meaning.
KW: Now some of these can be retrieved by a series of queries but handling the complex of relationships generated when we are dealing with lists of hundreds or even thousands of ordered Things is a nightmare.
[MW>] It should only be a nightmare if you have to deal with hundreds or thousands of different types of relation. Hundreds or thousands of one or two types of relation should be straight forward.
Further, if you really have lists of hundreds or thousands, they are not very useful for users in that form. More likely their real requirement is to find particular things in that list – better to support that need directly, rather than make them search manually within a list that you have ordered in a particular way.
__________________________________________________________________________________________________________________________________
HANS TEIJGELER wrote on 2013-12-03:
Apparently Matthew West couldn't convinve you. I agree with Matthew, but on the other hand I can see your requirement for some kind of a shortcut. Take the segments and inline components that are bounding such line segments, such as orifice plate assemblies, control valves, etc. I am borrowing a sketch made by Duhwan Mun:
Let's say that Line RZ17801 has three components:
- line segment RZ17801-4-S1 in the role of hasFirst
- control valve LV-101 in the role of hasSecond
- line segment RZ17801-4-S2 in the role of hasThird.
You could think of a template that has a signature with three predicates:
- hasFirst ClassOfInanimatePhysicalObject
- hasSecond ClassOfInanimatePhysicalObject
- hasThird ClassOfInanimatePhysicalObject
and voilá, you have your list. Or is that too simple?
If anything changes there, you will have to redo the entire list, that's the only consequence. As such that could be an advantage in case of snapshot updates of entire P&IDs, where you replace entire lines with all their segments and other components. That makes finding out what is new and what a replacement much easier (IFF the P&ID software remembers the UUIDs !).
__________________________________________________________________________________________________________________________________
KEITH WILLSHAW wrote on 2013-12-04:
This is a very simplistic example. The reality is that I don’t know how many components will be in a segment ahead of time. I only know there will be 1 to n.
Note that in your example what we would actually show for would be a single PipingNetworkSegment from Nozzle N1 to the Reducer outlet with an inserted Valve and a Reducer. Typically the line segments you show are actually dynamically generated i.e. when the valve is inserted what was one line segment becomes 2 line segments.
As such they would not have a persisted ID whereas the Valve and Reducer along with other piping components would. In fact in some systems the line segments do not actually exist in the database, they are implied as existing between ordered piping components. They have no intrinsic business value being simply a graphical representation of connectivity.
Since I cannot have a template with empty roles in order to go down the route you suggest I would have to have a large number of templates with numbers of predicates ranging from 1 to n and them pick the correct template at run time. Since they have different numbers of roles they are not of course simply specializations.
An ordered list is just a much simpler and more elegant solution. Part2 gives us the means to handle this in the form of the MultiDimensionalObject which as I am sure you know is defined as follows
“A <multidimensional_object> is an <abstract_object> that is an ordered list of <thing>. The significance of the <multidimensional_object> is determined by being a member of a <class_of_multidimensional_object> that indicates the role played by each of its elements.”
As I mentioned in my earlier post this is a relatively simple example. When we get into handling Stream Cases and we have multiple ordered lists of properties or Pump curves we have more complex cases.
This is in fact exactly the basis for the definition of MultiDimensionalProperty in Part2
“A <multidimensional_property> is a <property> that is also a <multidimensional_object>.
EXAMPLE A pump flow head characteristic is a multidimensional object. It consists of a continuum of Q, H property pairs, where Q is the flow rate and H is the flowing head difference. Each pair of properties Qa and Ha, where Qa is a particular flow rate and Ha a particular head, is a multidimensional property [Qa, Ha].”
It does not seem unreasonable to me to ask for a means of implementing these fundamental constructs instead of fudging it some other way.
__________________________________________________________________________________________________________________________________