<scribe> scribenick: ted
<scribe> Scribe: Ted
<scribe> Meeting: Auto BG F2F
Ted: what do people envision for an automotive data market place?
PatrickL: it is more a question
to those who want to use that data
... yes, we want to use it too and be able to share with
partners provided permission is given
... more common the model the better
... the way a how such a marketplace is structure, whether it
is standardized and well understood, will be influenced by the
market
Glenn: from a fleet perspective a
common dataset is useful, silo approach is problematic
... depending on the end user, their uses vary. to be able to
formulate it before it is transmitted is highly valuable
... for example if you take all the available signals and send
to cloud that is not necessarily useful for specific
purposes
... you need to take a purpose specific approach. commercial
fleets have become accustomed for things like predictive
maintenance
... having that consistent across manufacturers is something
they have become accustomed to
Ted: curious how many vehicles are part of commecial fleets
Harjot: we have 1.3M devices and have more vehicles through other telemetics services
<Harjot> Video mentioned by Glenn: https://www.youtube.com/watch?v=2vxsyJLygws
Glenn: there is a short video on
how we handle data sampling with a curve algorithm
... we can determine within a few weeks when a battery will
fail for example, and send that information to the cloud but
not needed otherwise
... Geotab has reverse engineered every vehicle used in
commercial fleets to be able to provide commonality, we are
looking forward to the standard providing that
Daniel: as you said we have thousands of signals, the private parts are less important
Guru: see email for CCC's similar work
PatrickL: they are working on
infrastructure, transmission and authentication
... they are not working on datasets itself
... they were willing to allow vehicles to deliver whatever it
had
... it has been a few years since I was involved with
them
... skimming the whitepaper...
... it might be great to align and leverage their experience
for backend plus identification, authorization parts
[discussion of experiences and synching with CCC. University of Colorada joining for Neutral Vehicle interests]
Glenn summarizes NV, mix of academia, government, telematics experts to demonstrate interoperability
Glenn: having government
involvement gives us large number of vehicles, their fleet to
draw data from
... we have a couple of projects in place
... we proposed to EU parliament concept of secure, accessible
data
neutralvehicle.com
Ted: clearly we should sync with CCC
[review of who has current and past experiences/relationships to draw from]
[Guru and Patrick to reach out]
Glenn: another thought on CCC, a phone is an individual's device (unlike shared vehicle) and consent can be prompted when a new phone is being paired with
[break until 10:30]
<AdamC> Hi everyone :)
<AdamC> Hi Ted. Have we resumed yet? I'm getting no audio on webex
[slide overview of automotive ontology work]
Benjamin: I wanted to make the
signals understandable to me and machines as well
... there are approximately 1k signals in VSS (Genivi, what W3C
VISS uses)
... it makes sense in having labels/descriptions, min/max value
ranges, units etc
... from this I started my ontology. I am creating RDF triples
(W3C OGC) instead of a tree using SOSA/SSN
... speed for example maps to sosa.ObservableProperty from a
sensor
... and encapsulation time, location and other parameters
available. speed is an observable signal based on other data
points or provided by the vehicle [actually vehicle provides
that element in multiple places]
... there are some weird things in VSS that need to be worked
out. need for unique names. i removed location (front, right,
left, rear) since you can instantiate eg mirror and distinguish
which it is
... want to be able to extend and add new sensor or other
data
... as mentioned you can measure the same information from
multiple paths
... you should not need to know which component is handling it
and filter by component/branch that is producing it
... you only care how fast the vehicle is going instead of how
you attained that information
... from a IoT/WoT point of view this (slide 14) is how you can
describe a vehicle
... we want to allow you to create instances of the same
concept (door, mirror, etc) and not be confined to how it is
outlined in VSS
... tree is no longer relevant when we move to a graph
model
... some other examples, I made a sparql simulator (similar to
sql) for interacting with VSS data
... you can make quite complete queries without understanding
workings of vehicle. this is more for off line use and some are
interested in realtime vehicle information
... we liked the VSS extension mechanism
PatrickL: I have a question for WG on structuring query
subtopic hashing: different use cases for JSON on vehicle vs RDF, JSON-LD, power benefits of SemWeb, WoT/realtime interactions and hesitations
Gregg: JSON-LD is great at
keeping things JSON based while masking some of the underlying
SemWeb complexities
... it allows to specify and inline further context (also
JSON-LD)
... auto for instance is a term that expands to its schema,
similar for IoT
... a JSON-LD processor can use inline defined context to turn
it into a URI, in thing description for instance
... just having a name in JSON does not have any grounding to
reality
... the elements might come from different vocabularies
... another thing we can do is have expectations for the term
base
... ideally a context is defined that allows the expression of
JSON as a developer expects to see it without all the RDF
behind it
... we might want to transform from JSON to alternate
formats
... you will notice some elements are link identifiers. this
can be flattened out
... we can take this information and convert to RDF and other
formats
Sebastian: I like it especially
as you represent the "thing" description as of a few days
ago
... allowing to skip media type and default to JSON
... you do not need to announce all the time
... writeable attribute
... using framing helps with semantic processing
DanielF: we started with JSON-LD 1.0 and got feedback from Mozilla
Gregg: there are multiple
properties within an array in 1.0, in 1.1 we have ID maps which
allows you to have a property as an object
... the keys are identifiers (ids)
... you can also index on a type, you might have multiple
languages present
PatrickL: so it is possible to assign multiple types to a property?
Gregg: RDF type is property of
resource that identifies a class for that resource
... yes you can have multiple types
... we can defer inference when going over subclasses, you can
be representing a thing that is a car
... values can also have types such as datetime
... any XSD types are possible
... you can make inferences and query based on those
values
... I expect basic classes of properties as a starting off
point
PatrickL: so SPARQL is the way to query JSON-LD?
Gregg: it is one way to access
this information. it is SQL like and maps to RDF subject
predicate object triple
... you can serialize the results in JSON-LD or other
formats
PatrickL: we have distinction between attributes and signals and not so action/event driven
Sebastian: request to open window is an action
PatrickL: yes
Benjamin: pushing the button triggers the window action
Sebastian: there are legacy property type approaches and the thing description allows how you control your system
PatrickL: looking at SPARQL it is
quite powerful to ask for very specific information
... I received internal feedback that it is hard to comply with
the W3C Member Submission (ViWi) we made previously
... it is possible to let someone know not to ask for eg
long/latitude since we will not share with a given
application
Gregg: the ontology defines the
types of relationships that align with these properties. say
you want to query door, you want to know all the properties
that have door as part of its domain
... there are other technologies like shacl and shex
... to be a valid door it needs to have these values expressed.
you could perform a sparql query but better would be one of
these constraint languages
... you are not required to use SPARQL, you might just want to
get back JSON when an event occurs
... it is not intuitive to some web developers who will prefer
JSON
PatrickL: I would like access for developers to be harmonious. not sure we should offer multiple paths
Benjamin: SPARQL is the query
language for RDF
... it is extremely powerful when merging data from additional
domains
... I do not see it as mainstream
Gregg: there are people who use
JSON-LD for crossing borders between programming
paradigms
... you want uniform data
... the performance can vary quite a bit based on dataset.
there are also REST ways for accesssing
... what types of query mechanisms do WoT folks do?
Sebastian: we do not have
guidelines, want RDF in background and you can use any
... we have a thing directory with a store to keep thing
description
... each device automatically sends thing description to
directory, it is just a SPARQL endpoint
PatrickL: so you define your thing directory outside of your ontology?
Sebastian: yeah the thing
description itself is an RDF store
... you return a thing description, answers you can send is a
triple
Gregg: if you have a car you might have a thousand things within it, would each register itself within the thing directory so I could query it?
DanielF: you would not register
everything for a device. you want to know street lamps and
vehicles around you can interact with
... each sensor hasn't registered
Sebastian: up to you to setup
your system
... depends on who is doing it for what purpose. backend or
vehicle
<Zakim> ted, you wanted to comment on JSON-LD coniderations within VSS and to segue to Linked Building CG
Ted: as I mentioned, I think for on-board apps we may want to stick with JSON. I was seeing JSON-LD more for writing to cloud but the added structure should be considered even for consistency
Pieter: we have similar ontology
for describing building using SNN
... we industry and research input working on these
topics
... our model is purely RDF, we haven't looked into JSON-LD but
you can produce multiple syntaxes and support multiple query
mechanisms
... we have a full 3D geometry model, external and internal eg
by room and you can get back various information by room such
as temperature
... the core of the work is focusing on the RDF ontology for
the building itself
... it makes sense to align, at least our approaches
... WoT, Building both should be aligned
... about thing repository for discovery, that will be
important for us as well for representation of buildings within
a geographical area and building interactions
Ted: we are not doing standards work
on V2i/V2x but could see how having common data model and means to
access it that we are working on could facilitate generic applications that run across
different manufacturer vehicles to communicate with the underlying
vehicle.
... We can also see vehicle/building interactions through the WoT
not to mention being able to bring together these related but
disparaging datasets together for multitude of purposes.
Michel: there are certainly information points you will want to gather/query across vehicles, understanding state but also vehicle/building interactions for things like parking
Pieter: we have been restricting
ourselves to buildings only, not interacting with
infrastructure
... traffic agencies and other companies are looking at the
same technologies
... there is a huge potential in connecting automobiles,
infrastructures and buildings
... apart from garage parking it is somewhat dodgy
Daniel: true but there are a number of similarities dealing with legacy building/vehicles and different capabilities
Pieter: we are drafting a charter
to move forward as a W3C working group for standardizing
... we have not been aligning adequately with WoT but clearly
should
Sebastian: we have some experiences from some participants on smart appliance perspectives
Ted: what sort of vehicle/building interactions do people see besides interactions through WoT? Parking capacity and availability is the most obvious
Pieter: we get granular in
properties such as down to window manufacturer
... whether or not a building has parking spots available, you
would need to query an active building. so far we have only
been doing that for temperature
Armin: LPL is a sticky policy.
you present the user in some manner the privacy policy and
through this UI provide consent and personalize aspects
... when the data will be accessed for some specific purpose,
they will be authenticated and dataset returned from the query
may have some filtering/sanitation (eg anonymization) applied
for that specific party
... big question of course is what is consent, GDPR defines
several aspects
[slide 4]
Armin: you need to validate
someone checked a particular box
... it should not be mixed with any conditions for
services
... no legal text should be present
... use clear language, provide use cases for how the data
would be used
... the user has the right to revoke their permissions at any
point and it needs to be equally as easy to revoke
... it is not valid to say a condition of buying this car is to
accept a specific policy
Ted: previously we discussed how an owner might have consented to sharing data with their insurance company for example. Should a different driver use the vehicle they should be informed this consent exists and is immutable or potentially prompt them to make granular distinctions on how the data can be used.
Armin: that is probably accurate or it could be possible to provide granular override
Guru: say a rental agency owns a car, how would consent work, what is the expectation?
PatrickL: handling of the data is
often combined with the rental contract with the consumer
... if personal data is generated while the vehicle is rented,
the agency needs to abide by GDPR
... it becomes more complicated
Guru: based on feasibility...
PatrickL: yes and based on what data
Armin: if there is a contract you
do not need explicit consent
... if you ask lawyers they would prefer to err on the side of
caution
[back to presentation]
[slide 5]
Armin: consent can be captured by various technical means, no pre-checked boxes as that is not a deliberate act to give consent
[slide 6]
Armin: there has to be a
differentiation between processing purposes
... for each purpose, consent needs to be given
[slide 7]
Armin: article 12-14 of GDPR
contain the required consent information
... basically you have to show them data, due process, duration
it will be stored, recipients, withdraw option... etc
... the main and important thing is that in needs to be
conveyed in a clear and understandable way
... if the consent is not valid you are suscept to 20M EUR
lawsuit
[slide 8]
Armin: I represent this in
LPL
... what we have is a root element for the policy, set of
purposes defined and under them the information required
... the legal basis for consent, automatic decision making, who
is the data protection officer etc
... with this information we can make the required information
availabe in a structured, human readable (allowing for
internationalization), support for privacy icons
... differentiating between purposes, required or optional,
whether you can opt in or out and then all the data points,
recipients, retention etc
... it is important to distinguish that this prototype is not
fully vetted legally but a prototype </disclaimer>
[slide 10]
Armin: 1st iterations, VISM... Privacy icons
[slide 11]
Armin: there is a legal
requirement to provide icons and I propose specific icons for
purposes
... you need to provide link to privacy policy
... for consent we just use check boxes based on legal
basis
[slide 13]
Armin: how will it be processed,
anonymized, stored, who will receive it
... what we will do in future work is implement this
information more granularly
... psedonymization, audit log capability
... we want to prevent inference detection so information
cannot be used to fingerprint an individual
Daniel: regarding stickiness, as a recipient of the data how can I assert I have the right to use it, revokation etc. you just a portal on permissions?
Armin: it should not be hard with encryption and signature to impose
Arnaud: the law forces us to do
that
... the tool should not create the policy
... capture the consent
Daniel: the WoT people are having the same conversation. If I drive up to my garage, my car requests the door opens and door in turn requests lights go on, consent would need to be collected by car to give permission to share with the house
Armin: you are allowed to define which person or controller can access and that is part of the policy language
PatrickL: I am wondering how to
embed this information in the protocol in a good way
... as a developer if the purpose I have in mind for using the
data is ok
... I need to make sure I am acting in the right way. use cases
(purposes) can be open to some interpretation
Armin: I made it to represent high and low level purposes. individuals will not understand the thousand+ signals in the car
Ulf: I was wondering how this can
relate to our access mechanism - tokens to access signals
... maybe they could be used together
... it would be advantageous to link token to these
policies
Ted: I believe I can share with the group some details on a proposed Ford-MIT_alliance project. It involves enforcing policies for accessing information on-vehicle and sending it off board
PatrickL: service implementation could translate to permissions - a consent manager
Glenn: consent is more granular and contract could be broader
[slide 18 - Why layers?]
Armin: between manufacturer and you. we would define some sort of API to verify consent for a given purpose
Daniel: is there a protocol you have defined?
Ulf: user gives consent and it would be possible to invalidate a token thereby revoking application's access to information
Ted: two use cases, on and off-board and we need to also cover how to convey to data warehouses
Daniel: if I set a climate control preference for my Uber rides, I need for that to be able to follow
Ted: we will need to have this queryable to apps on the vehicle, to know what it case use on the car and what it can send off
Armin: I want to differentiate between in-vehicle and external processing
Glenn: a fleet example, a fleet buys a number of vehicles and given permission to data. fleet in turn arranges terms with driver
Ted: that should be doable outside scope of a consent system or perhaps within and could handle more complex cases. You may for example to allow a contracted driver to bring their insurance with them for a trip within a fleet owned vehicle, usage based insurance that would also want certain signals.
PatrickL: we should be able to handle additional parties such as what Ted described receiving additional information
Ted: we need to allow multiple apps to run concurrently to collect different information for different purposes to share with different parties, some might last for ownership of vehicle and others just duration of a trip
Daniel: problem will be UI to
convey the scenarios
... the communication flow gets complicated
... duration of how long that access can last and whether there
is revokation will vary
Armin: this architecture can handle that
Policy language considerations:
* understanding of need for ideally *one* policy language, mix will be interop/integration hell
* criteria for selection, any requires customization for given,
* defined needs
Ulf: not sure I agree, tokens can solve our needs without bringing this into specification
Ted: this does not need to be in the main signals specification[s] at all. What checks a given token is allowed to access is independent of the spec but worth looking into it. This is exploratory within the Business Group and could be a complimentary spec or maybe more of a guideline.
PatrickL: I can see it as part of the application registry ecosystem
Daniel: we want cross domain capability, take WoT for example. they have distributed registry
Tim: you cannot necessarily see
clear to adopting a policy language that is less than domain
specific
... what we can fall back to is what annotations make sense and
sent downstream and provide hooks
... yes it is complicated to capture consent but you need to
know how that data is collected in order to use it
... different policies might apply based on different
situations such as which driver
... need to differentiate between owner, manufacturer,
driver..
... there are ways to hang off of data model, JSON-LD
facilitates this
Benjamin: provided we can come up
with a digital identity for driver
... there are interesting edge cases with renters/usage
... we are maybe looking more from commercial side
... schema.org defines a number of classes and properties with
nice annotations. JSON-LD+ontologies
Michel: any thought on using eg LDAP for identifying the party accessing the information
PatrickL: so far we have been focused with in-vehicle access of applications based on tokens
Allen: what the Verifiable Claims
does is very similar to permissions
... another thing to understand is that it indeed verifiable.
it could be as simple as a digital signature or as complicated
as a proof
... there are various related services, issuer (eg passport),
verifier (border control)
... verifiable claims has a notion of portfolio, we use the
term profile
... there may be numerous activities you want proofs for
... the draft specification describes the types of permissions
you are discussing
Armin: is there architecture behind how you issue a claim?
Allen: yes, the spec covers issuing and verification
Armin: seems like something that can be solved with blockchain
Allen: yes, definitely possible
Ulf: this could handle security tokens as well
Allen: indeed
... you can imagine a world of tokens with verifiable
claims
https://www.w3.org/2017/vc/WG/
Ted: I have seen this as how to revoke permissions either tokens or private key to ensure parties no longer have access
PatrickL: I am not sure I want to restrict access to the data or only inform directory that governs controlling of data
<PatrickLue> We will have a break till 16:00
https://www.w3.org/Privacy/permissions-ws-2018/minutes.html
Why I was interested from our perspecitve - localization, UX, A11y
general purpose permissions UI that could be tuned to our purposes
Why a semi-common/consistent UX would be so beneficial - usage and mixed fleets
friendlier more intuitive UI will be a major distinguishing feature in
usage models. OEM legal departments would be pleased
bleak on expections of users' capacity to handle complicated/nuanced permissions regardles of UI
\emphasis alt means to follow up in more detail at later date
prompting - pertinent and action specific not blanket and not weeks/months in advance
Harjot: the majority of the
individuals were from browser vendors
... also major websites like NY Times
... there was optimism from them as well
... they are putting themselves in a worse condition of not
getting more granular consent to be able to generate ad or
other revenue
... you need to identify yourself for web services which is a
challenge for them. in vehicles you already have a license
plate and driver's license
... they want something akin to a password manager to represent
all the website relations and permission you have given
them
Armin: was this based on an architecture, policy language or other?
Harjot: influenced by GDPR
... this isn't related to automotive explicitly
... they were discussing if someone has a VR setup at home that
needs to analyze their environment
... did they give consent for location? if not and you can
deduce where they are then you need to
... much can be inferred from different sensors eg
accelometer
* JSON-LD for VSS: Ulf, Benjamin and Gregg - potentially others
* Policy Language exploration, leverage
* Consent - largely defer look at any PoC from LPL prototype, Caruso or other
* Liaisons/consults - passive with WoT, Linked Building CG, Verifiable Claims, JSON-LD
Daniel: quality of data is another important topic
Ted: agree
Daniel: are you getting it
directly from sensor, ECU, VSS...
... how about versioning and contributions?
Ted: versioning for VSS?
Daniel: yes and speeding up the process
PatrickL: for Thursday v2 I have
an outline to bring forward based on the last half year of
discussions
... with that I think we can put times down. goal should be
discussable and less fuzzy
<PatrickLue> adjourned