W3C home > Mailing lists > Public > public-sdw-wg@w3.org > May 2016

[Minutes-BP] 2016-05-03

From: Phil Archer <phila@w3.org>
Date: Tue, 3 May 2016 22:24:22 +0100
To: SDW WG Public List <public-sdw-wg@w3.org>
Message-ID: <1204a966-8dcc-50b0-fae5-9ca469d641b3@w3.org>
The BP Sub Group had a long extra meeting, the minutes of which are at 
https://www.w3.org/2016/05/03-sdwbp-minutes with a text snapshot below. 
This meeting is in addition to, not instead of, the meeting on 4th May.

A text snapshot of the 3 May meeting minutes if provided below.

                    Spatial Data on the Web WG, BP VM

03 May 2016



    See also: [3]IRC log

       [3] http://www.w3.org/2016/05/03-sdwbp-irc


           jtandy, Linda, ClemensPortele, AndreaPerego, /, -


           jtandy, Clemens Portele, Linda van den Brink


      * [4]Topics
          1. [5]Patent Call
          2. [6]Check agenda
      * [7]Summary of Action Items
      * [8]Summary of Resolutions

    <jtandy> Agenda is at:


    <jtandy> Looks like the Goto meeting is started ...

    <jtandy> scribe: jtandy

    <scribe> scribe: Clemens Portele

    <scribe> scribenick: ClemensPortele

Patent Call

Check agenda


      [10] 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


      [11] 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?


    <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> [12]https://www.w3.org/2015/spatial/wiki/BP_Narrative

      [12] 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

      [13] https://www.w3.org/2015/spatial/wiki/BP_Narrative_2

    <Linda> -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

    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


    <Linda> +1

    <jtandy> I'm hoping that it addresses the needs of the BP

    <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

    <BartvanLeeuwen> I had to lookup some specific weahter /
    flooding related terms

    <jtandy> +1

    <Linda> +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


    <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

    <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

    <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
    ... step 1



    <BartvanLeeuwen> +1 to stick to a single event instead of

    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
    ... 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"

    <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

    <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

    joshlieberman: large scale = merging this information with the
    admin units etc and analysing this to identify discrepancies

    <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

    <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

    <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:

      [16] 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

    <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


    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

    ClemensPortele: not necessarily "has location", but "related to
    a location" (?)

    jtandy: (cites what some of the existing vocabularies have

    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

    <jtandy> noting that we mean 'real-world' as in the 'universe
    of discourse', which should include fictional and abstract

    <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

    <AndreaPerego> +1

    <jtandy> +1

    <jtandy> (representation implies geometry etc. ... not the
    wider Web term)


    <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

    <jtandy> two tasks then: (i) point to existing implementations,
    (ii) frame those implementation patterns in the flooding

    <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


      [18] 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
    -- [19]http://water.weather.gov/ahps/about/about.php

      [19] 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:

      [20] http://water.weather.gov/ahps/rss/forecasts.php

    <scribe> ACTION: Linda to ask Clemens to provide an example for
    narrative item 2 [recorded in

      [21] 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

    <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,


    <AndreaPerego> +1

    <jtandy> +1

    <scribe> ACTION: joshlieberman to work on narrative item 7
    [recorded in

      [22] 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

    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

      [23] 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

    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

    jtandy: should we have the biweekly SDW BP subgroup call

    Payam: we could continue this discussion

    <AndreaPerego> +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:


    <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

    <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

    <jtandy> worried that including usage examples will be too much

    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


    <jtandy> +1



    <scribe> ACTION: jtandy to prioritize data publication over
    adding usage examples and include list of potential usage
    examples from email [recorded in

      [26] 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> example (4)


    <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

    <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


    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

      [29] 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

      [30] 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

      [31] 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?


    <jtandy> +1


    <jtandy> meeting is now closed!

    <jtandy> trackbot, help

    <trackbot> Please see
    <[32]http://www.w3.org/2005/06/tracker/irc> for help.

      [32] http://www.w3.org/2005/06/tracker/irc

    <jtandy> trackbot, end meeting

Summary of Action Items

    [NEW] ACTION: AndreaPerego to add a section about publishing
    metadata to item nr 4 [recorded in
    [NEW] ACTION: joshlieberman to work on narrative item 7
    [recorded in
    [NEW] ACTION: jtandy to crossref the narrative_2 with the DWBP
    [recorded in
    [NEW] ACTION: jtandy to crossref the SWBBP with the DWBP to
    make it a true extension and eliminate duplication [recorded in
    [NEW] ACTION: jtandy to prioritize data publication over adding
    usage examples and include list of potential usage examples
    from email [recorded in
    [NEW] ACTION: Linda to ask Clemens to provide an example for
    narrative item 2 [recorded in
    [NEW] ACTION: Linda to work on narrative example 3. [recorded

      [33] http://www.w3.org/2016/05/03-sdwbp-minutes.html#action03
      [34] http://www.w3.org/2016/05/03-sdwbp-minutes.html#action02
      [35] http://www.w3.org/2016/05/03-sdwbp-minutes.html#action06
      [36] http://www.w3.org/2016/05/03-sdwbp-minutes.html#action07
      [37] http://www.w3.org/2016/05/03-sdwbp-minutes.html#action04
      [38] http://www.w3.org/2016/05/03-sdwbp-minutes.html#action01
      [39] http://www.w3.org/2016/05/03-sdwbp-minutes.html#action05

Summary of Resolutions

     1. [40]we have a non-technical overview of the scenario to
        complement the technical version
     2. [41]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)
     3. [42]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

    [End of minutes]
Received on Tuesday, 3 May 2016 21:24:30 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:21 UTC