Proposal Core Ontology: StaticVehicleAttributes: which attributes shall be explicit?

[danielwilms]

Static vehicle attributes define the vehicle and are set in the core ontology #5 as datatype properties. Question is, if and which attributes are better to be modelled as explicit classes instead of properties. Any Opinion?

[jdacoello]

Considering that the class Vehicle is the main concept of VSSo, I like all the vehicle static attributes as literals connected with the relationship hasStaticVehicleProperty and its sub properties like hasVehicleIdentificationVIN.

However, if you want to tell something else about such attributes (e.g., that the static attribute belongs to a particular component of the vehicle), then I would model those as subclasses of StaticVehicleProperty. One general approach could be to keep all identification attributes (e.g., VIN) or anything that is part of a virtual vehicle component as literals connected via data properties.

[danielwilms]

Here is a proposal using sub-classes for static vehicle properties:

The generated ttl file will be attached as soon, as it's ready.

[jdacoello]

It seems to me that we can remove the owl:AnnotationProperty. Or is it adding something relevant in practice?
In the end, now both (vsso:StaticVehicleProperty and vsso:DynamicVehicleProperty) are conected to a particular VehicleComponent via the vsso:belongsToVehicleComponent relationship.

[danielwilms]

It seems to me that we can remove the owl:AnnotationProperty. Or is it adding something relevant in practice?
In the end, now both (vsso:StaticVehicleProperty and vsso:DynamicVehicleProperty) are conected to a particular VehicleComponent via the vsso:belongsToVehicleComponent relationship.

I would keep focussing on the staticVehicleProperty here. Please use #8 for that discussion.

[felix-loesch]

Considering that the class Vehicle is the main concept of VSSo, I like all the vehicle static attributes as literals connected with the relationship hasStaticVehicleProperty and its sub properties like hasVehicleIdentificationVIN.

However, if you want to tell something else about such attributes (e.g., that the static attribute belongs to a particular component of the vehicle), then I would model those as subclasses of StaticVehicleProperty. One general approach could be to keep all identification attributes (e.g., VIN) or anything that is part of a virtual vehicle component as literals connected via data properties.

We (Felix, Anees from Bosch) discussed this with @danielwilms and agreed on taking the latter choice, i.e., modelling static attributes (e.g. number of cabin doors) as sub-classes of StaticVehicleProperty. That way these properties can be connected to VehicleComponent using belongsToVehicleComponent.

[felix-loesch]

Contrary to my comment from Apr 29, I suggest to model static attributes as instances of StaticVehicleProperty.