Re: Roving air quality monitor example data usage

Hi Rudi,

Thanks for reading and even more appreciate the response.

There certainly are benefits, more controlled and scientific, to having
fixed air quality monitoring. There are also some to roving as it can
cover a much wider area for instance. It is a real world example as
presented during the IoT call although augmented with additional
sensors not part of the automobile's original equipment.

https://www.w3.org/2018/11/20-auto-minutes.html#item01

I have not proven how much could be reasonably discerned about air
quality from performance statistics and other available data points but
believe it may be possible to draw some inferences. Based on location
and heading information you could account for some of the variables
like road incline affecting performance or instead compare to past
readings at the same place. External weather and other data can
potentially be factored in.

Particulars aside the merits of the example are more in the abstract. I
want to touch on those before getting to your excellent scenarios and
informative and amusing user responses.

At the higher level this is an unlikely assortment of data points to
aggregate especially in the sampling methodology desired (timed, curve
algorithm, other) and therefore doubtful what OEM would collect in
their warehousing. Best handled via a specific sampling application
permitted to run on head unit. 

As noted it would also be significantly better data with aftermarket
sensors added. The question then is how, provided some OEM may be
inclined, to integrate additional data in VISS (current or next) which
relates to registry topic in WG. There are many other possible
aftermarket sensor scenarios. Another example would be tire
manufacturer specific tpms which may be able to provide other data such
as per wheel balance and vibrations to an app on head unit from the
same tire manufacturer and/or a common, generic wheel maintenance
solution. This tire maintenance example has similar essential needs as
the air quality one. Specifically the combination of specific oem and
aftermarket signals best sampled on-board, edge computing, before
sending to cloud entrusted to a particular organization for specific
purpose[s] and clear, including can be referenced later by URI, terms.

As to your thought out scenarios, to be determined how best to present
and certainly would be wise to try on some test audiences. I defer to
usability and legal experts on what to provide in the interface but we
can try it out some, your wording was great.

Scenario 1 is too detailed and confuses user as you note, 2 too vague.
An enhancement to scenario 3 would be ability to expand on various
details. This would go beyond just providing details on which specific
signals would be collected but about the organization, email individual
the link to where in their profile one can alter/revoke permissions at
a later date, and whatever other provisions thought up and determined
useful.

Here is a possible web UI with [links] to more details on that topic or
if appropriate a user interface. Links probably handled as new tab or
pop-up that when closed brings you back to the initial page.  I'm not a
UX expert by any means. All content possible should be static, local
caopy from app install or a caching proxy, submitting changes to cloud
or car as appropriate.

[Foobar University Researchers] would like to collect [location],
[various vehicle performance and other sensor data] for the purpose of
[air quality monitoring]. With the exception of location, no personal
identifying information (driver, vin) is collected. You may [review
their terms] and [change your permission] at any point.

Provide permission [Yes/No] (previous selection set if applicable)

Footnote and various pertinent links such as benefits and legal
agreements, way to send user details by email/sms/cloud, ideally from
profile instead of having to enter on a form.

===

Getting into benefits as a direct consequence of and motivation for
giving permission would be ideal to try to state and include in brief
on the main page with a more nuanced explanation available. Done well
will help get more people besides those who just like to click yes to
participate and many may even understand to whatever level of detail
makes them comfortable what they are agreeing to.

On Fri, 2018-11-30 at 16:07 -0800, Streif, Rudolf wrote:
> Ted,
> 
> This is a great example albeit not so much for air quality data but
> for the complexity of policies.
> 
> Briefly addressing air quality data: I think that is better measured
> by putting the relevant sensor into the areas of interest (cities,
> parks, etc.) then using vehicles, as other environmental data has to
> be measured e.g. wind speed and direction. However, that data is
> typically not provided by a vehicle sensor (it's also not really
> feasible to measure unless the vehicle does not move). The set of
> data you are mentioning, only provides information on how much that
> particular vehicle contributes to air quality. To get a good air
> quality measurement one would need pretty much the data from all
> vehicles in that particular area for it to be somewhat reliable.
> 
> Looking at the policy: how would that be presented to an end-user?
> The example has 10 sensor data points.
> 
> Scenario 1: "Dear Driver, MIT's Environmental Institute would like to
> collect the following data form your vehicle to assess the air
> quality in Boston: rain intensity, air temperature, engine mass air
> flow, long term O2 trim 1, O2 Senors WR, O2 Sensor Alt, longitude,
> latitude, altitude. Do you agree to collecting that data? Yes/No"
> 
> Driver 1 to MIT: "I appreciate the detail but you lost me at 'engine
> mass air flow' but I do understand longitude, latitude and altitude
> and I am not sure if I want you to know where I am driving."
> Driver 2 to MIT: "What the ..."
> Driver 3 to MIT: "Of course, it must be for a good cause, I trust MIT
> and I always click on Yes anyway."
> 
> 
> Scenario 2: "Dear Driver, MIT's Environmental Institute would like to
> collect data from your vehicle to assess the air quality in
> Boston. Do you agree to collecting that data? Yes/No"
> 
> Driver 1 to MIT: "I am environmentally conscious but could you please
> tell me what data you are collecting?"
> Driver 2 to MIT: "Another one of these spy apps..."
> Driver 3 to MIT: "Of course, it must be for a good cause, I trust MIT
> and I always click on Yes anyway."
> 
> 
> Scenario 3: "Dear Driver, MIT's Environmental Institute would like to
> collect data from your vehicle to assess the air quality in Boston.
> The data includes how much your vehicle contributes to the pollution
> as well as the current position of your vehicle and environmental
> information such as current air temperature and if it is currently
> raining and how much. We do not collect any personally identifiable
> data such as what car you are driving, vehicle identification etc.
> All data is collected anonymously  Do you agree to collecting that
> data? Yes/No"
> 
> Driver 1 to MIT: "Good idea. Deal!"
> Driver 2 to MIT: "How does Google define 'anonymous' again?"
> Driver 3 to MIT: "Of course, it must be for a good cause, I trust MIT
> and I always click on Yes anyway."
> 
> 
> For me the most important part of all policy systems is presentation
> to the user. For this example, the user does not have any direct
> negative experience when not allowing the collection of the data.
> However, there are applications that provide the user with a benefit
> but sometimes the benefit does not seem to be directly related to the
> data accessed. These examples are even more complicated, as now the
> user should also be given information on how declining the request
> would impact the benefits.
> 
> :rjs
> 
> On Wed, Nov 28, 2018 at 1:11 PM Ted Guild <ted@w3.org> wrote:
> > The scenario I had in mind stems from a hasty conclusion I drew
> > when I
> > saw an early prototype of VISS done by NewSky and Baidu on city
> > buses
> > in China. The data points on the active city maps was showing a
> > small
> > number of data points including location and engine temperature. I
> > wondered if they were deducing air quality based on how rich or
> > lean
> > the engine was running. They weren't, it was a random selection of
> > data
> > points. We heard last week on the Working Group call however where
> > one
> > of the many IoT uses of vehicles is as a roving air quality sensor
> > with
> > the aid of aftermarket sensors likely measuring parts per million
> > of
> > pollutant particles. There may be inferences that can be drawn in
> > the
> > absence of such a specific sensor based on the signals information
> > available.
> > 
> > One of my children suffer from asthma and impacted by air quality
> > so as
> > a parent, I would not only wish to learn overall air quality where
> > I
> > live but pockets that might have worse quality to avoid. I would
> > also
> > be willing to participate in the data collection provided the
> > service
> > and researchers are not collecting any identifying information
> > about
> > me.  
> > 
> > For this exercise we will provide verbose policy example, who is
> > giving
> > permission to collect which data to be shared with which parties
> > for
> > what specific purposes. Later we can take our examples and work
> > them
> > into an actual policy language format.
> > 
> > I would be willing to provide information on engine performance, O2
> > measurements, my location, rain, temperature, etc to designated
> > researcher who in turns makes the data available realtime for air
> > quality reports. 
> > 
> > There may be additional data points that can help provide answers
> > on
> > air quality that are not obvious to me. These seem plausible and
> > sufficient for this exercise. Falling rain cleans the air and is
> > certainly a factor as is humidity that can exacerbate.
> > 
> > >From VSS here are some potential data points that might contribute
> > to
> > such a use case:
> > 
> > Signal.Body.Rainsensor
> > 
> > Signal.Body.Rainsensor.Intensity
> > 
> > Signal.Drivetrain.InternalCombustionEngine.AmbientAirTemperature 
> > 
> > Signal.Drivetrain.InternalCombustionEngine.MAF (Grams of air drawn
> > into
> > engine per second)
> > 
> > Signal.OBD.LongTermO2Trim1
> > 
> > Signal.OBD.O2SensorsWR
> > 
> > Signal.OBD.O2SensorsAlt
> > 
> > Longitude Latitude and Altitude.
> > 
> > -- 
> > Ted Guild <ted@w3.org>
> > W3C Automotive Lead
> > http://www.w3.org
> > 
> 
> 
-- 
Ted Guild <ted@w3.org>
W3C Automotive Lead
http://www.w3.org