See also: IRC log
<kerry> scribe: billroberts
<kerry> scribenick: billroberts
PROPOSED: approve minutes of last meeting
<ahaller2> +1
+1
<Linda> +1
<kerry> +1
<ScottSimmons> +1
<joshlieberman> +1
RESOLUTION: approve minutes of last meeting
<roba> +1
<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.
https://www.w3.org/2015/spatial/wiki/Cross_reference_of_UCR_to_CovJSON_spec
<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
https://www.w3.org/2015/spatial/wiki/Beginnings_of_a_W3C_note
<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
<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
<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
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
<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
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
bye