Meeting minutes
Introductions
Simon: geophysics background, transitioned towards enviromental sciences
… been working on originally UML then RDF/OWL for observation metadata
… acts of observation
… co-author of W3C SOSA/SSN and earlier worked on ISO and OGC versions
… worked in many different earth and energy models
Daniel: been at BMW for 9 years, Nokia before that
… data architecture centric, worked with Benjamin on VSSo. leading VSS/VSSo discussions at present
… we want a better information model across the company
Benjamin: I worked outside this topic at present, at VW subsidiary Carmeq
… worked with Daniel on VSSo based on VSS
… based on domain knowledge from VSS, core SOSA pattern for modeling observations for signals
Arman: I've been working on automotive cybersecurity with UL for three years before getting involved in W3C
… my main interest is in safety and security of connected
VSS2/VSSo history
Daniel shares screen
[reusing slides from last week's public working session]
Daniel: VSS is taxonomy of vehicle signals [slide 13] based on physical structure of the vehicle
… tree model with information down in the leaf level
… branching provides unique names. we differentiate between sensor and actuator, data type, unit and description
… we have 400 signals, number of which are repeated per door, seat, wheel... all of this is defined in YAML and from there we have csv, JSON (GraphQL, working on VSSo and soon protobuf)
Benjamin: we found three main patterns for vehicle signals. the taxonomy/tree shape based on physical characteristics of vehicle provides the underlying structure
… we wanted something lightweight for what a signal is, an observation from SOSA
… an attribute describes a car component and therefore a datatype property
… expressing values with units as a literal
… the use cases are mostly around telematics with ability to read and write
Simon: so you have a rich/full model of the vehicle physically and making observation of attributes at leaves
… and actuations?
Benjamin: yes
Simon: there are occuring patterns around actuation and observation, seems captured well
Daniel: we started with an earlier version of VSS when we created VSSo. some modeling choices were problematic but we were able to change them
… those changes were around instantiation for example (multiple wheels etc)
… we have three main use cases in mind. the one most interesting is dynamic vehicle data
… one dealing with interactions with eg WoT
… applicable to other interaction models
… we would appreciate your opinion on structuring
… for time based observations, I wanted to reflect the stream of observations
… but that is different than being a digital twin, is it an observation or more attached to current state
Simon: it may help if I can explain approach to SOSA
… you don't have to implement everything all the time and RDF world encourages this, allowing for assumptions
… goal of standardizing terminology in these spaces when you want to use one of these properties you have something you can take from either domain ontology or eg SOSA structure
… we worked early on with people doing weather forecasting, time properties involved 13 or so temporal properties coming from them
… we limited scope to two main temporal properties. in the ISO/OGC there was a third but didn't reflect that through. time when result was obtained and time it applies within the world
… if your application doesn't need it, you don't have to use it
… you will make selections. you will be transitioning from static and dynamic in some places
… what changes what viewpoint you take will be the time dimension. are you recording or reflecting current
… decide separately on what information to retain and discard
… you can use shape languages like SHACL
… when I was working in UML I said this is just a framework to do implementations within. goal is to provide people standard labels and slots for their data systems
… there may be multiple platforms involved, not necessarily even RDF based
… time scales (and volume of data) can range from milliseconds to years
… these models should not be taken as highly prescriptive but have sense you already understood this
… as Ted noted, also involved in Time space in addition to SOSA
… there are proposed extensions for both these ontologies which allow for patterns that are frequently coming up and worth describing and standardizing
… goal has been to use a mutual language
… I like what I'm seeing here and it makes sense to me
… encourage you to talk with Maxime who has more industrial space. my focus is more enviromental
… I haven't been involved in actuation
… that came from Maxime and his team
… regarding WoT is that coming from W3C or elsewhere?
Benjamin: yes, WoT being an interest
… we talked with Maxime back in 2019 but didn't look too much at the time in actuation, we were focused more on the time at observation
… we wanted to see if we could get alignment initially
… difficult to find direct link
… perhaps you can tell us more about 'feature of interest'
… car is a feature of interest as are its components...
Simon: that was how I understood what you have shown
… this word feature is a slightly strange use of the term, it comes from geospatial world
… makes less sense outside of geospatial. it is the thing you are making observations about
… your domain model recognizes these things as nested
… the domain model linking these components to vehicle as a whole. 'feature of interest' are just class of things we might make observations about
Daniel: right now we are thinking in the continuation of the ontology, taking the branches instead of referencing a given ECU
… 'feature of interest' fits pretty well to that, shows where the signal relates to
… we connected static and dynamic to vehicle itself
Simon: I am very comfortable with what I've seen and heard today
… this is how I would imagine the models/ontologies being applied to this knowledge domain. this is recognizably an appropriate use
Benjamin: regarding interacting with interaction with other domains, WoT has been our approach which has led to a bigger question
… how do you connect SOSA/SSN with other approaches?
… we have to make strong assumptions about a "Thing's" properties and events
… static maps to properties well. sensors more complicated and you need something specific to your use case
Daniel: what I don't get from WoT to Sensor is how to connect versus how to describe the world
… recording history of events SSN/SOSA makes sense
Simon: I'm not really familiar beyond background knowledge of WoT
… see how the views of the world are different but they don't seem incompatible
Simon: I haven't ingested VSSo yet
… this pulling in an existing domain ontology?
Daniel: gives GENIVI bg on VSS
Simon: and auto specific needs for Time extensions or we good there?
Ted on extensions for both@@
Simon: correct, we do expect to fold the Time extensions in directly. my further understanding of using SOSA/SSN within environmental gives me pause about pushing into SOSA or keep as extension
… we have specific sampling requirements for ecological needs
Simon: time series can be an active observation over time. duration becomes metadata
DanielA: that helps. sometimes you can nudge processes or store data coming with high velocity and clear need of aggregating a time series
… stream observations or events over time
Simon: the language we use in this space is the result of the observation. the result can be the time series as a whole
DanielA: you observe sensor as unique. it can be useful to just annotate series for different use cases
… hard to find a model that suits better these needs