Spatial Data on the Web BP Sub Group Teleconference

<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> 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> https://www.w3.org/2015/spatial/wiki/Patent_Call

Progress of BP Narrative 2

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