"connectsTo" Relationship instead of "startsAt"/"endsAt" ones

[AHABID]

"connectsTo" is a an NGSI-LD relationship defined in the NGSI-LD cross domain ontology recommended by the ETSI CIM group. Since that we have defined the relationships "hasInlet" and "hasOutlet" that help in defining the inlet and the outlet points of Nodes and in order to simplify more the model and to align it with the NGSI-LD cross domain ontology: is-it possible to replace "startsAt"/"endsAt" relationships by "connectsTo"?
@franckLG @csweetapple @albertoabellagarcia

[csweetapple]

We need to know what direction a link (pipe/valve/pump) runs in, so it is important to be able to distinguish between the start and end nodes (they cannot be swapped around). We would lose the ability to do this if we just had a 'connectsTo' relationship.

[franckLG]

Is this direction really to be part of the model or is it overall deduced by the simulation and physical law : differences in height or pressure should define the orientation.
Some water utilities discovered that at the end of the network, there may be some water reinjected back into the network which means that some pipes had the 2 directions of water flow depending on time/events in the day.
So the overall question is: is having this orientation hardly encoded in the data model a real need or is this something that the physical model (i.e. EPANET) would infer in any case at the end ?

[csweetapple]

It is really a part of the model.

• For pumps, it is necessary to know what direction the water is being pumped in (i.e. from start node to end node).
• Some valves only allow flow in one direction - we need to know what direction this is (obviously a valve, like a pump, could be oriented in either direction depending on the design of the network - we cannot deduce this direction from heights or simulation).
• All links can have any number of vertices specified - in EPANET these are an ordered list of coordinates, ordered from the start node to the end node. The vertices have been included similarly in the data model. If we are unable to distinguish between the start and end node of the link then we don't have sufficient information to use the list of vertices. Vertices are not used in simulations, so replacing them with junctions (to overcome the order issue) is not an acceptable solution due to the compleity this would add to the model and impact on simulation time it would have. However, it is important that we have the vertex information for visualising the network.

[csweetapple]

For pipes, which node is called the start and which is the end is selected arbitarily - it does not (necessarily) correspond to the direction of flow, which could in fact be variable. However, it must match with the order in which the vertices are listed.

[eladsal]

Hi All, I totally agree with @csweetapple. Also, in one of the data models there was a thought to place sensors with a property of distance from the start of the pipe so it is important to know which side is the start and which is the end.

[albertoabellagarcia]

So what is the agreement?

[eladsal]

I'm for keeping "startsAt"/"endsAt".

[albertoabellagarcia]

Anyone else opposing to accept Elad suggestion?

[franckLG]

So, from Chris explanations, this issue can be solved. It is clear that:
1 - Some items are directed (pumps, unidirectional valves, etc.)
2 - It allows to define the coordinate reference point of the vertice.
These components are modelled as entities and thus are not directed. So we have to keep the "startsAt"/"endsAt" relationships.
From these considerations the issue can be closed.

Another completely different approach would have been to model network elements as relationships which then would have been directed. From a conceptual point of view, such an approach would completely make sense but would have complexify the foreseen interactions between EPANET and the NGSI-LD graph through the current NGSI-LD api which is more entity centric for the queries.