Spatial Data on the Web Working Group Teleconference

17 Aug 2016


See also: IRC log


kerry, phila, ahaller2, frans, ScottSimmons, Linda, billroberts, MattPerry, ClausStadler
Rachel, Lars, SimonCox, Andrea_Perego, AndreaP


<kerry> scribe: billroberts

<kerry> scribenick: billroberts

approve minutes https://www.w3.org/2016/08/03-sdw-minutes.html

PROPOSED: approve minutes of last meeting

<ahaller2> +1


<Linda> +1

<kerry> +1

<ScottSimmons> +1

<joshlieberman> +1

RESOLUTION: approve minutes of last meeting

<roba> +1

Coverage update

<kerry> patent call: https://www.w3.org/2015/spatial/wiki/Patent_Call

<kerry> billroberts: work on coverage has focused on 2 strands

<kerry> ...1 is covjson from u reading and a draft specification will be given more formal status.


<kerry> ...i have run thru ucs and xref with covjson and wrriten some note (see above) and concluded a pretty good match

<frans> Bill, did you use the latest editors draft of the UCR to cross-reference?

<kerry> ... a missing bit has some ideas being developed now by jon and mail re fragment identifiers and "extracts" with metadata atttached

<kerry> .... discussion at last meeting was whetherwe should make it a rec/standard or a not/discussion odc. Issue is resources.

<kerry> .... esp implementations -- will be discussed with phil

<kerry> ...did i use laterst ucr draft ? yes, but it might have moved since


<kerry> ....2 other strand is rdf datacube approach.... dmitry has put together beginnings of what could be a "note"

<kerry> .... roba also doing early stage work on soemthing called qbfor st (space and time dimensions).

<kerry> .... will see whther these should/could be combined to a note

<kerry> .. might say how rdf db should be used

<kerry> .... i will help too

<kerry> ...objective to have reasonable drafts

<kerry> ... by tpac meeting

<kerry> phila: thanks for a lot of work here --- ok for 2 docs provinding different ways of doing a similar thing .... sounls like maybe both docs should be notes/discussion paper

<kerry> .... may not be a formal standards ---a little premature... notes/discussion maybe over standard/recs

<kerry> billroberts: happy with that -- sounds right to me too

<kerry> linda: should there be something about cov in BP?

<kerry> billroberts: yes, seems appropriate. we can put some work into this. already a relevant narrative there.

<kerry> ....we could have a specific bp around this topic.

<kerry> ....the new things are quite new so would they be "best practice"?

<kerry> linda: could be just careful wording e.g "possible approach"

<kerry> roba: plea for help and clarification -- how to take existing bp to definitions that can be reused...

<kerry> ... i have action to write a note about general problem of metadata... general comment to review vocablaries and pointing to ogc vocabs where they should be held

<kerry> ... are we lookjing at 2 different approaches ... they are not competing more of a bridge with link to josh's vocab work, to fit into best practice.

<kerry> ... is there a middle glue -- but i need some help here.

joshlieberman: has been following the coverages work with interest. There are several approaches, which have a lot in common: XML from OGC, RDF, JSON.
... these have a connection to existing models and definitions. Coverage is a Feature, elements within that are also potentially Features.
... subsets/slices/bounding areas are also Features. The different appraoches are essentially about how you define the index from those features to the corresponding range.
... the Best Practice could focus on those higher level concepts, plus practical aspects of how to represent those
... this would give the basis for converting between those approaches. Different ones have strenghts for different applications

Frans: is wondering about how coverages relate to the spatial ontology work, partly answered by Josh's recent comment
... where will the concept of 'Coverage' be defined?

joshlieberman: [sound lost for a few seconds] has discussed with Rob about defining key concepts of the coverage dimensions/index

<frans> I lost Josh´s voice for a while

joshlieberman: Coverage concept is well defined in existing OGC documents but we should summarise it in the BP for ease of access

frans: will it be defined in an RDF ontology?

joshlieberman: the Data Cube Note could include extensions to the ontology
... would like to write a charter for OGC to extend GeoSPARQL to reflect his current research work
... so thinking about what could go into the BP while a possibly long-running consideration of this takes place at OGC

Consolidating (merging) best practices, e.g. the ones on identifiers

<frans> Josh, I would love to help with the spatial ontology but I am occupied with the UC&R now.

Linda: hard at work on the BP. Jeremy working on the narrative, Linda working on restructuring the BP, Payam is working on CRS
... would like to talk about consolidating and merging of BPs
... have created a new section to hold a merged section around best practices for identifiers. Previously there were 5 or so

<Linda> http://w3c.github.io/sdw/bp/#bp-identifiers

Linda: now only one BP in this section. The Possible Approach section includes 3 main points: reuse identifiers when you can; when none exist, create your own; provide stable identifiers for things that change over time

<kerry> +1 to the merge

<roba> +1

<frans> Less is more!

Linda: question for the working group - is this a good approach? There will be fewer best practices but each will be longer

<ScottSimmons> +1

Linda: please look at the document over the next few days and give feedback on this approach
... but seeing the good initial support, will carry on in this way for now

<roba> i had a look - and its good to improive connection between the issues anyway - maybe some sort of decision tree emerges

Linda: has already incorporated some comments from Simon

<joshlieberman> Should identifiers be part of a system for the features of interest?

joshlieberman: making identifiers part of a system, where the features are part of the system?
... for example corresponding to paths in a taxonomy

Linda: no answer right now, will have to think about it

Fix a date for document freeze prior to TPAC (F2F) vote

<roba> +1 for special case where a set of features provide a set of identifiers - highlights the separation of feature model as a data structure implementation and object identity :-)

kerry: for rest of meeting, concentrate on remaining issues in the UCR doc
... Frans had asked what state are we aiming to get UCR in by TPAC. Can we get it to 'final call' status?

phila: as it is a Note, there is no concept of a Final Call or final edition. It just becomes whatever you publish last.

kerry: so should it be another Public Working Draft? and so does it need a vote

phila: it's currently published as a Note, so the next version just becomes another version of that Note. There is no change in status associated with a new version

<phila> UCR

frans: understood
... at some point we want a frozen version for soliciting public comments and for discussing at TPAC. So how long before TPAC should we freeze documents to allow that

phila: no formal requirement, but something like a week before works well in practice
... are members of the group happy that they have had sufficient time to read it and prepare

frans: is happy with freezing a week before TPAC
... do we want a public call for comments at that moment?
... so we should do that a week before TPAC too
... it would be nice to receive some public comments before TPAC so maybe seeking comments earlier would be better

phila: notes only 5 weeks to TPAC

kerry: let's freeze a week before TPAC and respond to any notable public comments that we receive

Editors of deliverables checking requirements in UCR (this thread)

kerry: Frans would like to check the status of other deliverables and how they relate to UCR

<kerry> the email thread is here: https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jun/0114.html

Frans: has asked editors of other deliverables to see if they are aware of the latest UCR and any suggests for changes
... not many changes required. Their working requirements are well aligned with current status of UCR
... but hasn't heard yet from SSN group

kerry: I brought this up at a SSN meeting but no significant response, so will bring it up again at the next SSN meeting in 2 weeks and Kerry will look at it herself. So Frans can assume it's probably ok but notes the need to take a look

frans: expects each deliverable to include an explanation of how it meets the requirements, or why it was not possible to meet them
... so important to have the links from requirements to deliverable

kerry: good idea, but not sure it is feasible for SSN, at least not within 5 weeks

frans: was thinking of a simple checklist or table of requirements and a 'yes' or 'no' whether it was met
... maybe it doesn't need to eb part of a formal deliverable, but just a record on the wiki to show that the deliverable was tested against hte requirements

kerry: doing it on the wiki might be possible in that time
... but as Phil said, it only has to be final when the working group finishes, so could perhaps be revised later.

phila: it's possible that another group could pick up aspects of the work. That's what happened with the Time ontology. Our group has extended something that was first produced as a Note 10 yaers ago

frans: at least we should make sure that all the requirements from the use case analysis are somehow addressed

kerry: can agree to do that on the wiki

frans: should the BP document have explicit links to UCR?

kerry: yes, we have something on that in the 'evidence' sections that have links into the UCR doc

<kerry> issue: ssn group needs to produce a wiki document that realtes to requirements met or not from UCR

<trackbot> Created ISSUE-73 - Ssn group needs to produce a wiki document that realtes to requirements met or not from ucr. Please complete additional details at <http://www.w3.org/2015/spatial/track/issues/73/edit>.

frans: that makes it easier to check whether any requirements have been overlooked, especially since some have been added recently
... ok not to meet requirements in some cases, but that should come with a note on why that requirement could not be met

Linda: but we won't be sure whether all requirements are met until the end of the work on the other deliverables

phila: that should probably go into the other deliverables - a list of requirements and whether/how they are met, so not in the UCR doc

Remaining outstanding issues and actions summary

<frans> https://www.w3.org/2015/spatial/track/products/1

<ScottSimmons> sorry - must leave a little early due to another meeting that requires brief travel.

frans: Action 111 will be addressed in next SSN teleconference https://www.w3.org/2015/spatial/track/actions/111
... there is a new requirement on coordinate transformations

<frans> https://www.w3.org/2015/spatial/track/issues/31

<kerry> +1 on adding requirement for issue-70

frans: issue 31 has been overlooked until recently
... Linda had remarked that this might be out of scope. Frans will create a new thread on the subject to seek opinions. Is it a spatial data question, or a more general data issue
... there are no red issues any more, so should be ready with next version in 2 weeks

kerry: congratulates Frans

how should geosparql be handled?

joshlieberman: the spatial ontology is not in a deliverable of this working group, but spatial data practices that refer to that ontology are in scope

<frans> The spatial ontology is mentioned as a subdeliverable of the BP deliverable

joshlieberman: the BP could refer to an OGC specification for that, but there is a mismatch in time, as a new OGC spec will take a long time
... so should there be another SDW document to describe that ontology

frans: perhaps we can indicate in BP that there is a need for a spatial ontology and that the new ontology in development is a promising option for the future - assuming that the ontology in development has a landing page or similar that we can link to

joshlieberman: yes it's currently at geosemweb.org

<Linda> +1 to having a note/discussion paper and reference that in BP

joshlieberman: a W3 note or OGC discussion paper reflect work at similar levels of maturity - not quite ready to become a standard

kerry: would feel more comfortable if is referenced in the BP document, even if future work - just to avoid creating additional documents

roba: wouldn't disagree. If we're looking for a way to reference spatial concepts, something like GeoSPARQL might be too complicated and not a good fit. So a need for an updated ontology is obvious

<joshlieberman> http://geosemweb.org/sdwgeo goes to a ttl file right now.

roba: am agnostic about where we document it, but we definitely need a practical solution to the problem, which could involve referring to the concepts from geosparql

<joshlieberman> mature state would be a BP reference to a new GeoSPARQL version, but interim measures are the question.

phila: remember the charter. Help people decide how to do stuff, and guide them. People will tend only to read the main thing and won't follow up all footnotes etc
... it's up to the group and editors to decide how best to do it

kerry: do you want people to review what you have done more closely? Propose what such a note might look like so we could decide what goes into BP?

joshlieberman: the ontology is available at the link above. I'll write a description of it to go with it

phila: who controls geosemweb.org?

joshlieberman: me

phila: we'll need something more permanent if we want to refer to it normatively, eg in SSN or Time ontology, as they are RECs

<joshlieberman> Proposal: reference GeoSPARQL in BP and indicate location of the draft update.

joshlieberman: so it would be better to have it as an OGC discussion paper

kerry: need to talk more about TPAC plans
... editors, please say how much time you want in the TPAC meeting, so can start putting together an agenda

phila: early-bird registration runs out at end of month, so register quick

<frans> Thanks, have a good day or night

<joshlieberman> bye


Summary of Action Items

Summary of Resolutions

  1. approve minutes of last meeting
[End of minutes]