<billroberts> just persuading webex to start. Will be with you imminently I hope!

Emily shares screen

Responsible use note feedback and next steps

Fran: Emily, Jo, Rob and I worked on this document
… Ed as well, a diverse group of contributors
… we want to share the note at a high level and solicit feedback
… we also want people to promote this note to a wider audience
… please direct feedback to github
… we note we have a western bias and want more global input, aided by your sharing of the document
… spatial data has special characteristics requiring careful treatment
… situations and data points vary but the principles are general
… this is for end users, developers and those using the data

<brinkwoman> Shared link: https://w3c.github.io/sdw/responsible-use/

<brinkwoman> Published FPWD is at https://www.w3.org/TR/responsible-use-spatial/

Fran: we want to give a quick tour, time permitted
… why spatial is special, existing [legal, other] frameworks, principles to follow
… this audience already understands the importance of this, new concept to others
… we explain some of the legal frameworks which are as mentioned western oriented, eg GDPR, CPAA...
… we want more geographic diversity on frameworks
… concepts like right to access data, right to be forgotten are explained in the note
… besides government there are corporate, group and other ethical frameworks
… UNICEF has a fairly large one for operating their drones evaluating developing areas
… most frameworks do not address spatial data in detail though

Emily: the note is aiming to show how to use location data ethically and responsibly

<PeterR> lots of chop

<brinkwoman> better

Emily: we wrote from three perspectives, user, developer and regulator
… these [slide] are the main values/principles we wanted to cover
… data collection should be voluntary, there should be clear consent
… we added some guiding questions: do I need to store the location data? if so for how long?...
… from a user perspective Rob came up with some helpful icons
… from regulators perspective we encourage them to have bar as high as possible and consequences for breaching
… this is still an early version and expect considerable changes

Chris: one principle from GDPR I didn't see covered is portability
… portability to your own data, to be able to bring your data with you to new platforms
… this should be part of the ethical use

Fran: agree, it should be there

Jo: missed in review

Chris: that's another beer you owe me :)

Fran: any other questions for now?

Linda: how widely do you want it shared at this early stage?

Emily: as widely as possible

Jo: most of the points we wanted to cover are there, certainly more to add but want to start the conversation

Chris: one of the things I found helpful about GDPR was their guiding principles and clear, separate set of individual rights

Fran: users generally don't know their rights
… this should be governed more by ethos than law

Jeremy: great work bringing this to FPWD
… timing is great and intend to leverage for IoT data project proposal
… especially important with smart home devices
… I'll provide feedback I get

Fran: applying to specific situations will be beneficial

Jo: Ted, PING pinged me on W3C Auto

<RobSmith> Christine Runnegar

Ted rambles somewhat sensically on scope of W3C Auto work, what belongs in charter spec or elsewhere, group's best practices work, intent to tie in this responsible use document issue 358

Discussion on defining Convenience APIs with OGC Architecture Board members

Linda: Chuck can you introduce yourself and give us update on OAB Convenience API

Chuck: I'm concerned we are defining concepts without broader context, including these separate Convenience APIs
… we have a division between data provider and user perspectives
… a Convenience API is similar to analysis ready data
… provider has to deal with unanticipated user. user wants as few variables as possible enabled by API
… we are not discussing necessarily humans performing the analysis

Clemens: we mention Convenience API in our Best Practices document and raised issue recently
… these are very broad, generic APIs
… on the web, APIs are usually more specific for a given problem

Jeremy: Convenience API useful for coverage or feature. consumer versus provider perspective helps
… they are typically tailored to specific uses
… as Clemens said, most things being created at OGC are convenience APIs

Michael: these APIs are for making things simpler and easier, not necessarily tailored to specific use
… they make interaction with data easier and improve understanding
… they are usually designed towards the underlying data
… for a specific set of use cases
… there are differences with generic APIs, convenience APIs more structured to the use cases

Chuck: consider API features and coverages to EDR model
… there may be processing of data before exposing through API

Bill: problem with purpose specific APIs is discovering them
… what are the most popular use cases and how are they addressed with a generic API
… they could be simple mappings or documentation on how to use the generic for specific uses

Chuck: that is the hard part of the problem. it is great to say something is user focused but you need clear understanding of what their needs are
… how much can you standardize a convenience API if it is provider focused instead of user centric?

Chris: issue is what is in the eye of the beholder - perspective being addressed
… data can be discrete or categorical. where do you draw dividing lines in a modular approach?

Chuck: proper scoping helps address it

Linda: a key part is convenience API is for a set of use cases, making it easier for non-experts to use the data

<Zakim> ClemensPortele, you wanted to talk about publisher/user centric

Clemens: there are just different types of users
… drawing borders is a fine line, not necessarily user or provider specific perspective

Chuck: an API can simplify beyond the modules used to define it
… API can hide considerable detail
… need clear understanding of space being defined

Linda: do you have draft definitions?

Chuck: I have some ideas but wanted to get input before putting them down

Jeremy: hope discussion today has informed your thinking. we would be happy to review candidate definition

Chuck: I want to take convenience APIs, EDR, ADE, other APIs and put them together in some abstract architecture and see how they come together
… goal is to create a federated cloud for analytics, how does each component play into that?

Jeremy: one of the things we wanted to do from Chairs perspective, Linda, Ted and I took another pass at refining the charter
… moving from an Interest Group to Working Group
… we know we are not in 2020 but look past that in URI

https://w3c.github.io/sdw/roadmap/charter-2020.html
… scope was refined, deliverables moved around a bit
… plan for Time OWL is to roll extensions into main spec

Linda: any final anouncements?

Action: Chuck to bring definitions back to group

<trackbot> Sorry, but no Tracker is associated with this channel.

RobS: I've been working in OGC testbed 16 and published a video since last meeting

<RobSmith> https://www.youtube.com/watch?v=j9ayV2_gskY

<Zakim> AndreaPerego, you wanted to ask about updates on SDWBP wrt DCAT2

Andrea: is SDWBP being updated to try to fill in some gaps with DCAT2?

<brinkwoman> https://github.com/w3c/sdw/issues/1084

Jeremy: Clara has that within her scope, please provide feedback in github on examples you want to see clarified
… you can create a patch for consideration?

Andrea: yes