View unanswered posts | View active topics It is currently Tue Sep 25, 2018 3:19 am



Reply to topic  [ 11 posts ]  Go to page 1, 2  Next
 How to model LISTs? 
Author Message

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

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.
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:
Attachment:
duhwans-line.jpg
duhwans-line.jpg [ 51.48 KiB | Viewed 1871 times ]


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.

__________________________________________________________________________________________________________________________________


Wed Dec 04, 2013 2:02 pm
Profile

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

This is an example as you gave. Your P&ID software can count n. It is no problem to generate specializations of this template for as many predicates as you need.

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

That's the charming side of this solution, if you map batchwise.

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

No problem, give those segments new UUIDs and terminate the ones in the previous batch.

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

See above. A clever software geek will find a solution.

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

Keith, that template IS a MultidimensionalObject, so an ordered list!

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

For stream cases see http://www.15926.org/publications/general-discussions/modes-and-options/index.htm.

Quote:
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].”

See http://www.15926.info/multidimensional-property/multidimensional-property.htm (forgive me the oldfashioned symbology (already TWO years old!!))


Wed Dec 04, 2013 2:33 pm
Profile

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia
There is one particular task for geometry modelling. It is often required to define a homogeneous list for geometry data (by homogeneous I mean ordered lists of same-typed objects without any particular role assigned to each object). Additional requirements are:

1. RDF representation should be as small (in triples) as possible.

2. List should not be restricted by length.

3. List should be named.

I've devised a representation for this task, which can be considered a specialised mapping from P2 to RDF.

My idea is obvious from the stand-alone named list of points (points are described separately):
Code:
<dm:MultidimensionalObject rdf:about="PL1_Point_List" />

 <owl:sameAs rdf:parseType="Collection">

         <owl:Thing rdf:nodeID="MSP5" />

         <owl:Thing rdf:nodeID="MSP6" />

         <owl:Thing rdf:nodeID="MSP7" />

         <owl:Thing rdf:nodeID="MSP8" />
  </owl:SameAs>

 </dm:MultidimensionalObject>


Is such a construct allowed? Can it be useful for the restricted context described above? Any other ideas to satisfy the requirements?


Wed Dec 04, 2013 3:55 pm
Profile WWW

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

Apart from the fact that it is not well-formed RDF or OWL, I would ask you: would it become different when you replaced MultidimensionalObject with any other string?

The minimum code for your example seems to me the following:
Code:
<owl:Class rdf:about="PL1_Point_List">
    <rdf:type rdf:resource="&tm;ClassOfTemplateWith4Predicates"/>
    <rdfs:subClassOf rdf:resource="&tm;Template"/>
    <rdfs:subClassOf>
        <owl:Class>
            <owl:intersectionOf rdf:parseType="Collection">
                <owl:Restriction>
                    <owl:onProperty rdf:resource="hasElement1"/>
                    <owl:allValuesFrom rdf:resource="MSP5"/>
                </owl:Restriction>
                <owl:Restriction>
                    <owl:onProperty rdf:resource="hasElement2"/>
                    <owl:allValuesFrom rdf:resource="MSP6"/>
                </owl:Restriction>
                <owl:Restriction>
                    <owl:onProperty rdf:resource="hasElement3"/>
                    <owl:allValuesFrom rdf:resource="MSP7"/>
                </owl:Restriction>
                <owl:Restriction>
                    <owl:onProperty rdf:resource="hasElement4"/>
                    <owl:allValuesFrom rdf:resource="MSP8"/>
                </owl:Restriction>
            </owl:intersectionOf>
        </owl:Class>
    </rdfs:subClassOf>
</owl:Class>


That results in 26 triples:
Attachment:
list.jpg
list.jpg [ 691.55 KiB | Viewed 1864 times ]


Thu Dec 05, 2013 12:20 pm
Profile

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

Quote:
it is not well-formed RDF or OWL


That's the most important. Why it is not?

Quote:
would it become different when you replaced MultidimensionalObject with any other string


Yes, it will. I'm assuming that there is a separate dm ontology available somewhere, where many useful facts about dm entities are recorded. Combined with this ontology you can do reasoning, verification, etc.

Just now this ontology is at:

http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003
http://rds.posccaesar.org/2008/07/OWL/I ... nnotations
http://rds.posccaesar.org/2008/07/OWL/I ... Membership
http://rds.posccaesar.org/2008/07/OWL/I ... Candidates
http://rds.posccaesar.org/2008/09/OWL/I ... verseRoles
http://rds.posccaesar.org/2008/09/OWL/I ... ainedRoles

Not a great ontology and we all hope for a better one. But it has 2 or 3 useful facts about this dm:MultidimensionalObject .

Quote:
The minimum code for your example seems to me the following:


Please explain in more details. What you are showing looks like a template definition, but my example shows an instance, declaration of a particular list with particular points as members. MSP8 is a particular metric space point with 3 specific coordinate values like <1.0, 2.0, 1.0>.


Thu Dec 05, 2013 12:55 pm
Profile WWW

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia
Just for the record I'll copy here from our earlier correspondence on the topic.

Do we need a uniform way to model MO and COMO, which will allow us to do a Part 2 compliant OWL models for diverse types of lists: lists of template roles, lists of points, lists of properties, etc. As well as I understand the situation now, it can be called the single most important reason for changes in p7tm model of Part 8.

As of today, we have several ways to model lists (MOs and to some extent COMOs). Current Part 8 way of modelling is designed particularly for lists of template roles. But Keith is asking about other types of lists. Matthew is describing one way to do it (more suitable for lists of piping). In GSIG we are discussing ways to do compact modelling of geometry point lists, which are homogeneous (do not require a particular role for each list member).

Uniform approach will probable be comparable in complexity to current P8 model, and will be very bulky for point lists!

Is it wrong to have several ways to represent MO and COMO in different contexts? Personally I'm quite happy with diverse models and I do not see any value in a uniform from-P2-to-OWL-compliant-model. Even the current P8 template model theoretically allows OWL reasoning over template definitions and instances. In practice I'm releasing a tool for specialized template, template instance and pattern verification, which is custom-designed for ISO 15926 data and is not based on standard OWL reasoning.


Thu Dec 05, 2013 1:00 pm
Profile WWW

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

Quote:
Please explain in more details. What you are showing looks like a template definition, but my example shows an instance, declaration of a particular list with particular points as members. MSP8 is a particular metric space point with 3 specific coordinate values like <1.0, 2.0, 1.0>.

What you want is a list, and what a template is is a list as well, so that's why they look alike.

The reason why a template is an owl:Class is that, next to being a MultidimensionalObject, it is also an instance of ClassOfInformationRepresentation. It tells nothing about your MSPs. These are defined separately the way you think is correct. I'd suggest though to talk to the Part 3 guys about what it is.


Fri Dec 06, 2013 11:00 am
Profile

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

In response to your second posting:

To me there seem not to be any reason why you should model a MultidimensionalObject and its classifying ClassOfMultidimensionalObject in various ways.

I have preached this gospel since February 2011, as you can find at the bottom of the frontpage of http://www.15926.info/
(I will update those pages).

Just like the semantics of lowered templates are defined by their lifted counterpart, so can that be done with the templates that represent a list. The list of segments and components that, in that order, constitute a Line can be "dressed up" with a lifted template that tells that they are connected pairwise. For that reason such lists should be made from junction to junction, so they should stop at a TEE or the like.

Please see the definition for PIPING NETWORK SEGMENT in http://posccaesar.org/rdl/page/RDS267704:
Quote:
The piping limited by a Node and a Break, Node and Connector, two Nodes, two Breaks, two Connectors or a Break and a Connector. The last five providing there are no Breaks or Connectors in between. In the last three cases the Segment will coincide with a Piping Branch.


Fri Dec 06, 2013 11:17 am
Profile

Joined: Tue May 15, 2012 8:48 am
Posts: 77
Colleagues Let me restate the problem as simply as possible

1) I have numerous instances of Lists of Data and Things that need to be transferred or
published by some entity so that other organizations may access them without instroducing
either errors or ambiguity.

2) In many but not all cases the order of the Data or Things in the list is important

3) I do not know when modelling how many items will be in the list other than
that the number lies between 1 and n where n can be in the order of housands.
For those that doubt this I have seen examples in both simulations and geophysical
surveys

4) The implementation must be practical, one suggestion that has been made involved
producing multiple specialised templates with the number of roles corresponding
to the number of elements in the list. Thus for a list of data points ranging from 1 to 10,000
points I would need produce and maintain 10,000 templates. This appears to me to be utterly
impractical.

Similarly deconstructing the list by producing a chain of relationships between each point
and then reconstructing it while technically feasible is apt to to be both slow and unreliable
in a real world implementation.

5) The concept of lists is common and valuable, is supported by Part 2 and in my humble
opinion cannot be simply ignored if our work is to retain any credibility in the commercial world.

Regards Keith


Fri Dec 06, 2013 11:55 am
Profile

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia
Quote:
The reason why a template is an owl:Class is that, next to being a MultidimensionalObject, it is also an instance of ClassOfInformationRepresentation.


Sorry, I'm lost again. Template instance is a MO because it is an ordered list of role occupiers (n-tuple). Template is a COMO because it is a predicate, and predicate is a set (class) of all n-tuples for which it is TRUE.

Quote:
It tells nothing about your MSPs. These are defined separately the way you think is correct. I'd suggest though to talk to the Part 3 guys about what it is.


Oh, I had! Metric space point is an AbstractObjects but not a Class from P2-P3 point. It is owl:Class in mapping to OWL, but it is not an ontological fact, I believe.

Therefore I'd prefer not to use constructs like

Quote:
<owl:Restriction>
<owl:onProperty rdf:resource="hasElement1"/>
<owl:allValuesFrom rdf:resource="MSP5"/>
</owl:Restriction>


Anyway, I do not believe that your series of templates with N roles are the only solution. Please explain, why my initial construct "is not well-formed RDF or OWL"?


Fri Dec 06, 2013 9:05 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 11 posts ]  Go to page 1, 2  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.