See also: IRC log
<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
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
<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
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