See also: IRC log
<trackbot> Date: 14 October 2015
<eparsons> Meeting: SDW WG Weekly
<eparsons> Hey where is everyone ?
<billroberts> mornign all, just trying to get my webex going
<eparsons> OK Bill
<kerry> mornig? oy yes. it *isI morning, by 5 minutes
<billroberts> (morning/afternoon/evening as appropriate)
<kerry> scribe: josh
<kerry> scribenick: josh
<kerry> scribenick: joshlieberman
<eparsons> http://www.w3.org/2015/10/07-sdw-minutes.html
<eparsons> PROPOSED: Accept last meeting minutes
<jtandy> +0 (apologies - wasn't there)
<eparsons> +1
<kerry> +1
<LarsG> +1
<frans> +1
<Alejandro_Llaves> +0, not there
<Linda> +1
<eparsons> RESOLVED: Accept last meeting minutes
<Payam> +1
<frans> http://www.w3.org/2015/spatial/track/products/1
frans: remaining unresolved issues
<kerry> +q
frans: Issue 16 valid time requirement out of scope? Issue 15 represent past, present, future not clear?
kerry: what is the Valid time disagreement?
frans: one view is that OWL-Time expresses time, not its relevance to spatial data.
kerry: agreed, but should we cover those relationships additionally?
frans: well, not technically in scope, since the scope covers OWL-TIme alone and that doesn't include validity predicates.
billrobert: isn't this a generic data issues?
<kerry> +1
<frans> http://dublincore.org/documents/dcmi-terms/#terms-valid
<Zakim> jtandy, you wanted to ask about scoping
josh: spatial data needs particular expressions of validity / relevance to the real world. That has to include time.
chris: in general, the representation of time on the Web needs work as well, and this group or someone else needs to take this on.
jeremy: validTime is conceived as just a property with range OWL-Time. Should create / adopt bits of vocabulary as needed such as this.
eparsons: probably need to decide this sort of scope question sooner rather than later.
<jtandy> (the SDW charter allows us to formalise practice as necessary - we could produce additonal Notes)
<billrobe_> Ed: kerry is on the speaker queue
<Alejandro_Llaves> +q
<jtandy> "spatial data needs temporal context" ... good point kerry
kerry: agree with josh, chris, jeremy that spatial data needs temporal context. Shouldn't feel constrained by narrow interpretation of scope.
<Alejandro_Llaves> I can write, then...
billrobe_: clear this is important, not clear that anyone has done this for us, so reassured on scope.
frans: Issue 15: trend towards not having this as a requirement
<jtandy> past, present and future are valid statements only at a particular point in time ... we need relative statements; e.g. "before {now}" = past
<frans> http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#TemporalReferenceSystem
frans: Issue 25: temporal reference "description should be referenceable online
<jtandy> (my previous comment relating to Issue 15)
could we change "description" to "definition"?
<Alejandro_Llaves> IMO, with many of this issues related to UCR document we are trying to provide solutions. And this is not the point of the UCR document, nor the proper time to provide solutions to them, according to the group charter schedule. Best practice document and the corresponding Time deliverables, etc. would be the proper tool to discuss and propose solutions to the issues. I understood the UCR document as an exercise to extract requirements from UCs.
<Alejandro_Llaves> We could discuss if reqs are well phrased, if they need more examples, etc. But it seems we are trying to solve them now.
<eparsons> PROPOSED: Accept "Temporal reference system requirement: phrasing" for Issue 25
<frans> proposal: If a temporal reference is used, the definition of the temporal reference system (e.g. Unix date, Gregorian Calendar, Japanese Imperial Calendar, Carbon Date, Geological Date) should be referenceable online.
<Linda> +1
+1
<jtandy> +1
<eparsons> +1
<billrobe_> +1
<frans> +1
<Alejandro_Llaves> +1
<LarsG> +1
<kerry> +1
<eparsons> RESOLVED: Accept "Temporal reference system requirement: phrasing" for Issue 25
frans: Issue 28 - require default CRS, Issue 29 - require linking geometry to CRS
kerry: maybe it will go away on its own?
eparsons: never!
jeremy: point to real practices and decide what to adopt, rather than making a hard requirement.
<kerry> +q
<jtandy> joshlieberman: there is widespread practice to assume WGS84
<jtandy> ... mostly this works
<jtandy> joshlieberman: if we accumulate enough evidence of the assumption about WGS84 being broken, then we can make a statement
<jtandy> ... about people changing their practice
josh: good approach to examine practice. Maybe we will develop a requirement if practice turns out to be broken.
frans: people may be waiting for better "best practices". Continental drift may be catching up with us anyway.
<Linda> +1
<eparsons> +1 to chris
chris: agree that evidence is needed. At some point, though, a CRS does need to be understood, whether its a defined default or not.
<Zakim> jtandy, you wanted to ask about namespacing?
<ChrisLittle> +1
frans: remember that these are requirements, not yet solutions
<kerry> +1 to jeremy
jeremy: the base requirement is "where are things on the planet (or elsewhere)" Only 1% need to make CRS explicit, but what do we need to do for the 99%
<Alejandro_Llaves> yay!
<kerry> t+1 -- this is a solution but is so easy that it should not be too hard for anyone -- it is effectively a default while being explicit
<Alejandro_Llaves> +1 to Ed
<kerry> +1 to frans solution
frans: still good idea to have a wiki page for evidence and ideas.
+1 to wiki page
<kerry> ACTION: Frans to start a wiki page on evidence for CRS being needed or not [recorded in http://www.w3.org/2015/10/14-sdw-minutes.html#action01]
<trackbot> Created ACTION-82 - Start a wiki page on evidence for crs being needed or not [on Frans Knibbe - due 2015-10-21].
<eparsons> yay Linda !!!
<Linda> thanks Jeremy
jeremy: welcome on the editorial board to Linda
<jtandy> https://www.w3.org/2015/spatial/wiki/Linked-data
<Payam> yes, we had a quick discussion on it
Do you not have audio?
<Zakim> kerry, you wanted to mention mapping use cases to themes
<Payam> since the last meeting, there have been some new emails in the discussion thread and I will update the wiki
kerry: Linda has done some of the mapping of issues to requirements. I did some for the sensors thread.
<Linda> This is the link https://www.w3.org/2015/spatial/wiki/BP_Consolidated_Narratives
<Linda> yes both
<kerry> +1
<LarsG> +1
<jtandy> +1
jeremy: clear that different levels of abstraction are involved. Are we interested in both evident levels?
<eparsons> +1 the thing and its representation
<ChrisLittle> +1
+1
<ChrisLittle> complex geometry
jeremy: anything special about spatial data sets?
frans: high chance that spatial data is "professional" with curators / maintainers, etc.
joshlieberman: spatial data actually has different structure and granularity because it represents real world entities.
frans: another specialty: special links between data entities.
<eparsons> +1 for links
jeremy: "links are 1st class citizens" - consensus here. But what does that mean for link-poor formats?
<frans> I am afraid I did not understand the 3...2...1 question
<kerry> +q but json-ld does do links, doesn't it?
<eparsons> Josh : no best Practice yet..
josh: a consistent practice was identified in TB-11 as a need, but would have to be synthesized from disparate practice.
--for JSON
chris: tools are part of the need for those link-poor formats.
eparsons: out of time -- look forward to the 8 other issues next time.
<frans> What a great cliffhanger. I can not wait for the next edition of the meeting.
<billrobe_> :-) thanks everyone
<LarsG> Thanks, bye
<Alejandro_Llaves> thanks, bye!
<Linda> bye!
<Payam> thanks, bye
<kerry> bye!
bye thanks
<eparsons> bye all _ thanks
<ChrisLittle> bye
<frans> bye!