[Minutes-BP] 2016-06-01

And, amazingly, the minutes of last week's BP and Spatial Ontology 
meeting are at https://www.w3.org/2016/06/01-sdwbp-minutes with a text 
snapshot below.

    [1]W3C

       [1] http://www.w3.org/

           Spatial Data on the Web BP Sub Group Teleconference

01 Jun 2016

    See also: [2]IRC log

       [2] http://www.w3.org/2016/06/01-sdwbp-irc

Attendees

    Present
           BartvanLeeuwen, Linda, frans, ByronCinNZ, eparsons,
           joshli, MattPerry, roba, billroberts, ClausStadler,
           AndreaPerego

    Regrets
           Payam, Jeremy, PhilA

    Chair
           Linda

    Scribe
           billroberts

Contents

      * [3]Topics
          1. [4]Progress of BP Narrative 2
          2. [5]spatial ontology
      * [6]Summary of Action Items
      * [7]Summary of Resolutions
      __________________________________________________________

    <frans> Only Dutch people on webex

    <Linda> Ed, Bill, will you join the webex?

    <eparsons> Just switching meetings

    <Linda> present

    <Linda> present?

    <scribe> scribe: billroberts

    <Linda> [8]https://www.w3.org/2016/05/18-sdwbp-minutes

       [8] https://www.w3.org/2016/05/18-sdwbp-minutes

    Proposed: approve minutes of last meeting

    <BartvanLeeuwen> +1

    <Linda> +1

    0 - wasn't there

    <eparsons> 0 sorry

    <joshli> +1

    <MattPerry> 0 - not there

    <frans> +0 (but they look fine)

    <ByronCinNZ_> +1

    RESOLUTION: minutes approved

    <Linda> [9]https://www.w3.org/2015/spatial/wiki/Patent_Call

       [9] https://www.w3.org/2015/spatial/wiki/Patent_Call

Progress of BP Narrative 2

    <Linda> [10]https://www.w3.org/2015/spatial/wiki/BP_Narrative_2

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

    BartvanLeeuwen: Nicky and Bart have been working further on it.
    Should be possible to align the work of the Dutch working group
    and this group

    Linda: would be useful to get feedback from the Dutch group on
    the narrative

    BartvanLeeuwen: the Dutch group would like to produce some
    guidance. For this group, would be good to show that external
    people have used it

    Linda: Bart to ask Nicky to share feedback via the mailing list

    or by editing the wiki page

    Linda: has edited the language to reduce the amount of jargon

    <Linda> convert a coverage to a Feature dataset using the
    �typical� Web environment of a javascript engine

    Linda: has edited item (3). Question to working group on that
    particular sentence

    BartvanLeeuwen: this might be to do with OpenLayers - taking
    feature data and putting it on a map

    <joshli> was the idea to do the conversion with a javascript
    engine or access a processing API?

    BartvanLeeuwen: but that might not be what Jeremy meant when he
    wrote it

    Linda: thinks he meant to process coverage data and detect
    features

    eparsons: questioned Jeremy on this point as this seemed not
    something that a web developer would do directly
    ... perhaps the details don't matter, other than the high level
    point that the developer does something to achieve a purpose.
    We don't need to be specific about how

    joshli: 3 pieces to this. (1) Processing can be accessed via a
    javascript library (though perhaps more liekly to be accessing
    an API).
    ... (2) common task to take an image or raster and have someone
    draw features on it, eg via crowdsourcing
    ... (3) corollary is to be able to link the derived feature to
    the source raster data

    <Linda> billroberts: made some edits in section 5, happy to
    take feedback

    <Linda> ... described minimum stuff to do and more advanced
    stuff census data publishers might do, including data cube
    stuff

    <Linda> .. what's the take on including examples, I included
    one from the Scottish govt statistics.

    Linda: in favour of including examples

    <eparsons> +1 for examples

    <frans> We could look at what Eurostat provides too

    <Linda> ... happy to add more examples

    Linda: welcomes input from others on the narrative - editors
    can't do it all themselves

    eparsons: has worked on item 6 (evacuation plan)
    ... importance of human readable as well as machine readable
    presentation of data

    <roba> ed - so if some people will be humans.. what are the
    other peple?

    Linda: has talked to Payam this week and he intends to help
    Josh on topics 7 and 8.

    <eparsons> roba how machine overlords

    <Linda>
    [11]https://www.w3.org/2015/spatial/wiki/An_agreed_spatial_onto
    logy

      [11] https://www.w3.org/2015/spatial/wiki/An_agreed_spatial_ontology

spatial ontology

    Linda: there has been discussion on an agreed spatial ontology.
    Should it be a new one, or should it be improvements to an
    existing one, eg GeoSPARQL

    joshli: presents thoughts on the spatial ontology.
    ... so far we have been focusing on how to do geometry
    ... looking at updating the GeoSPARQL approach to feature
    geometry
    ... the issues are (1) there should be some means to use and
    reuse multiple geometries. There are very simple spatial
    ontologies that say feature = geometry = encoding, but there
    are many use cases that require these to be separated
    ... geometry should be a first class object so that attributes
    of it can be captured
    ... so the geometry has to be disjoint from the feature
    ... and the feature should be disjoint from the spatial object
    ... a type of spatial object would be a geometrical object
    ... which would enable topological relationships without having
    to talk about coordinates

    joshli (continued): we also want to make it very simple for eg
    web developers to add information to a spatial object, eg
    simply lat,long coordinates

    scribe: want to find a way to be rigorous when we want to and
    simple when we want to
    ... It's not yet clear how to do that and which mechanisms
    would be best. SHACL?
    ... in GeoRSS 2005, we just stated equivalence of different
    forms
    ... One additional aspect is that there should be different
    serialisations of coordinate positions for a geometry
    ... Given a geometry with particular resolution and coordinate
    system, we want to use the GeoSPARQL property as a particular
    serialisation, eg asWKT, asGeoJSON, asGML. Can assert that they
    are mathematically the same but expressed in different formats
    ... that's another issue to resolve. [End of Josh's overview]

    eparsons: agrees with Josh's thoughtful approach. We should
    look at this starting from a simple approach. This is spatial
    data **on the web** and many use cases are simple
    ... There are also common use cases about spatial information
    that may have no defined geometry. We should include that in
    our thinking
    ... Someone wants to talk about London but doesn't need to
    define the geometry of it

    Joshli: Matt Perry has been thinking about this. eg you might
    want to talk about London as a two dimensional region and say
    that something else is inside it, without specifying details

    eparsons: 'London is in England', 'England is in Europe' etc
    are useful pieces of information

    joshli: those are assertions about the spatial nature of those
    things, even if not talking about geometry explicitly

    MattPerry: been looking for a simple approach to this: making
    assertions about a feature rather than adding new classes to
    the hierarchy
    ... it may well make sense to add Spatial Object as a new
    class, but we need to eb careful not to break what we already
    have

    frans: Simplicity should be paramount in this context
    ... if we can put in good foundations for the basics of
    geometry that would be a step towards simplification
    ... the foundation (which in itself might not be simple) can
    hopefully build bridges between different representations on
    the web
    ... Is this an opportunity to start cooperating on developing a
    new ontology?

    joshli: answer to that is 'yes'. Josh is working on one and
    would be happy to host drafts

    frans: Coverage people had a discussion

    bill: (actually that was teh SSN group)

    joshli: SSN group talked about Webprotege as a tool

    roba: I'm working on describing hierarchical relationships in
    data cube dimensions
    ... linked data web is very heterogeneous. Often relies on
    assumed rather than explicitly declared knowledge. Many
    different terms used by different people. There is a lot of
    misuse of vocabularies
    ... so there is a need for a best practice as there are too
    many different ways of doing it

    eparsons: we should think more broadly than just geometries,
    but also think of relationships between features that rely on
    other aspects of them than geometry

    joshli: I've been focusing on geometry so far as that seemed to
    be the pain point
    ... but interesting to consider other things
    ... How do we distinguish between spatial relationships and
    (non-spatial) feature relationships?
    ... but this can get very complicated.

    eparsons: perhaps we can at least note our aspiration to go in
    that direction, while noting the concern about complexity of
    that
    ... it's natural to get het up about geometry, but many web
    developers take a more 'place-based' than 'space-based' view of
    the world

    joshli: noted in his conversation with Matt, than many
    relationships are not space based, eg 'part of' relationships
    ... useful to describe equivalence between different kinds of
    relation

    <Linda> oops, I was actually talking but muted...

    frans: audience could include, for example, people at say
    Google working on artificial intelligence, data mining, etc
    might benefit from spatial data on the web having common
    geometrical foundations to make it more processable

    linda: asks Frans - is there anything in the use cases about
    this?

    frans: yes, lots relating to defining and consuming geometry

    roba: noting conversations in the SSN group, about how to
    modularize vocabularies
    ... so can have a simple basic ontology then add in more
    sophisticated modules if you want to do reasoning

    <AndreaPerego> About UCR & spatial ontology, there's also some
    about spatial relations -
    [12]https://www.w3.org/TR/sdw-ucr/#SpatialRelationships

      [12] https://www.w3.org/TR/sdw-ucr/#SpatialRelationships

    Linda: can we categorise our requirements into 'simple' and
    'complex' ?

    eparsons: in response to Frans on AI, data mining etc - the
    geometry is not always relevant to that. More important is
    relations between features. The relation is 'London is in
    England'
    ... second point is a more operational one. How are we going to
    get this work done? Is it part of the BP, or is it a separate
    deliverable that needs to be managed and resourced
    ... don't want to lose focus on the BP while working on the
    spatial ontology

    Linda: yes that needs further discussion. In my mind it is a
    separate thing

    joshli: agrees that it should be separate to the BP
    deliverable.
    ... it could be an OGC thing that could be cited in the best
    practice
    ... but need to consider the process for that. Perhaps a
    charter for a GeoSPARQL working group
    ... should development of ontology be part of the SDW activity?
    Maybe SDW can set requirements and the drafting of it could be
    in OGC context perhaps

    <eparsons> +1 to josh's plan req from here - doc produced via
    OGC process

    joshli: Also, useful to look at the SSN modularity approach as
    a pattern, but is that parallelisable

    <Linda> +1 to josh's plan

    <AndreaPerego> +1 to RDFS for core, and more sophisticated
    formalisation for extensions.

    frans: on modularity, GeoSPARQL is already modular in a
    functional sense. We would want a future version of GeoSPARQL
    to be compatible with the existing version, so would keep
    existing modularization pattern
    ... a risk of the ontology development being in the OGC area
    might be a loss of input from W3C perspective

    <eparsons> +1

    <AndreaPerego> +1

    <Linda> +1

    <MattPerry> +1

    Linda: who would be interested on working on this ontology?

    <ByronCinNZ_> +1

    <joshli> +1

    <frans> +1

    <AndreaPerego> +1

    <roba> +1

    <eparsons> thanks billroberts Good Job !!

    Linda: will take this discussion back to plenary group next
    week

    <AndreaPerego> Thanks, and bye.

    <eparsons> thank Linda

    Meeting closed

    <frans> Thanks all, have a good day

    <joshli> bye bye

    bye

    <MattPerry> bye

    <Linda> bye

Summary of Action Items

Summary of Resolutions

     1. [13]minutes approved
     2. [14]minutes approved

    [End of minutes]
      __________________________________________________________

Received on Monday, 6 June 2016 09:12:38 UTC