Sub-classes vs. Instantiation of existing VSS concepts

[danielwilms]

In the current proposal, concepts generated from VSS are sub-classes of the core ontology, rather than instances. In this issue we want to collect pros and cons as preparation for a decision.

[felix-loesch]

As discussed in the VSS Ontology Workshop on 14.03. we decided to go for the following implementation:
DynamicVehicleProperty: Implementation as instances
StaticVehicleProperty: Implementation as subclasses. Subclasses can be further instantiated to assign concrete values to static vehicle properties (e.g. vehicleWidth = 3400 mm).
VehicleComponent: Implementation as instances
Vspec2ttl (VSS Tools): define rules /exceptions how to generate VSS signals in VSSo

[jdacoello]

DynamicVehicleProperty: Implementation as instances

I have a comment/question about the implication of the tentative decision of having DynamicProperties as individuals. The main concern is regarding the practical use of the dynamic properties (e.g., Speed). To illustrate the possibilities, let us focus on trying to say that "MyVehicle has the property of Speed whose value at time 10:34 is 100"?

• NOTE: Rectangles with rounded corners are classes and sharp corners represent individuals

Current vsso-core model

Let's start with what we have right now:

• In the current approach, all the VehicleProperties must be instantiated to be able to assign a Value.
• Despite that fact, the model is clean and its patterns are easy to follow.
• To update the property value, it is ALWAYS needed to delete the previous value and then insert the new one.

Specific DynamicProperties as individuals

The limitation

Now, let's consider the change:

I see the following:

• Individuals will be helpful whenever you just need to point to the element of the hierarchy, which implies not instantiating dynamic properties for each new vehicle.
• However, the question mark at the right side red box in the diagram indicates that using this approach directly from Vehicle instances won't be possible. Unless I am missing some detail of OWL and RDF, I believe that assigning custom values to the individuals defined in the model is not possible. I mean, you could add the triple to assert the value and the time, as it is shown in the figure. However, there wouldn't be a way to identify the vehicle that is modifying those value updates.

The work around

To work around this you need to add a custom middle hop in between (generic for all dynamic vehicle properties). Something that would look like the following:

• Although we don't need to instantiate DynamicProperties anymore, we must instantiate a custom class to indicate the value, time, and the connection to the dynamic property to which it refers. This custom class can be, for example, an Observation of a dynamic property that belongs to the vehicle. If this is the case for the modeling decision, I suggest that we come with a name for that middle step to have it as part of the ontology, too. This could, however, sacrifice some semantics.

[rtroncy]

The work around, i.e. adding intermediate observations, is indeed the best way to model with this configuration. This is similar to what SOSA does for example.

However, another alternative is to not model Speed as an instance but as a property. And this would generalize for all vehicle properties (static and dynamic). Again, what was the rationale to model a class hierarchy instead of a property hierarchy? I need a refresh!

[danielwilms]

I wouldn't call it a work around. As discussed in the workshop, it seems to make sense for dynamic vehicle properties to model it like that, as they're mostly used in combination with observations.

Punning was suggested for having both instances and classes or properties available.

Again, what was the rationale to model a class hierarchy instead of a property hierarchy? I need a refresh!

for some static properties it makes sense, to instantiate (e.g. model, brand, etc.) as there the connections help. For the dynamic part the reason was (if I recall correctly, have to check notes) the proximity to SOSA.

[jdacoello]

what was the rationale to model a class hierarchy instead of a property hierarchy?

@rtroncy , do you mean having a property hierarchy like:

• hasProperty
  • hasDynamicProperty
    • speed
    • acceleration
    • gear
    • etc.
  • hasStaticProperty
    • brand
    • model
    • VIN
    • etc.

In that case, we would have something like:

I have a couple of questions of this appraoch:

• What is the practical use of this approach for the end-user? I mean, should it be handled with blank nodes to add extra metadata (like is the figure)?
• Would it be possible to say that speed is part of VehicleComponent

I think the main reason of having them as clases was being able to create instances and to tell something else about the clases. For example, to specify to which vehicle component is that property related or to keep open the option to specify further a hierarchy of vehicle brands and models, etc.

[rtroncy]

@jdacoello You could probably get rid of the blank nodes. The value of the property will make use of cdt:ucum. The provenance information capturing the time at which the observation took place can be attached to the complete triple via reification.

The added value is that the model is much simpler to query (and to understand, thus to adopt). The cons is that indeed, you're not following the SOSA modeling as @danielwilms said.

What does this mean that speed is a part of VehicleComponent? What do you want to express and for what purpose?
Yes, modeling things as instances (of classes) enable to say more things about these instances, but in this case, what do you want to express about the instance of a Speed?

[felix-loesch]

@rtroncy The approach with property hierarchies you are proposing will probably not work as expected as the OWL datatype properties are limited to have a literal value only and not a physical unit. Furthermore in conjunction with issue #29 we would like to attach additional metadata like minimum, maximum value to properties. If we follow the approach depicted in the diagram of @jdacoello under the headline "workaround" we will have a clean model.

[rtroncy]

@felix-loesch No, this is not true. See the extension with custom datatypes, with ucum, this has been done precisely for this purpose.

[danielwilms]

Would it be possible to say that speed is part of VehicleComponent

What does this mean that speed is a part of VehicleComponent? What do you want to express and for what purpose?

You don't need the belongsToVC object property anymore as it can be a datatype property of the vehicle component itself.

There's the proposal of punning on the table as well, which could help, but make it more complex.

[felix-loesch]

We have already thought many times about the best approach to handle the different requirements for static and dynamic vehicle properties. We came to the following conclusions:

1. OWL datatype properties are not sufficient to handle dynamic property values as they are time-series related and there is no concept to associate multiple values with timestamps to a OWL datatype property
2. OWL datatype properties could be used for static vehicle properties but not every Vehicle has the same set of static vehicle properties. If you want to express this you have to relate the Vehicle instances to static vehicle property instances.
   Both observations lead us to the conclusion to model dynamic and static vehicle properties as instances of classes and then link them to the Vehicle instances using object property "hasVehicleProperty".

[jdacoello]

The value of the property will make use of cdt:ucum

@rtroncy I like the simplicity of expressing units in this compacted way.
However, if you follow this approach, I believe that these custom datatypes won't be handled out-of-the-box by many existing tools. Then, the final user of the model must make sure that he/she has in place a system that is able to apply functions and operations on those datatypes.

Since we want to promote the adoption of VSSo, I suggest sticking with a solution that uses the default datatypes. And handling the units with instances of an already existing ontology.

[felix-loesch]

+1. The tooling issue is really important for adoption of VSSo.

[danielwilms]

• Instantiation for Dynamic Vehicle Properties still to be used
• Maybe simple observation proposals in VSSo Core (ticket @danielwilms)
• Punning as possibility to have both (ticket @danielwilms) < @tguild will ping Alan on proposal

Next Step:
@danielwilms create PR in Covesa Repo

[pchampin]

@jdacoello

I believe that these custom datatypes won't be handled out-of-the-box by many existing tools. Then, the final user of the model must make sure that he/she has in place a system that is able to apply functions and operations on those datatypes.

True, standard OWL reasoners won't be able to tell that "1m"^^cdt:ucum and "100cm"^^cdt:ucum are actually the same thing. But neither will they be able to tell that [ :value 1; :hasUnit u:m ] and [ :value 100; :hasUnit u:cm ]are actually the same thing. I am not sure exactly what compound values buy you, compared to specific literals...

[pchampin]

@felix-loesch
I understand why dynamic properties require more complex constructs than just datatype properties, in order to relate additional metadata (temporal, at least). This more complex construct can be a class-instance relation (as in the first figure above), and observable-feature relation (as in the third figure above), or an RDF reification (as suggested by @rtroncy above). RDF-star could also be used, I have to mention it 😉 although I understand it is probably not mature enough for this group.

For static properties, however, I don't understand why datatype properties were deemed inappropriate.

not every Vehicle has the same set of static vehicle properties. If you want to express this you have to relate the Vehicle instances to static vehicle property instances.

I don't get how the 2nd sentence follows from the 1st one.

[jdacoello]

ONLY if the proposal to issue #13 is accepted, consider changing specific StaticVehicleProperties from sub classes into individuals.

The resulting structure would look like the following figure for the example of the vehicle's Brand:

[danielwilms]

@danielwilms to create counter proposal

[rtroncy]

I wish to also make a counter proposal based on the idea sketched in #22 (comment), using ucum datatype and RDF-star for attaching temporal information to the observations. I could prepare such a proposal by mid/end-July. Would it be to late?

[jdacoello]

@rtroncy Any other proposal is always welcome. The next meeting will be on Monday 11.07.2022. I believe that this topic will be further discussed there. Maybe by then it would not be resolved yet. But, since the discussion is fresh, it would be great if you could join the call and bring also your ideas as these aspects have a direct impact on the core model.

FYI, it was mentioned in the last meeting that for some static vehicle properties (i.e., attributes) it will make more sense to have data properties directly linked to a Vehicle. The main idea behind my last proposal was to be generic. Apparently, the proposal (detailed in issue #13) has is a better fit for a DynamicVehicleProperty only.