Composite properties needed

While attempting to automatically convert the ETSI-ITS-CDD to SAREF, I face numerous challenges. One is the fact that, in many situations, a property is composed of different sub-properties.

Take as an example snippet from https://forge.etsi.org/rep/ITS/asn1/cdd_ts102894_2/-/raw/v2.1.1/ETSI-ITS-CDD.asn

/**
 * This DF indicates a transversal position in relation to the different lanes of the road. 
 * It is an extension of DE_LanePosition to cover locations (sidewalks, bicycle paths), where Vehicle ITS-S would normally not be present. 
 *
 * The following options are available:
 *
 * @field trafficLanePosition: a position on a traffic lane. 
 * 
 * @field nonTrafficLanePosition: a position on a lane which is not a traffic lane.
 * 
 * @field trafficIslandPosition: a position on a traffic island
 * 
 * @field mapPosition: a position on a lane identified in a MAPEM.
 *  
 * @category: Road Topology information
 * @revision: created in V2.1.1
 */
GeneralizedLanePosition::= CHOICE {
    trafficLanePosition       LanePosition,
    nonTrafficLanePosition    LanePositionAndType,
    trafficIslandPosition     TrafficIslandPosition,
    mapPosition               MapPosition,
    ...
}	

Here, GeneralizedLanePosition would be modeled as a saref:Property, with four narrower properties: TrafficLanePosition, NonTrafficLanePosition , TrafficIslandPosition , MapPosition.

TrafficLanePosition is pretty easy, but it demonstrates that the frontier between states and properties is blur (see #62):

/**
 * This DE indicates a transversal position on the carriageway at a specific longitudinal position, in resolution of lanes of the carriageway. 
 *
 * For right-hand traffic roads, the value shall be set to:
 * - `-1` if the position is off, i.e. besides the road,
 * - `0` if the position is on the inner hard shoulder, i.e. the hard should adjacent to the leftmost lane,
 * - `n` (`n > 0` and `n < 14`), if the position is on the n-th driving lane counted from the leftmost lane to the rightmost lane of a specific traffic direction,
 * - `14` if the position is on the outer hard shoulder, i.e. the hard should adjacent to rightmost lane (if present).
 *
 * For left-hand traffic roads, the value shall be set to:
 * - `-1` if the position is off, i.e. besides the road,
 * - `0` if the position is on the inner hard shoulder, i.e. the hard should adjacent to the rightmost lane,
 * - `n` (`n > 0` and `n < 14`), if the position is on the n-th driving lane counted from the rightmost lane to the leftmost lane of a specific traffic direction,
 * - `14` if the position is on the outer hard shoulder, i.e. the hard should adjacent to leftmost lane (if present).

 *  @note: in practice this means that the position is counted from "inside" to "outside" no matter which traffic practice is used.
 *
 * If the carriageway allows only traffic in one direction (e.g. in case of dual or multiple carriageway roads), the position is counted from the physical border of the carriageway. 
 * If the carriageway allows traffic in both directions and there is no physical delimitation between traffic directions (e.g. on a single carrriageway road), 
 * the position is counted from the legal (i.e. optical) separation between traffic directions (horizontal marking). 

 * @category: Road topology information
 * @revision: Description revised in V2.1.1
*/
LanePosition ::= INTEGER {
    offTheRoad           (-1), 
    innerHardShoulder    (0), 
    outerHardShoulder    (14) 
} (-1..14)

I model it as a property s4auto:LanePosition, the integer "n" would be the value of the PropertyValue instance. I define three distinguished instances of PropertyValue:

s4auto:LanePositionOffTheRoad a saref:PropertyValue .
  saref:isValueOfProperty s4auto:LanePosition ;
  saref:hasValue -1 ;
  rdfs:label "LanePosition - OffTheRoad"@en ;
  rdfs:comment """if the position is off, i.e. besides the road"""@en .

s4auto:LanePositionInnerHardShoulder a saref:PropertyValue .
  saref:isValueOfProperty s4auto:LanePosition ;
  saref:hasValue 0 ;
  rdfs:label "LanePosition - InnerHardShoulder"@en ;
  rdfs:comment """if the position is on the inner hard shoulder, i.e. the hard should adjacent to the leftmost lane"""@en .

s4auto:LanePositionOuterHardShoulder a saref:PropertyValue .
  saref:isValueOfProperty s4auto:LanePosition ;
  saref:hasValue 14 ;
  rdfs:label "LanePosition - OuterHardShoulder"@en ;
  rdfs:comment """if the position is on the outer hard shoulder, i.e. the hard should adjacent to rightmost lane (if present)."""@en .

But then, there is the LanePositionAndType type:

/**
 * This DF indicates a transversal position in resolution of lanes and the associated lane type.
 *
 * It shall include the following components: 
 * 
 * @field transversalPosition: the transversal position.
 * 
 * @field laneType: the type of the lane identified in the component transversalPosition.
 * 
 * @category Road topology information
 * @revision: Created in V2.1.1
 */
LanePositionAndType::= SEQUENCE {
    transversalPosition    LanePosition,
    laneType               LaneType,
    ...
}

It is a composite property, that consists of a LanePosition (as above), and a LaneType. A few examples of lane types are below:

 * - 9	- `taxi`               - Lane dedicated to movement of taxis,
 * - 10	- `hov`                - Carpooling lane or high occupancy vehicle lane,
 * - 11	- `hot`                - High occupancy vehicle lanes that is allowed to be used without meeting the occupancy criteria by paying a toll,
 * - 12	- `pedestrian`         - Lanes dedicated to pedestrians such as pedestrian sidewalk paths,

One could either model these as FeatureKind (the lane would be the feature of interest, and its type wouldn't change over time), as States (with different narrower states corresponding to the type of lane, and that can be observed), or as Properties (that could be modeled with the integer value being the value of the PropertyValue, and for which one could identify a couple of PropertyValues).

I'd like to go for the third modeling choice, which to me is the more accurate (the usage of the lane could change over time), but I face two issues:

1. That property is the property of the lane, not of the vehicle
2. How to define that the LanePositionAndType is composed of the LanePosition and the LaneType ?

For point 2, I might want to use saref:consistsOf , or saref:hasProperty.

If consistsOf, that would give something like:

s4auto:LanePosition a saref:Property .

s4auto:LaneType a saref:Property .

s4auto:LaneTypeTaxi a saref:PropertyValue ;
  saref:isValueOfProperty s4auto:LaneType ;
  saref:hasValue 9 .

s4auto:LanePositionAndType a saref:Property ;
  saref:consistsOf s4auto:LanePosition , s4auto:LaneType .

A property value for the s4auto:LanePositionAndType could consistsOf different property values:

[] a saref:PropertyValue;
  saref:isValueOfProperty s4auto:LanePositionAndType ;
  saref:consistsOf [ 
    a saref:PropertyValue;
    saref:isValueOfProperty s4auto:LanePosition ; 
    saref:hasValue 2
  ] ;
  saref:consistsOf s4auto:LaneTypeTaxi .

Problem: in some situations, a composite entity may be composed of twice the same property. For example, the TrafficIslandPosition property above is defined as:

TrafficIslandPosition ::= SEQUENCE {
    oneSide      LanePositionAndType,
    otherSide    LanePositionAndType,
    ...
}

so, there wouldn't be a way to differentiate which property value applies to which side.

possible solution: we could define sub-properties of saref:consistsOf to distinguish the different components of the property:

s4auto:consistsOfTransversalPosition rdfs:subPropertyOf saref:consistsOf .
s4auto:consistsOfLaneType rdfs:subPropertyOf saref:consistsOf .

<lanepositionandtypevalue> a saref:PropertyValue;
  saref:isValueOfProperty s4auto:LanePositionAndType ;
  s4auto:consistsOfTransversalPosition
    laneType [ 
    a saref:PropertyValue;
    saref:isValueOfProperty s4auto:LanePosition ; 
    saref:hasValue 2
  ] ;
  s4auto:consistsOfLaneType s4auto:LaneTypeTaxi .

Problem 2: There are two options for how to model an observation about the composite entity.

It could be option 1: one observation with a composite property value,

[] a saref:Observation;
  saref:observes s4auto:LanePositionAndType ;
  saref:hasResult <lanepositionandtypevalue> .

or option 2: one observation with two results,

[] a saref:Observation;
  saref:observes s4auto:LanePositionAndType ;
  saref:hasResult [ 
    a saref:PropertyValue;
    saref:isValueOfProperty s4auto:LanePosition ; 
    saref:hasValue 2
  ] .
  saref:hasResult s4auto:LaneTypeTaxi .

IMO, option 1 would be preferred.

What are your thoughts about this ?

changed the description

Agreed that conceptually your first option should be preferred. However, the second option can already now be used.

The saref:hasValue constraint on saref:PropertyValue should then be relaxed from exactly 1 to max 1, isn't it? Because your example in option 1 has a saref:PropertyValue without a saref:hasValue property.

However, we would want to tag these composite properties in the documentation as advanced usage to warn potential users and initially indicate them to regular properties. In the documentation diagrams we can also add a recursive arrow on the PropertyValue and an example & a note to show its usage.

mentioned in commit b1f9912a

mentioned in merge request !44

mentioned in issue #62