Meeting minutes
VSSo lead
Daniel: unsure if I will be able to be part of this group going forward
… BMW needs to figure out still who they're sending
… DanielA will still be involved
… Felix also has been deeply involved
DanielA: I am quite open to discuss how we can support this
Felix: also from my side
… hope you will be able to remain involved
Pull Requests
https://
Daniel: we discussed three option: no root node but separate branches; core vehicle as a class and annotation property and vehicle component of root of instances
… we decided to go with option 3 but wait to allow for any reactions or feedback
Felix: option 3 is probably the best, 2 is a bit awkward, 1 would have a disconnect
… 3 would be instance of vehicle component, right?
Daniel: exactly
Felix: then I agree with 3
Daniel: I'll merge this one for now, review the changes and modify from there as needed
Felix: fine with me
DanielA: what would be the name of the root vehicle component?
Daniel: vsso:Vehicle
DanielA: we should include descriptions in the documentation to avoid confusion
Daniel: yes
Issues
https://
DanielA: the generated documentation is wrong in some places
https://
DanielA: current status is reflected in the top figure
… intention is to add value to this property. it has some drawbacks, simplicity is nice but here comes with limitations in practical use
… whenever you want to update the value you will need to first delete current triple and insert new one. not a big issue but a two step approach
… if you want to add multiple values or more information you might need new properties for that. it is preventing you from having a model with different units
… since the previous workshop, the resolution was to have specific dynamic vehicle properties as instances instead of subclasses
… in this diagram you can see if you add specific data properties to eg speed you will have multiple triples tied to the instance
… in practice you may have access to multiple triples
Felix: for me the speed property needs to be created under the vehicle identifier
DanielA: there is no possibility to identify the values are associated
Felix: prefix with vehicle identifier or vehiclePropertyValue as a class with vehicle name and associated properties
Daniel: conclusion at the workshop was to use SOSA for historic instead of current state
DanielA: how would this work in practice?
Daniel: one proposal was SOSA or could be a simple observation
… you won't have a connection to vsso speed
… problem is clear, let's see your proposal
DanielA: we need something linked to a specific vehicle and want something similar to what is shown here
… this vehicle has this property value. you just instantiate the values and link/point to the vehicle
… this would allow you to have additional linked meta data
… if you want freedom to express speed in alternate units, eg miles instead of km, you can change the quantity velue
Felix: this makes sense. in VSS we have concrete units defined so maybe we encourage consistence in km/h
Daniel: you don't want to attach metadata with every value
Felix: question is how strict or relaxed should we be without diluting the standard
… in US people are use to miles but it is easy to convert when displaying
Daniel: we discussed in VSS. we took the unit configuration out and put into a configuration file
… you're not necessarily losing information
Pierre-Antoine: question is who gets the burden if you choose flexibility. if you allow alternate units, it is more work for the consumer
DanielA: I would vote to fix the unit
Felix: most important is to agree on vehicle property class so we can express the values
Ted: also supporting fixed units, it will make adoption more difficult for US OEM and other data producers as well as consumers.
Felix: QUTT for example comes with conversion utilities
DanielA: the conversion should be kept out of the ontology
Felix: agree
DanielA: we need to agree to unit names
Daniel: why not use existing?
DanielA: wondering whether to reuse concepts from other ontologies or have all concepts in VSSo
Daniel: leverage SOSA for example?
DanielA: right
Daniel: it would depend on definition, the concepts are trivial. we can start with the one we have but you're welcome to start another issue
Felix: sounds good
Daniel: did you want it in the core or somewhere else?
DanielA: as an object property
Daniel: do a proposal as a pull request on top
DanielA: I can do that
Daniel: I will look at the tooling
https://
DanielA: problem was having specific dynamic values as instances instead of subclasses
… static properties could be a subclass instead of an instance, point to any related concepts from their ontologies
… that way you reuse scope of VSSo and you can point to specific properties
Daniel: all the static values would be better as instances so you can collect for evaluation
… harder to query otherwise
… any other opinions?
DanielA: if you have other concept or interest and want to express more
… if you have a vehicle, you can link to concept somewhere else
Felix: data management systems are a philosophy in and of itself. every OEM is doing it differently
… its a nightmware
DanielA: if you look at the diagram, you can connect to more specific description
Daniel: you can get more specific
DanielA: in the end you want the characteristics in
Daniel: somewhere you'll need to define what the concept of a "brand" (example) is
… I agree with you but some of this is defined. concepts are there but do we need to get more specific/granular or keep it higher level?
Felix: that is true for all the things we model in VSSo. it is fine for the purposes we have
… ontology modeling is sufficient
DanielA: you want to remain open to be able to link to other concepts
Daniel: for static vehicle properties you might want additional information indeed and if it doesn't fit in VSS link and express elsewhere
Pierre-Antoine: can you give an example with brand being a class instead of instance?
Daniel: I can come up for next time
Felix: you can link individual vehicles to brand directly, the linkage would be vehicle is of brand. we would be expanding VSS
DanielA: the benefit is clearer for other data points like number of tires
Pierre-Antoine: the pattern you are looking at is a classic one, it uses SOSA properties since it is similar to observations there
… something that happens to be an instance of brand
… agree many of these are not needed as a class
DanielA: in some cases one property is not enough
Daniel: I would like to see static as properties but some should be part of the instantiation
… open to a counter proposal
… thanks for the discussion, continue in two weeks