New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restrictions on datatype/unit #13
Comments
Has to be solved OWL compliant. Raised as issue in: w3c/vsso#13 Signed-off-by: Daniel Wilms <Daniel.DW.Wilms@bmw.de>
I strongly suggest that we move the concrete VSS definitions (e.g. signals, branches) to OWL instances. |
Possible tooling extension for: |
@jdacoello will create proposal until 2022/05/30 for discussion |
Here is a proposal to handle values and units. Current problem/drawbackTo give some context, as of today, a PROS:
CONS:
You can see in the figure how multiple values coming from different vehicles are linked to the same instance of a ProposalI propose to have the following structure: If the unit is fixed, make it part of the modelIf the unit is not fixed, introduce quantity kind for correctnessAdopt an existing ontology for units and quantity kinds (e.g., QUDT)VSS has the specification for the unit and the dimension to which it relates. We can use it to map into concrete instances of unit and quantity kind. Taking the extensive QUDT ontology as the reference: |
Meeting 2022/06/27:
|
|
Related to issue w3c#13. Class VehiclePropertyState was introduced to handle the values and metadata of a DynamicVehicleProperty. Changes were: Create a new class VehiclePropertyState Create a new object property hasVehiclePropertyState Domain: Vehicle Range: VehiclePropertyState Change domain of vsso-core:propertyValueUpdatedAt Domain: VehiclePropertyState Change domain and range of vsso-core:vehiclePropertyValue Domain: VehiclePropertyState Range: Literal
First idea was using schema:rangeIncludes. Other ideas from @felix-loesch
The text was updated successfully, but these errors were encountered: