See also: IRC log
<jtandy> Agenda is at: https://www.w3.org/2015/spatial/wiki/Agenda_BP_VM_May_2016#Main_agenda_.28DRAFT.29
<jtandy> Looks like the Goto meeting is started ...
<jtandy> scribe: jtandy
<scribe> scribe: Clemens Portele
<scribe> scribenick: ClemensPortele
<jtandy> https://www.w3.org/2015/spatial/wiki/Agenda_BP_VM_May_2016
jtandy: will not be able to work
through all of this
... Work on spatial ontology will be spin off to a separate
activity, not this meeting
<jtandy> https://www.w3.org/2015/spatial/wiki/BP_Narrative_2
<jtandy> (revised flooding scenario)
<AndreaPerego> +1
jtandy: We should go through the
narrative and identify where we have best practices,
recommended practices or gaps
... a bit of a challenge to get stuff into the BP
document
... ... are we writing them from an SDI user/provider
perspective, from the perspective of someone not familiar with
SDIs, etc.
... anything else for the agenda?
(silence)
<AndreaPerego> +1
<Payam> +1
The proposed agenda is approved
<BartvanLeeuwen> hi
jtandy: may stop the meeting for a while a split into subgroups
<jtandy> original narrative
<jtandy> https://www.w3.org/2015/spatial/wiki/BP_Narrative
jtandy: questions was "how do
people should contribute"? Difficult with the first
narrative
... created second version of the narrative
<jtandy> who has read https://www.w3.org/2015/spatial/wiki/BP_Narrative_2
<Linda> -1
-1
<BartvanLeeuwen> +1
<AndreaPerego> +1 (but partially)
<BartvanLeeuwen> I did find it rather technical
Payam: what do want to achieve today? what can make our day productive?
jtandy: ensure that the (currently 9) steps cover everything or do we need a different approach. Identify where we can get best practices from and who can lead on those?
Payam: Do we go through them one-by-one or do we split?
jtandy: Not sure, need to see.
Let's first go through the list in the group
... overview of narrative 2
... ... context at the beginning (no details)
... regarding the comment on this being technical, this is
meant for a technical audience
<jtandy> question: is it right to pose this as a technical best practice / scenario
<jtandy> +1
+1
<Linda> +1
<jtandy> I'm hoping that it addresses the needs of the BP audience
<AndreaPerego> +1 - but shouldn't we have in mind also a non-technical audience?
<Payam> +1
<Linda> Bart, could you explain why you found it technical?
<joshlieberman> flooded area?
Linda: maybe avoid domain expert language?
<jtandy> terminology: avoid terms like "inundation extent" in favour of "flood extent" or "how far did the water reach"
Payam: maybe create two versions
of the same story, one more technical and one less
technical?
... ... today we would work on the technical one (narrative
2)
<jtandy> payam: suggests we have a non-technical summary of the scenario as a complement to the technical version
<BartvanLeeuwen> I had the impression that there were some very domain specific terms in there
<Linda> I agree Bart
<jtandy> proposed: we have a non-technical overview of the scenario to complement the technical version
Payam: Bart's comment is related to the terminology discussion earlier
<BartvanLeeuwen> I had to lookup some specific weahter / flooding related terms
<jtandy> +1
<Linda> +1
+1
<AndreaPerego> +1
<Payam> +1
RESOLUTION: we have a non-technical overview of the scenario to complement the technical version
<jtandy> Linda: avoid domain specific terms in the technical version too
<jtandy> +1
<Linda> +1
+1
<AndreaPerego> +1
<Zakim> AndreaPerego, you wanted to make a general comment on "flood prediction" as a sensitive subject.
AndreaPerego: flood prediction is
a sensitive subject, eg may have an impact on insurance
rates
... ... do we need to take this into account (potential misuse
of the information)?
jtandy: everything that may have economic impact will be a sensitive subject. The narrative is not about publishing authoritative information, just someone who wants to help.
<AndreaPerego> +1 - agreed.
jtandy: The waterboard (for example) would validate the data before using it. Maybe talke this into account later in the story?
<joshlieberman> The concern may not just be whether data is authoritative, but whether the Web application leads people to appreciate what the term "100 year flood" means for them.
jtandy: points to the text in step 8 that touches on the subject
<jtandy> intent (of SDW): web publishing is one in such a way that the connections between data can be followed
<jtandy> (said joshlieberman)
joshlieberman: even if we do not use technical terms, we still use technical concepts that need to be linked to from the data
<jtandy> joshlieberman: not so much data, but connections between data and its meaning or implication
jtandy: better look at a certain flooding event, not the long-term flooding prediction
Linda agrees
<AndreaPerego> +1
jtandy: the story is just a
vehicle to illustrate what we are doing
... step 1
<BartvanLeeuwen> +1 to stick to a single event instead of prediction
jtandy: coverage data suitable
for use in web applications
... issues like versioning, volume, need for data extraction,
bulk download for offline analysis
... quite a common scenario
<AndreaPerego> +1
<Linda> +1
next step - turn coverage into vector features
jtandy: how do I publish the
admin area information on the web?
... Geonovum testbed topic 4 is related
... support for multiple formats including those for geo
experts
... how far do we want to pursue Linked Data?
... also need to cover the feature / real-world thing
subject
Linda: sounds like a large chunk (covers many BPs)
<joshlieberman> We use the term feature, but most Web developers think that's some capability of their software. Real world thing is more evocative for them, so we'd need to do quite the education job to switch
<AndreaPerego> +1 to josh
jtandy: need to decide whether we recommend only one approach?
<joshlieberman> Argue that there may be two categories of tasks with Web technology -- link to data over the Web and use the Web to bring data together
<jtandy> ClemensPortele: "there's not a one-size fits all" solution
<jtandy> joshlieberman: there's a set of sizes ...
<jtandy> joshlieberman: "small" = linking _to_ something and "large" = integrate information together 'on the web' without needing to download stuff for offline work or use some obscure API
<Linda> +1
jtandy: agrees, some will use the
SDI as a starting point, others come from a different starting
point
... ... same best practice applies, just different approaches
to the same outcome
<AndreaPerego> +1
jtandy: "small" would mean to publish resources with URIs?
joshlieberman: yes, fine-grained URIs. Or for queries to access 500 features to put them on a map. Both are needed
<jtandy> joshlieberman: "does the API let me make a single request to get 500 Features - rather than 500 fine grained requests, each with a URL of a Feature"
jtandy: what is the ecosystem for using spatial data on the Web? Using the Browser as the platform for application?
<jtandy> using data on the web: (i) referencing a resource that someone else has published via URL in _my_ data, (ii) integrating multiple data sources using 'Web engines' as application runtime environment
jtandy: classic process of downloading data and processing it in a GIS is not what we are looking at
<AndreaPerego> Does the notion of "Web engine" includes machine-to-machine use cases?
jtandy: ... our focus is more the processing on the Web
<jtandy> Yes to @AndreaPerego
<AndreaPerego> Thanks!
<jtandy> another classification of users: can our intended user base by classified by ‘those who are publishing information about individual Features’ and ‘those who are publishing information about collections of Features (e.g. as a dataset) … the former need to rely on the platform into which they publish to make their information discoverable [& accessible] and to expose provenance and licensing information; e.g. Twitter search API, search engines etc.
<jtandy> ... another Small and Large perspective
<AndreaPerego> Should we also consider the (integrated) use of third-party / non-authoritative data here? E.g., OSM, Geonames.
joshlieberman: part of the web is
others harvesting individually published information in large
amounts
... small scale = publishing tweets from the area / with
reference to the flooding
<jtandy> joshlieberman: "Small" = create a map with a pin on for the location of each #flood geo-located tweet ... just links
joshlieberman: large scale = merging this information with the admin units etc and analysing this to identify discrepancies etc
<jtandy> are we writing best practices for the people _using_ social media, or the social media platform providers to make sure the _aggregate_ set of social media can be exposed as spatial data?
joshlieberman: BPs should be helpful for platform providers
<jtandy> interpreting joshlieberman: we are writing best practices for social media platform providers - and _any_ platform provider that has spatial information
<jtandy> ... implication is that that might drive collection of particular information from users of the platform
jtandy: when thinking about crowdsourcing - we are more focussing on the platform that is used for crowdsourcing
joshlieberman: but this will be also about what the platform users want
Linda: agrees that the platform is the main focus
joshlieberman: but if the SDI has all the URIs for locations, Twitter users could use them in tweets without Twitter doing anything
<jtandy> "small" size of problem = encouraging people to use URLs for the things they might Tweet about
Payam: sees it a bit different, it is also about how people could send tweets (or publish data) so that it can be used easily by others
jtandy: The Web is the platform in this case?
<jtandy> interpreting Payam's comment: crowdsourcing information ... people will use the _web_ as the data sharing platform- either directly as Web resources, or via an App or some other platform
<joshlieberman> Here is a case: someone might tweet: #flooding the water is 2 feet deep at my house. Analysis requires parsing 2 ambiguous statements. Alternately: #flooding [2 feet] @{link to my house feature}.
<jtandy> (people might publish information about their house flooding in a blog entry; native HTML perhaps)
Payam: cannot tell the Twitter user how to write tweets, but apps may provide a framework to make aggregated data reusable
<jtandy> payam: we're targeting the part of the story that enables the aggregated set of information on a platform to be access from / published to the web in a consistent way
<jtandy> there's the special case when people write HTML directly- but the majority of cases, people use a platform to do that
joshlieberman: usually there are
lightweight means to help interpretation (eg the use of
hashtags in tweets)
... what is the minimum that people could do to make their
contribution more usable
<jtandy> joshlieberman: "what's the minimum we could ask people to do to make their [data] contribution more usable ... e.g. use a URL for the thing you're talking about!"
jtandy: so a recommendation would be to use a format that supports links
<jtandy> our BPs will include "use URLs when you talk about things"
<jtandy> joshlieberman: so we need to make the URLs for things easy to find
<jtandy> joshlieberman: ... e.g. small / tiny and easy to type
<jtandy> we're seeing Twitter (etc.) "just" as a Platform Provider that has spatial data that should be on the Web ... so our advice is targeted toward the Twitter API developers
jtandy: anything else on crowdsourcing?
<Zakim> AndreaPerego, you wanted to ask if we should also consider the (integrated) use of third-party / non-authoritative data here? E.g., OSM, Geonames.
<Linda> example of (pretty) tiny urls for locations: http://w3w.co/pumpkin.dwarves.issuer
AndreaPerego: also the cases where "authoritative" data may not be available
jtandy: so not just consider the publication of government data, but also other data like OSM or geonames
<jtandy> AndreaPerego: suggest linking stuff to non-authoritative URLs e.g. geonames or OSM ... non-official information
<BartvanLeeuwen> it sounds like a discussion on 'crowd truth'
<AndreaPerego> :)
ClemensPortele: the result is the same, the important aspect is that we can link to location using URIs
joshlieberman: Twitter API has data structure for places
<jtandy> should we use the term Feature?
jtandy: let's go back to the "feature" topic
<jtandy> joshlieberman: confusion from IoT - folks often mean a software or IoT device capability
joshlieberman: divergence on terminology (feature = 'software capability' for many)
jtandy: should we impose the geo terminology on the world?
<jtandy> joshlieberman: we should have a "general feature model for dummies section" if we're going to use the term Feature
<BartvanLeeuwen> -1 to feature its a spatial expert thing
<jtandy> ClemensPortele: try to avoid geo-jargon where possible
<AndreaPerego> +1 to Clemens & Bart
ClemensPortele: at the same time we need to mention it to be clear to the geo experts
<AndreaPerego> BTW, "feature" was intentionally excluded from LOCN for the same issues.
<jtandy> Proposed: use alternative term to Feature in most of BP doc ... use the term Feature just once (to keep spatial experts clear on what we mean)
<BartvanLeeuwen> +1
<jtandy> +1
<Linda> +1
+1
RESOLUTION: use alternative term to Feature in most of BP doc ... use the term Feature just once (to keep spatial experts clear on what we mean)
<AndreaPerego> Quoting: "If you're a geospatial dev, AJAX is not a domestic cleaning product. A polygon is not a dead parrot." -@open_data #LGD14 #geospatialhumour
<AndreaPerego> :)
<jtandy> :D
<jtandy> what about SpatialThing?
<jtandy> joshlieberman: real-world Thing is quite evocative ... but doesn't cover the non-geo cases
<jtandy> Linda: spatial object in Geosparql
<AndreaPerego> I think "spatial thing" is generic enough to be understood by most people.
<jtandy> ClemensPortele: this is the geometry
<jtandy> ClemensPortele: SpatialResource?
<jtandy> we need a term for "a thing that has location and a URI"
ClemensPortele: not necessarily "has location", but "related to a location" (?)
jtandy: (cites what some of the existing vocabularies have used)
AndreaPerego: LOCN avoids this, but using only the concrete terms without restricting their use
<jtandy> joshlieberman: in GeoRSS we used OWL Thing > Spatial Thing > Feature > Geometry ... but hey
<jtandy> schema.org uses "Place"
joshlieberman: for many linked to point locations, but in general are meaningful term
<jtandy> joshlieberman: would like to use Place- very useful for geo-humanities ... but often related to just a point location ... but we could address this in our definition
<BartvanLeeuwen> I think not spatial people will talk about points / places anyway
jtandy: need to keep in mind that spatial is more than geo
<AndreaPerego> +1 - e.g., geometry as the "shape" of a thing.
joshlieberman: geographers use "place" often as a synonym for "feature", not "location"
<jtandy> Proposed: we use the term SpatialThing because it has 'provenance' of over a decade
<jtandy> joshlieberman: quite obscure
<AndreaPerego> Just "thing".
joshlieberman: "real-world thing"?
<jtandy> Proposed: we use "real-world Thing" or sometimes just "Thing" in place of the term Feature
<AndreaPerego> +1
+1 (at least we can try if it works)
AndreaPerego: are abstract things like computer drawings included?
<jtandy> noting that we mean 'real-world' as in the 'universe of discourse', which should include fictional and abstract concepts
<jtandy> AndreaPerego: need to be more than "things we can touch" - need to cover abstract concepts too
<jtandy> ClemensPortele: like cadastral parcel
<jtandy> AndreaPerego: the notion of 'real-world' could be confusing - so our definition needs to make sure its clear that we also include abstract stuff
<jtandy> joshlieberman: let's use 'real-world Thing' with the disclaimer 'imaginary', 'abstract' etc.
<AndreaPerego> +1
<jtandy> joshlieberman: as per Feature, it may not have representation - but it always has identity
<AndreaPerego> +1!
<jtandy> proposed: we use "real-world Thing" or sometimes just "Thing" in place of the term Feature; with caveat that it includes abstract / imaginary / fictional entities ... as per Feature, it may not have representation - but it always has identity
<AndreaPerego> +1
<jtandy> +1
<jtandy> (representation implies geometry etc. ... not the wider Web term)
+1
<Linda> +1
<AndreaPerego> "embodiment" (equally obscure)
<jtandy> Linda: geometry or a link to a location
<Payam> +1
<joshlieberman> +1
RESOLUTION: we use "real-world Thing" or sometimes just "Thing" in place of the term Feature; with caveat that it includes abstract / imaginary / fictional entities ... as per Feature, it may not have representation - but it always has identity
(short break)
<jtandy> [returning to the meeting at 13:30 utc]
(starting again)
jtandy: let's get back to the narrative
step 3
jtandy: take SDI data and do
something useful with it
... covers spatial analysis, identifiers to features,
linking
... do we need to discuss spatial analysis or just assume
he/she is using some library
<jtandy> do we need to talk about the spatial analysis? or just say that our developer is "using a library"
<jtandy> Linda: the latter
joshlieberman: different persons would use different terminology (eg the spatial analyst may use "spatial join")
<jtandy> joshlieberman: an spatial analyst calls this "a spatial join"; a web developer might says they are "integrating datasets" or combining two sources of data ...
<jtandy> ClemensPortele: a 'mashup'
<jtandy> joshlieberman: use both terms in our doc to appeal to both types of users
<jtandy> question: is there a specific javascript library we can cite?
jtandy: (walks through step 3 and the BPs referenced)
Linda: Are there overlaps between the steps?
jtandy: not yet a proper analysis, but there is overlap
Linda: Should we assign work for these steps?
jtandy: good idea. What we are looking for is how to figure out you would do it with a real-life implementation
Linda: ... point to existing implementation(s)
jtandy: Yes, but those may not exactly fit the flooding scenario
<jtandy> two tasks then: (i) point to existing implementations, (ii) frame those implementation patterns in the flooding scenario
<jtandy> payam likes the idea of creating a full example - e.g. for publication in GitHub ... and then taking code snippets for the BP doc
<jtandy> ... but always being able to reference a full example ... and hopefully, the original source implementation that our example apes
<jtandy> "this example is derived from what they did over there"
<Payam> http://environment.data.gov.uk/flood-monitoring/doc/reference
<Payam> Environment Agency Real Time flood-monitoring API: Environment Agency Real Time flood-monitoring API
<jtandy> unlikely to find implementation examples all in flooding domain- need to see the implementation patterns we want people to use and convert the subject to flooding ...
joshlieberman: often it may be difficult to point to existing JavaScript code that implements a best practice
jtandy: some examples will exist (see the coverage work eg in step 7), often from a different domain
<jtandy> joshlieberman: key issue for river gauge datastream is about pulling together information from the sensor and the location data in the SDI (linked geometries) and 'mash' those up in an application
<jtandy> (this is the "Large" type of usage)
<jtandy> scribe: Linda van den Brink
<jtandy> scribenick: Linda
Payam: does Metoffice do something like the environmental agencies ie publishing their data as API?
jtandy: no
<joshlieberman> The US has some "services" but mostly graphical -- http://water.weather.gov/ahps/about/about.php
jtandy: in terms of work on the
first 3 narrative parts...
... do we want to give clemens nr 2?
Linda: makes sense
<joshlieberman> e.g. the API's may only be as far as RSS: http://water.weather.gov/ahps/rss/forecasts.php
<scribe> ACTION: Linda to ask Clemens to provide an example for narrative item 2 [recorded in http://www.w3.org/2016/05/03-sdwbp-minutes.html#action01]
<trackbot> Created ACTION-163 - Ask clemens to provide an example for narrative item 2 [on Linda van den Brink - due 2016-05-10].
<joshlieberman> I'll need to depart as well. Apologies. I can do some work on #7
<joshlieberman> bye
<AndreaPerego> +1
jtandy: the way examples are used in the narrative_2 these are technical tasks that allow us to illustrate the best practices, yes?
+1
<AndreaPerego> +1
<jtandy> +1
<scribe> ACTION: joshlieberman to work on narrative item 7 [recorded in http://www.w3.org/2016/05/03-sdwbp-minutes.html#action02]
<trackbot> Created ACTION-164 - Work on narrative item 7 [on Joshua Lieberman - due 2016-05-10].
<AndreaPerego> yep
jtandy: AndreaPerego, do you want to discuss anything before you leave?
AndreaPerego: no, it was quite
productive
... Am looking how I can contribute. Maybe something about
metadata?
jtandy: it's not explicit because metadata is embedded in all of these things
AndreaPerego: it's mostly about the data
jtandy: but we have to publish the metadata anyway. It's necessary for us to publish some geodcat-ap stuff and a landing page with schema.org
AndreaPerego: it's part of number 1 I think
Linda: yes, I think it should be somewhere in the beginning
jtandy: let's add it to item 4
AndreaPerego: agrees
<scribe> ACTION: AndreaPerego to add a section about publishing metadata to item nr 4 [recorded in http://www.w3.org/2016/05/03-sdwbp-minutes.html#action03]
<trackbot> Created ACTION-165 - Add a section about publishing metadata to item nr 4 [on Andrea Perego - due 2016-05-10].
AndreaPerego: the opensearch and geo extension are more about data?
jtandy: yes, about searching
through the data
... also keen to pick up on making info available for search
engines to index.
... also look at the work done within Geonovum testbed topics 3
and 4 on this.
AndreaPerego: also we are now working on mapping geodcat-ap to schema.org
jtandy: should we have the biweekly SDW BP subgroup call tomorrow?
Payam: we could continue this discussion
<AndreaPerego> +1
+1
jtandy: so tomorrow we'll
continue to work on these narrative parts and try to allocate
them to people
... about Bruce Bannerman's email: should we try to also
include some usage? My concern is this could mean we could
never finish the work.
... if we try to describe in our BP how people should use
spatial data
<jtandy> see email response to Bruce here: https://lists.w3.org/Archives/Public/public-sdw-wg/2016Apr/0104.html
<jtandy> potential data usage examples:
<jtandy> * web developer uses inundation coverage data to build a web app that
<jtandy> returns discrete (vector) Features for inundation areas
<jtandy> * web developer determines which administrative areas 'touch' inundation
<jtandy> areas
<jtandy> * emergency teams prioritise critical infrastructure to protect by
<jtandy> identifying categories of assets that are 'within' inundation areas - or
<jtandy> care-homes to assist with evacuation
<jtandy> * emergency teams determine hazard exposure by requesting water depth at
<jtandy> coordinates of critical infrastructure
<jtandy> * section (5) illustrates combining census data that is geocoded by
<jtandy> administrative areas with the administrative areas that are affected by
<jtandy> inundation
<jtandy> * emergency teams create the evacuation plans; refuges and safe transit
<jtandy> routes- no doubt a complex piece of GI analysis
<jtandy> * media and news agencies use the evacuation plans to build simple web
<jtandy> applications- e.g. using reverse geocoding from the geo-location provided
<jtandy> by a user agent to find the administrative area they are within; then
<jtandy> finding the associated evac plan ... and displaying the refuges / transit
<jtandy> routes on [web] maps
<jtandy> * emergency teams (for example) using social media reports of flood extent
<jtandy> observations to track the flood impact in real time
jtandy: in my response I made a
list of potential usage
... lots of things we could do but worried it could be too much
work.
<jtandy> worried that including usage examples will be too much work
AndreaPerego: agrees
... getting spatial data on the web is the first step to
tackle. This would be a second step.
jtandy: we could prioritize: data publication first, add usage examples after.
<AndreaPerego> +1
+1
<jtandy> +1
<jtandy> https://lists.w3.org/Archives/Public/public-sdw-wg/2016Apr/0104.html
<scribe> ACTION: jtandy to prioritize data publication over adding usage examples and include list of potential usage examples from email [recorded in http://www.w3.org/2016/05/03-sdwbp-minutes.html#action04]
<trackbot> Created ACTION-166 - Prioritize data publication over adding usage examples and include list of potential usage examples from email [on Jeremy Tandy - due 2016-05-10].
<AndreaPerego> Need to leave, sorry.
Jeremy and Linda looking through narrative 4 through 9.
<jtandy> ... this is a good example where we can use an alternative implementation approach to achieve the same best practice as in (2)
<jtandy> ... e.g. exposing data residing in ElasticSearch as RESTful API rather than proxying an SDI
<jtandy> spatial and textual filter: "find all electricity sub-stations within this flood polygon"
<jtandy> (filter for search)
example (5) maybe we can also add linked data fragments ref here.
<jtandy> for API usage: "the 5-minute rule" = the maximum time developers will try to make a first successful call to a data API - or leave and find something else
I came across some nice belgian examples today, see this blog http://blog.pieter.pm/2016/04/i-do-not-want-your-open-data-api-id-rather-scrape-your-website/
example 8 needs to be changed based on the discussion we had about targeting the platform provider more than the social media user.
jtandy: does example 9 add any value?
Linda: lets ask the group tomorrow
<scribe> ACTION: Linda to work on narrative example 3. [recorded in http://www.w3.org/2016/05/03-sdwbp-minutes.html#action05]
<trackbot> Created ACTION-167 - Work on narrative example 3. [on Linda van den Brink - due 2016-05-10].
<scribe> ACTION: jtandy to crossref the narrative_2 with the DWBP [recorded in http://www.w3.org/2016/05/03-sdwbp-minutes.html#action06]
<trackbot> Created ACTION-168 - Crossref the narrative_2 with the dwbp [on Jeremy Tandy - due 2016-05-10].
<jtandy> delete action 6
<jtandy> close action-168
<trackbot> Closed action-168.
<scribe> ACTION: jtandy to crossref the SWBBP with the DWBP to make it a true extension and eliminate duplication [recorded in http://www.w3.org/2016/05/03-sdwbp-minutes.html#action07]
<trackbot> Created ACTION-169 - Crossref the swbbp with the dwbp to make it a true extension and eliminate duplication [on Jeremy Tandy - due 2016-05-10].
<jtandy> DWBP is a great piece of work; currently we're repeating much of what they say - would it be better simply to extend those BPs that need extra 'spatial' context?
+1\
<jtandy> +1
bye
<jtandy> meeting is now closed!
<jtandy> trackbot, help
<trackbot> Please see <http://www.w3.org/2005/06/tracker/irc> for help.
<jtandy> trackbot, end meeting