Spatial Data on the Web Working Group Teleconference

<phila> trackbot, start meeting

<trackbot> Meeting: Spatial Data on the Web Working Group Teleconference

<trackbot> Date: 27 April 2016

<phila> scribe: jtandy

<phila> scribeNick: jtandy

<eparsons> Topic : Approve last week's minutes

+1

<eparsons> Proposed : Approve last week's minutes

<AndreaPerego> +1

+1

<eparsons> http://www.w3.org/2016/04/13-sdw-minutes.html

<phila> PROPOSED: Approve previous plenary meeting's minutes

<phila> +1

<frans> +!

<frans> +1

<kerry> +1

<eparsons> RESOLUTION: Approve last week's minutes

<billroberts> +1

<joshlieberman> +!

<eparsons> Topic : Patent Call

<eparsons> https://www.w3.org/2015/spatial/wiki/Patent_Call

eparsons: calls us pedants!
... main business now ...

<RaulGarciaCastro> +present RaulGarciaCastro

eparsons: how to best make use of this plenary call? what are you ideas?

<eparsons> Topic : SSN A primer

eparsons: sets up kerry to talk about the SSN primer

kerry: happy to describe- sadly not so many SSN folks in attendance

<kerry> We passed a RESOLUTION - that DUL alignment becomes a note or some other product outside the recommendation

kerry: we made this resolution in _their_ meeting
... see above
... we wanted to publish [things that complement] the core SSN spec - but separate
... phila suggested a Note, ScottSimmons suggested a few options including
... the DUL bit could be published as an extension (no thanks!) or a best practice / discussion paper
... phila later suggested Primer instead of a Note
... primer seems best; a tutorial

<phila> phila: q+ to say that Primers are Notes - we only have Recs and Notes in terms if docs

kerry: DUL won't be the _only_ example of 'extra bits and pieces' required to use the core SSN spec
... this issue is also likely to hit us with the Time deliverable

<Zakim> phila, you wanted to say that Primers are Notes - we only have Recs and Notes in terms if docs

kerry: ontology publication (REC track) will be fairly dry - we put the interesting and complementary information in the Primer

phila: we only have Notes and Recs ... the Primer could be either Note or Primer ... suggests that we have the SSN Primer as a Note

ScottSimmons: asks what we want from this doc
... best practice is a formal endorsement of the OGC community, discussion paper is just "useful"

kerry: sounds like a discussion paper to me; full of examples

phila: agrees - a REC is formally endorsed, a Note is not ... more like a discussion paper then

eparsons: what's the publication process in each case?

phila: WG agree to publish a Note

ScottSimmons: recommendation from WG for 8-day vote from TC

<Zakim> RaulGarciaCastro, you wanted to say that if we don’t recommend DUL, I would not put it in a primer; people could choose to align to others

RaulGarciaCastro: I don't have a clear notion of the semantics of "primer" - but if DUL is outside the core spec, then does this really fit in the Primer?
... people could use something other than DUL ...

kerry: we're not saying that DUL is the only alignment you could use
... the alignment to DUL is proposed as an _example_ ... others are possible
... but we won't develop that
... the DUL alignment is just an example [of how to use SSN] - we're not saying that you must (or should) use DUL

eparsons: we all need to review the primer anyway, so we have a chance to comment on the content
... summarises ... Primer it is then - as a W3C Note and OGC Discussion paper

kerry: requests a vote

eparsons: are there other deliverables where this approach makes sense? e.g. where you need to complement a dry spec
... what are other people's thoughts

<phila> jtandy: Where you have a dry spec that doesn't work well with lots of embedded examples, stick the examples in something else - that makes sense to me

kerry: we're not setting a policy here- just a recommendation for Time ...
... can we have a resolution that SSN team deliver a REC and a complementary Note?

<phila> PROPOSED: That the SSN Sub Group should create a Rec for SSN plus a Primer that will include examples using DUL

kerry: notes that the SSN REC-track FPWD is coming soon!

<phila> PROPOSED: That the SSN Sub Group should create a Rec for SSN plus a Primer that will include examples using DUL. The latter will be an OGC Discussion paper and W3C Note

+1

<RaulGarciaCastro> +1

<eparsons> +1

<ScottSimmons> +1

<kerry> +1

<billroberts> +1

RESOLUTION: That the SSN Sub Group should create a Rec for SSN plus a Primer that will include examples using DUL. The latter will be an OGC Discussion paper and W3C Note

<frans> +1

eparsons: looks good ... sold to the lady in Australia

A Spatial Ontology

eparsons: "the spatial ontology to rule them all" ... we _do_ need to address this

frans: this topic could be at the core of our mission to [clarify] the spatial data standards landscape
... there are no clear solutions at the moment
... there are interoperability issues with all the options today
... implementers are still at a loss to see which option they should support
... the world is waiting to be told
... there are many ways to approach the spatial ontology

<frans> https://www.w3.org/2015/spatial/wiki/An_agreed_spatial_ontology

frans: I made this wiki page to collect thoughts around this issue
... my personal thought is that the spatial ontology should, at least, define geometry as a core concept
... at a fundamental everyone agrees what a geometry is
... we probably have lots of standards because [they have evolved from] different perspectives
... perhaps we need to base our standard on the underpinning [mathematical] theory - rather than a particular domain view

<Zakim> phila, you wanted to ask 4 questions

<phila> Do we think there is already a clear preferred spatial ontology?

<phila> If so, is there consensus on endorsing it?

<phila> If not, is there one that is within our power to amend?

<phila> If not, can we present the pros and cons of each and leave it up to implementers?

frans: so lets start by collecting our thoughts

phila: question 1- do we already think there is already a preferred spatial ontology? if there is, we should just say that (assuming the group can agree)
... question 2- if there is one that _almost_ works, can we amend that?
... question 3- failing that, can we identify when and where each option should be used?

frans: we can see a preference for ontologies- but the preference depends on domain
... for example, spatial folks like GeoSPARQL
... but this doesn't address all the needs
... we could start by trying to evolve GeoSPARQL
... perhaps we could start with GeoSPARQL
... and try to make it usable for everyone

eparsons: so - GeoSPARQL seems like a good starting point

<phila> scribe: phila

eparsons: Is this the right level of abstraction?
... Does everyone care about points lines and polygons, abstract spatial features etc.
... We might be better off taking about roads, rivers etc.

frans: Should the spatial ontology be about spatial things or about geometry?

<joshlieberman> http://www.w3.org/2005/Incubator/geo/XGR-geo-ont-20071023/

frans: If I look at the practical problems - it has to do with expressing geometry (with CRSs in the background)
... No practical probs in what a spatial thing is
... There are already systems in place for classifying

scribe jtandy

<jtandy> joshlieberman: I have some comments

<scribe> scribe: jtandy

UNKNOWN_SPEAKER: geometry is important
... we don't need to establish a theoretical validation for geometry - there's lots of existing work
... we don't need an ontology for geometry- geometry is for computation

<billroberts> joshlieberman said 'geometry is for computation'

joshlieberman: after 13 years, we still have people saying "lets just use W3C basic Geo"
... this work was incorporated and extended by the W3C Geo Ontologies IG (XGR-geo-ont-20071023)
... this work is the precursor of GeoSPARQL - which is based on 19107
... but there's very little traction in the web community
... if we can figure out why there is a lack of traction then this would be a good start

frans: agrees. the lack of traction could be that it is (i) unknown, or (ii) doesn't meet all the requirements
... notes that GeoSPARQL doesn't actually identify the geometry definitions
... this is [impenetrable] for people wanting to transform between different encodings

joshlieberman: the definitions are incorporated into ISO standards, which are only available for a fee!
... this is an ongoing issue for OGC
... (not good for ScottSimmons blood pressure)
... we want to make these standards web accessible

<ScottSimmons> (gotta run and up my meds after that comment)

joshlieberman: there's a difference to starting from scratch; we want to make [the existing work] web accessible
... we can start from the OWL ontologies that are being derived from the UML models in ISO 19107
... this was Simon Cox's suggestion
... perhaps we can develop a web accessible standard based on ISO 19107 and ISO 19109

<Zakim> phila, you wanted to talk about developers

joshlieberman: I don't really care if this upsets ISO - but the issue with ISO is about intellectual property of the text- not the data models

<phila> Vladimir Agafonkin's story of creating Leaflet.

ScottSimmons: agrees ... but this would take time

phila: a barrier to adoption [of GeoSPARQL] is that it has the word "SPARQL" in it
... also, ref experience from developer of leaflet. In general, developers are astounded that you need more than a lat-lon ... surely Google maps [does the heavy lifting]
... you're not going to get a Web developer to write a SPARQL query

frans: GeoSPARQL has good points
... such as the geometry definitions
... it's modular
... if we take the route to open up ISO 19107 and ISO 19109
... can we modularise [GeoSPARQL] to include / refer to these

joshlieberman: its a pity that Mathew Perry isn't here; he developed the properties
... required to query against (?) geometries
... this was an add on; didn't realise that this needed to be done until after we'd started
... modularising GeoSPARQL [is a good idea]
... we do need to recognise that many developers won't want to do all the complex stuff
... so we need to map their simple world onto GeoSPARQL
... specifically, we need to include GeoJSON

<kerry> What formalizations of the non-geometric property literals, such as <relationshiptag> are needed to fully satisfy the group's use cases and others like them?

kerry: I liked where joshlieberman was going with that- sounds sensible
... copies a sentence from the report that joshlieberman refers to
... discussing geospatial relationships and the venacular (e.g. "next door to")
... perhaps this could be added to the ontology

eparsons: back to frans

<joshlieberman> Yes, the point of the incubator report was that there are several ontologies relevant to spatial data.

frans: extensibility is another key requirement
... GeoSPARQL already supports this

<Zakim> billroberts, you wanted to talk about the most important aspects of geometry from a dev point of view

frans: if we take GeoSPARQL as a starting point can we using this to bridge the gap between spatial and normal data

<joshlieberman> Could you define what that gap is? Arguably it's a question of coordinate system

eparsons: intervenes to get back to queue

billroberts: we quite like a SPARQL query- but mostly, we want to get hold a chunk of geometry
... e.g. the boundary of my town
... in GeoJSON so that I can work with it - to draw it on a map, put in elastic search etc.

<Zakim> AndreaPerego, you wanted to talk about practical requirements for (a) Web developers & (b) LD guys

billroberts: simply getting the geometries [as objects] would solve 95% of my problems

AndreaPerego: refers to previous work
... most web developers just want to get the geometries -
... in which ever format suits them
... in the appropriate CRS
... at the right level of complexity
... the main issue is how to fill in the gaps
... GeoSPARQL has lots of stuff- but doesn't say how to do a bounding box
... looking from a practical point of view, I am concerned about the ability of the WG to cope with this issue in the time we have
... should we not try to help reuse what is already available?

eparsons: good point- we need to consider this

<AndreaPerego> About gaps: https://www.w3.org/community/locadd/wiki/Use_case:_Sub-properties_for_locn:geometry

<AndreaPerego> https://www.w3.org/community/locadd/wiki/Use_case:_CRS_specification

<AndreaPerego> https://www.w3.org/community/locadd/wiki/LOCN_extension:_Metadata

eparsons: how do we go forward? Presumably, this is another deliverable beyond the BP work? Jeremy and Linda to comment

joshlieberman: W3C and OGC can work together to deliver this

<frans> Yes, we need as many people on the case as possible

joshlieberman: timing is an issue; we could get this going in June TC

<phila> scribe: phila

Virtual F2F

<eparsons> https://www.w3.org/2015/spatial/wiki/Agenda_BP_VM_May_2016

jtandy: For thos interested - on Tuesday next, European afternoon, 11:00 UTC onwards, we're going to try and work through outstanding issues
... make big progress. I've turned the narrative into chunks that have tangible examples in them.
... See if they make them constraints, underpinning issues etc.
... I suggest we keep the spatial ontology thread separate from that discussion

back to Spatial Ontology

eparsons: If we do it as a separate deliverable, we need people. I suggest Frans and Josh?

joshlieberman: I can put some time into that

<frans> Yes, but we need a larger group

eparsons: I agree we need a larger group

jtandy: I think tis is an issue that we might be able to get extra support from the office on.

joshlieberman: I point out that we have time on the Thursday in the TC for this. 08:00 Dublin time

eparsons: Out of time guys. Please continue on e-mail.
... So we have a new deliverable.
... We'll talk again in 2 weeks.

#/me no

kerry: Two new deliverables tis meeting

<AndreaPerego> Thanks, and bye!

<frans> Thanks, bye

<joshlieberman> bye

<RaulGarciaCastro> Bye

<billroberts> thanks bye

<eparsons> thank all - bye

<kerry> bye!

<jtandy> bye