See also: IRC log
<eparsons> Morning all - give us a few minutes to get started
<kerry> evening!
<eparsons> hello kerry
<eparsons> trackbot, start meeting
<trackbot> Meeting: Spatial Data on the Web Working Group Teleconference
<trackbot> Date: 15 December 2016
<eparsons> morning LarsG
<eparsons> Chair: eparsons
<eparsons> agenda : https://www.w3.org/2015/spatial/wiki/Meetings:F2F4
<eparsons> no not that one
<eparsons> https://www.w3.org/2015/spatial/wiki/Meetings:F2F5
<eparsons> that one
<RaulGarciaCastro> HI!
<kerry> [eparsons cwalks through the agenda for today]
<kerry> [plan to go for curry in evening]
<kerry> scribe: kerry
<scribe> scribeNick: kerry
<billroberts> http://w3c.github.io//eo-qb/
billroberts: lets make a start on eoqb
<billroberts> kerry: introduces the EO-QB doc.
<billroberts> ...began at the start of 2016. Editors believe it is close to final, though with a few issues marked
<billroberts> ...the purpose of the document is to show how to do EO data using RDF data cube
<billroberts> ...no new ontologies but discussion of how to use existing ontologies
<billroberts> ...It's supported by an implementation
<billroberts> ...Part of the implementation uses the Discrete Global Grid System which is a forthcoming? perhaps complete standard of the OGC
<billroberts> ...and explains the advantages of using DGGS for earth observation data
<billroberts> ...It doesn't cover all kinds of coverage, but some possible extensions are described.
<billroberts> ...EO-QB makes use of the QB4ST note (to be discussed separately later) - extensions to the RDF Data Cube vocabulary for spatial and temporal dimensions
<billroberts> ChrisLittle: comments that he has been at a meeting in Taiwan, that the DGGS spec has been bounced by the planning committee of OGC
<billroberts> eparsons: this is related to potential IP issues
<billroberts> jtandy: DGGS doesn't appear in the bibliography. It probably should
<billroberts> ...geometry definitions are all using WKT (possibly because of use of GeoSPARQL use). Is that what we would recommend as a best practice?
<Zakim> kerry, you wanted to reply to jtandy
<billroberts> kerry: one of the TO-DOs is to sort out the references.
<billroberts> kerry: WKT - we are aware it is an issue in the best practices, and there is an issue in the EO-QB document that it needs review for alignment with best practices
<billroberts> jtandy: the BP group/doc is to some extent waiting for good practices that can be documented so a bit chicken and egg
<billroberts> eparsons: what's the realistic schedule for this document to be published and so be a reference for BP? Might be after BP is finalised
<billroberts> kerry: this is very close to final. So shouldn't be a problem for use in BP
<billroberts> ...but looking for advice from the BP group!
<Payam> +q
<billroberts> jtandy: clearly this is a 'practice' (use of WKT). Is EO-QB predicated on use of GeoSPARQL, which would require WKT?
<billroberts> kerry: no it doesn't depend on GeoSPARQL.
<billroberts> jtandy: could something be added to indicate that other approaches to describing geometry are possible?
<billroberts> kerry: this whole document is an example of how RDF Data Cube can be used for coverage data
<billroberts> ...also uses Time ontology and SSN - so they might need to be finalised
<billroberts> Payam: what is the intention of this document? Understand that it is an example of best practices. Are you going to link to particular best practices?
<billroberts> ...eg GeoSPARQL is mentioned in BP10
<billroberts> ...which way should the links go? BP to EO-QB or vice versa, or both?
<billroberts> kerry: yes, good idea to link it to the BP doc
<billroberts> kerry: let's add an issue for that
<jonblower> Struggling to hear a little bit - someone is typing close to the mic ;-)
<billroberts> kerry: aimed at linked data users, but also particularly at RDF Data Cube (hence statistical agency) audience
<billroberts> hi Jon!
<Zakim> jtandy, you wanted to check sotd
<billroberts> jtandy: could do with adding some text on the status of the document and planned changes before finalising
<billroberts> ...in the section at the top 'Status of the Document'
<billroberts> kerry: to confirm - would this be a condition of going to FWPD?
<billroberts> jtandy: yes
<Payam> +q
<billroberts> ...it should say 'there are relationships with other deliverables from SDWWG. Over the coming 3-4 months we expect to resolve these and update the note"
<billroberts> jtandy: happy with a vote subject to that condition
<billroberts> Payam: happy to work with kerry on the relation with BP
<scribe> ACTION: Payam to work with kerry to get BPs and eo-qb aligned [recorded in http://www.w3.org/2016/12/15-sdw-minutes.html#action01]
<trackbot> Created ACTION-229 - Work with kerry to get bps and eo-qb aligned [on Payam Barnaghi - due 2016-12-22].
<eparsons> Proposed : That the document is the FPWD with modifications in terms of status are made
<jtandy> +1
<Payam> +1
<eparsons> +1
<Linda> +1
+1
<billroberts> +1
<ahaller2> +1
<RaulGarciaCastro> +1
<ChrisLittle> +1
<eparsons> Resolved : That the document is the FPWD with modifications in terms of status are made
<LarsG> +1
bill says thanks and claps
work primarily by rob atkinson who is on holiday
<billroberts> kerry: as well as RDF Data Cube, it also draws on other existing ontologies
<billroberts> ...it's quite small. Only about 10 properties and classes
<billroberts> ...it's closely related to the Best Practices
<Linda> http://w3c.github.io/sdw/qb4st/
<billroberts> ...references GeoSPARQL and there is an issue about how to interlink wiht that and other BPs
<Payam> +q
ChrisLittle: qb is very generic and does not help with dimensions
<billroberts> ChrisLittle: I'm very supportive of the work. QB is very generic and doesn't have anything about coordinates in a dimension. Current QB dimensions don't have ordering for example
ChrisLittle: i am very supportive
of this singling out of some dimensions
... also supporting partitioning of dimensions
<billroberts> Payam: is anyone using this?
payam asks if there are any groups using this?
<billroberts> (sorry kerry I'll hand scribing back to you now!)
chris: maybe not for rdf ata but for the metadata describing data
payam; can we add this to the doc?
billroberts: similar to eoqb, there are a few known issues but reasnably well advanced
<laurent_oz> A useful reference in this space http://meaningfulspatialstatistics.org/
billroberts: inviting conditions
on the vote to publish?
... things that can be fixed up aftewards
Linda: notes respec and html errors
<eparsons> Proposed that http://w3c.github.io/sdw/qb4st/ becomes FPWD with html errors corrected
<jtandy> +1
<ChrisLittle> +1
<Payam> +1
<Linda> +1
<eparsons> +1
<LarsG> +1
+1
<ClausStadler> +1
<RaulGarciaCastro> +1
<billroberts> +1
<eparsons> Resolved that http://w3c.github.io/sdw/qb4st/ becomes FPWD with html errors corrected
<billroberts> http://w3c.github.io/sdw/coverage-json/
billroberts: well done Rob
effort led by Jon Blower and Maaik Reichart a reading
<jonblower> can't hear anything over typing
scribe: for web pages and web
applications in particular
... more than the other docs there is significant uncertainly
around relationship of thsi not to the spec (is this it , or is
it about it?)
... jon has discussed with phil and scott
jonblower: [having trouble
hearing over typing]
... this was started in MELODIES project before we joined the
activity of the wg
... so we started to develop the spec elsewhere
... but now in the wg it is not clear how to express out
outputs in and after the WG
... is a data format based on JSON for coverage data
is a format for web servers to exchange with web apps
for coverage data in rich web applications
as data analysis and visualisation can be done in the browser
scribe: some relation to rdf ---
a brief discussion on how to convert cov json to rdf in section
2.6
... says how to convert the json to rdf triples, mainly
focusing on the metadata rather than the data
... useful if you are into rdf
... that conversion is to an rdf structure that is not
standardised, we just made this up at the time for a poc
... so is only an interesting expt at present -- needs rounding
off
... so as bill was saying
... the our "NOTE" on git hub is onformative, does not contain
the spec itself
quesiton is whther the spec should indeed be in there
scribe: so that it is formalised
and can be pointed to
... althogh a note, not a rec
... but this is a prblem from a maintenance point of view
<LarsG> s/informative/informative/
scribe: so we won't be updating
the spec any morein the note when the WG is over
... we could put the spec in the note and make a big message to
point to the latest version eslewhere from the Note
... taking advice on this
... scott Simmons said the standard incubator might be a way to
take forward
... important that it can be taken forward and is not forzen
here
ChrisLittle: if sdw stops next
year OGC has a few ways of going on with this
... when we discussed this before you had single dimension in
the json
... has this gone forward to multidimensions?
jonblower: no, because json does not support
<eparsons> ACTION: jonblower to add a section on multi-dimension arrays [recorded in http://www.w3.org/2016/12/15-sdw-minutes.html#action02]
<trackbot> Created ACTION-230 - Add a section on multi-dimension arrays [on Jon Blower - due 2016-12-22].
<Payam> +q
billroberts: important to make
sure spec is free of patent issues and will never be
encumbered
... this is a benefit of brining the spec into this WD
document
... iprecedent for specs to evolve after publication but is a
question hhow to steer readers to the right place
eparsons: either standards body
has mechanisms, that should not be a concern
... the more fundamental question is do you want the note to
identify the problem and context and have the spec developed
elsewhere? this may be the best way
... and the actual normative part in another w3c or ogc
activity?
jonblower: that is where I was
thinking, but i am aware that this WG has a lot of activities
and there has not been a lot of technical discussion on this
work inp articular
... so for advancing the standard a more specilist grop might
be useful to drive it forward
... so it might be more accurate to say this group has
motivated and driven the work but the spec goes elsewhere for
now
... I think Phil would like the spec as part of the note
... my problem is lots of versions in different places so the
community knows which one to get
... that is normative
jtandy: i think that copies
littered around the web is a good thing, i think the scrutiny
of the group may not be strong enough
... so I like linking to it but will it be a durable
link?
... and we need a licence statment in the note
<billroberts> https://covjson.org/spec/
jonblower: is now living on the
covjson.org website that is durable
... can see advantages in going forward through the new
stnadards incubator process
... which gives you a github place maybe
the durable url exists but maybe the future standards approach affects this
jtandy: as long as that durable standard forwards to the right place durability this will be useful
<Linda> +1
billroberts: cc licence applies
-- can put this in the note
... phila said there is no patent statement and no warranty
about patent-free-ness -- we need to find a way to warrant
that
eparsons: don't worry unduly -- this can be done
jonblower: my understanding is that we cannot make that assertion --- but we can by copying the spec into the doc
eparsons: but is that a big concern for this note?
jonblower: need to clarify
<Zakim> kerry, you wanted to speak on patent issue
jonblower: conclusion would be we keep the scope of hte note as informative/motivating
<eparsons> kerry : different perspective - phila not keen on a note that is just informative..
<eparsons> billroberts : We need phila to clarify - saw advantages to having spec but not as strong an opinion as suggusted
jonblower: note is informative
anyway
... but I do unerstand the point about the patent
... if it comes to it i am happy to copy in to spec with a big
note to say that it should not be used but to look
elsewhere
ChrisLittle: [soft]
eparsons: chrislittle does not like hypertext
jonblower: is 5 pages or so --
adding the spec will quadruple the lenght which makes it a bit
harder to read
... but as a deal breaker am happy to put spec copy in
... but note is informative so not a great place for a spec but
phila was happy with this
eparsons: at next coverages call or what to resolve this?
billroberts: we cannot vote on
this until that is resolved as it is a significant issue
... need to develop a concret proposal for this and then bring
it back for a vote in a telecon in the new year
... late Jan or so
jonblower: agrees
<eparsons> ACTION: billroberts to discuss with phila et al to bring back for a vote at a plenary call in the new year [recorded in http://www.w3.org/2016/12/15-sdw-minutes.html#action03]
<trackbot> Created ACTION-231 - Discuss with phila et al to bring back for a vote at a plenary call in the new year [on Bill Roberts - due 2016-12-22].
billroberts: two out of three ain't bad!
eparsons: working out the way to
make this accessible is hte right thing to do -- useful
discussion
... thansk jon
<billroberts> thanks very much Jon
<Payam> https://www.w3.org/2015/spatial/wiki/Coverages_in_Linked_Data
jonblower: [returns the thanks]
Payam: can we add explanation how this approach would be used and why --- to distinguish from the others
eparsons: yes, so why do we have 3 solutions? what is the rationale?
jtandy: qb4st is not separate, really a complement
<Payam> +q
jtandy: differnt communities use
different tech cnages to achieve differnt outcomes
... recordnises the polarised nature of our community
ChrisLittle: also [quiet] layered approach.. specific encodings.. justified
<ChrisLittle> +1 to Separate QB and QB4ST
billroberts: agress eo-qb and
qb4st should stay separate
... we have two differnt approaches becuase there are multiple
ways
... the web has many user communities
... with different subsets of people who want to put data on
the web, we just need to say who needs what
Payam: [mised first
question]
... are there any other solutions we need to refernce
jtandy: (summarises from
eo-qb)
... it is not proposing storing data in a triple store -- this
is impoertnat
jonblower: do need to link to the
cov world of the ogc and we need to cover off on this
... peter Baumann might help
eparsons: what is the mechanism
for us to provide this coverage context overview/
... how do we make sure we do not give the impression this is
all there is?
... where does this go?
ChrisLittle: robatkinson has a useful bit in the qb4st doc --- cut and paste to other docs might do?
billroberts: agrees should go in each doc
jtandy: could write once and link to it from each
[general agreement]
<jonblower> I'm afraid I won't be rejoining you as I have other meetings, but have fun and thanks for all the discussion
eparsons: break until 11:00 am GMT
s/impoertant/important/
<eparsons> we are back almost
<laurent_oz> * Laurent waving to everyone
<eparsons> Hello laurent_oz you are welcome
<eparsons> would you like to say hello
<laurent_oz> * Yes, so I can test
scribe?
<scribe> scribe: Payam
<scribe> scribenick: Payam
This session: SSN
ahaller2_ working draft was published on Monday; there have been some editorial changes since and some additional changes
<jtandy> present?
ahaller2_ changes: used a different tool to generate the ontology document (name of the software?)
ahaller2_ other changes: changes to SSN ontology; the major change is the SSN dolce alignment is included
ahaller2_ new ssn to dolce and new ssn to the old ssn; SOSA core ontology has been also included into SSN
ahaller2_ alignments to PROV and alignment to O&M: placeholders have been added but they are not documented yet
ahaller2_ there are also many issues that are included in the SSN document; some don't have a number (please add the numbers); ahaller2_ will fix these
ahaller2_ we need to discuss treatment of the values and also samples and possible solutions (linking to SOSA core and sub-class realtionships)
ahaller2_ other ontologies in the core; Dublin core is included but not many others; SKOS possibly won't be included (there seem to be a discussion about this in the mailing list)
kerry: there have been people who
have not been editor(s) of the documents and have been issuing
PULL requests- ONLY editors should do this
... is unhappy and please be careful :-)
<RaulGarciaCastro> kerry, do you mean creating pull requests or accepting them?
ahaller2_: no one made any pushes to the main brunch on github
<RaulGarciaCastro> OK
kerry means accepting pull requests if you are not an editor
<ahaller2_> there was a pull request by simon: https://github.com/w3c/sdw/pulls
jtandy editors are the people who should do the merge
<kerry> there is nothing to stop me pulling into gh-pages for bp!
jtandy there seem to be some merges done by none-editors
kerry referring to accepting pull requests by non-editors but not issuing the pull requests
ahaller2_ would like to discuss the treatment of units of measurements and values
ahaller2_ we don't use dolce; so there could be issue here ; SSN (old) used DOLCE for this
kerry is in favour of adding this back to SSN without using DOLCE and same for units of measurment
eparsons are close enough to make a proposal for these?
eparsons how do you want to address these?
ahaller2_ we can go through the document and address these
ahaller2_ issue number 999? has been raised but has not been discussed and there is no reference back to the issue tracker; we either should remove this or a reference to issue tracker should be included
ahaller2_ the question is if we need more issues - question to RaulGarciaCastro and DanhLePhuoc
<ahaller2_> https://www.w3.org/2015/spatial/track/issues/108
<ahaller2_> https://www.w3.org/2015/spatial/track/issues/109
eparsons: the main issues is: numbering and discussing and dealing with the "issues" raised in relation to SSN- we can't leave them outstanding
kerry issues with numbers on them (those with "999" number); they can be treated as they were in the document/tracker- but this shouldn't stop us from voting on the document
eparsons is worried about numbering and consistency
<ahaller2_> 999 issues don't exist in the issue tracker
<ahaller2_> +1 for jtandy, broken links are UNCOOL
jtandy those will be considered as broken links and won't be passed to the webmaster
kerry there have been changes to ontologies that are cited in the document and those changes are not reflected in the document; this will create some inconsistencies
<laurent_oz> +1 looks like the document and the ontologies are living separately
kerry one possible solution is to revert the document to an older version
<laurent_oz> It's unclear which ones are in or not (and they should be in a single place on GitHub)
eparsons suggests to work on the latest version and try to resolve the existing issues/inconsistencies
ahaller2_ agrees to work on the current version and fix the issues
ahaller2_ ontologies in the document are the key concern but not those published in the github- the ontologies may change but the descriptions in the document are the main referecne
<laurent_oz> I personally use the ontologies to automatically generate graphical representation of them. I really NEED ontologies up-to-date.
<laurent_oz> Not having the right ontologies is a reason for me to vote NO.
kerry we discuss this with Phil; we need to tell Phil which version is consistent with the document; the documentation and the published ontology should be consistent (there seem to be inconsistent in the current version)
eparsons suggests to work on some of the open issues
ahaller2_ proposed to go through the document and find issues without number and decide whether they should be an issue
kerry suggests to accept all of the issues without number and then add them to issue tracker
<kerry> fine -- sorry for the interuuption!
ahaller2_ some of the may not be an issue- let's check them
<ahaller2_> http://w3c.github.io/sdw/ssn/
<ahaller2_> "In fact the OGC SWE standards provided separate provider (sensor) and consumer (observation, data) viewpoints, starting in 2002.
<jtandy> see http://w3c.github.io/sdw/ssn/#intro
ChrisLittle SWE: Sensor Web Enablement
jtandy this issue refers to clarify the OGC SWE standards (but is it?)
we are not sure what this issue refers to... we try to figure out who put that issue in;
jtandy uses his github and detective skills to find this out
<ahaller2_> https://github.com/w3c/sdw/commit/6d146e4eaee757255be79cc9651944554fd6dcf5
<jtandy> see https://github.com/w3c/sdw/blame/gh-pages/ssn/index.html#L124
jtandy this probably refers to the fact that OGC SWE work came before the current work and we should keep the references to this
kerry not sure if this is the right interpretation of the issue
jtandy sensorML is the sensor focused and the O&M is abut the data usage part and they are separated to two different parts
<ahaller2_> "Need to explain rdfs:isDefinedBy arrows."
jtandy is working on rephrasing/clarifying this part
ahaller2_ agrees with this issue; we need to add some brief description or remove rdfs:isDefinedBy arrows." from the graph
<RaulGarciaCastro> +1 to remove
<laurent_oz> Suggest to remove it.
<RaulGarciaCastro> (until some explanation is given)
ahaller2_ suggests to remove it
ahaller2_ issue will be also removed- the arrows will be remove from the graph
<kerry> +1
ahaller2_ section 8
<laurent_oz> No to section 8
ahaller2_ 1st question: whether we should keep or remove this section 2nd question: are there any issue in this section?
<ahaller2_> https://www.w3.org/2015/spatial/track/issues/53
kerry suggests that it is already mentioned in the document- should be removed
kerry it is in issue in number 53 in the document; so this section should be removed
<ahaller2_> +1 to remove section 8 for now, as it is in the work plan
Linda remove the issue or remove the section?
kerry remove the section
<laurent_oz> The priority for me is to empty the issue queue on the tracker (with the rationale attached).
eparsons whether we refer to the fact this won't be section on its own but some parts are already (or will be) included in the document
<jtandy> @jtandy suggests the following text for the first ISSUE 999: "In [SSN section 1. Introduction](http://w3c.github.io/sdw/ssn/#intro) OGCs Sensor Web Enablement (SWE) is cited. It would be worth clarifying that SWE evolving from way back in 2002 provides distinct provider- and consumer-focused standards; SensorML (dealing with sensors) and O&M (dealing with observations and data). "
eparsons if you don't have time to deal with it (and cover those areas) then better to remove the section and related issues
ahaller2_ proposes to remove the section
<Zakim> jtandy, you wanted to talk through the new issue text
<laurent_oz> NEWBIE question: when was the document structure discussed?
jtandy going back to the first "999" issue; he has posted it above
jtandy: suggests the following text for the first ISSUE 999: "In [SSN section 1. Introduction](http://w3c.github.io/sdw/ssn/#intro) OGCs Sensor Web Enablement (SWE) is cited. It would be worth clarifying that SWE evolving from way back in 2002 provides distinct provider- and consumer-focused standards; SensorML (dealing with sensors) and O&M (dealing with observations and data). "
<ahaller2_> +1 to raise that issue and include that in the document
<RaulGarciaCastro> +1
<Linda> +1
<kerry> +1
jtandy an issue need to be added to the tracker and the document needss to be updated to reflect this
<DanhLePhuoc> +1
<eparsons> action ahaller2_ to update issue with jtandy 's text
<trackbot> Error finding 'ahaller2_'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
<ChrisLittle> +0 no views on this
<kerry> the correponding issue is issue-53
<ahaller2_> proposal to remove section 8, as it is already mentioned in the work plan in section 10, under issue 53. No prioritisation of issues has yet been done, and it is unclear if we will be able to produce a PROV-O alignment
+1
<ahaller2_> +1
<ClausStadler> +1
<RaulGarciaCastro> +1
ahaller2_ section 1- there is another unnumbered issue- referring to O&M mapping
laurent_oz: the mapping table is mainly about the core but here is the reference to O&M TL? - suggests to remove it
kerry this is similar to the previous case; we need to discuss this and then decide if this is an issue
ahaller2_ there is a little bit of difference here compared to the previous one
<laurent_oz> The priority is to consolidate the relationship between SSN and SOSA-core (and work on "not confusing" the readers). Adding all the other ones is not helping.
ahaller2_ is remove this issue we need to describe to link to the SSN O&M alignment
Linda thinks it is useful to have an alignment with O&M- useful to keep this alignment; it is especially important to the OGC community
kerry it is in the document - work plan, issue number 4;
kerry this refers to ways that it should be done and we need to discuss this and decide what to include
<laurent_oz> One key question is which O&M ontology we are talking about. Adding an alignment means that you have identified one version which is stable (and/or are committed to publish it).
eparsons as editors you should decide and define the scope of the work
<ahaller2_> agree with ed and linda, I think this section can remain
laurent_oz: alignment could mean that we are referring to another O&M ontology; here we want to talk about ontology to ontology alignment
eparsons editors should decide on this
ahaller2_ proposes to keep the section and the alignment ... hopes we manage to provide this
<Linda> +1
<laurent_oz> -1
ahaller2_ we can align and update the text to address all the concerns
kerry mapping to O&M .... we need to discuss: what we should do here and how to do it
<kerry> +1
ahaller2_ proposes to remove the sentence and raise and issue and add a new brief description (to raise the issue) and we vote on it tomorrow
<RaulGarciaCastro> +1
ahaller2_ to remove and update/raise the issue
<ahaller2_> https://github.com/w3c/sdw/blob/gh-pages/ssn/index.html
ahaller2_ let's look at at the github history
<ahaller2_> https://github.com/w3c/sdw/commit/6d146e4eaee757255be79cc9651944554fd6dcf5
we are discussing the remaining "999" issues and the changes
<laurent_oz> Not sure about the process here: should we use the tracker as the primary list of issues or the document (e.g. ISSUE-104 describing the ssn alignment in the spec) or is it a case of issue declared twice - need some cleanup!
ahaller2_ added something to issue number 92
<ahaller2_> "It is needed by the working group UCR, but is in a separate modeul in O&M. Sampling is a key aspect of most observational strategies. "
kerry: issue number 46- is being put back again (it was removed)
<kerry> issue-46
<trackbot> issue-46 -- Should the movement of sensor become a direct subclass of dul:object? -- closed
<trackbot> http://www.w3.org/2015/spatial/track/issues/46
eparsons suggests to spend sometime to go through this and discuss this later rather that going through them now....
<Linda> I don't see issue 46 in the document
laurent_oz: is asking about the process; where to start: from issues or go through the document...
ahaller2_ issues are all in the issue tracker but there are some issues that is in the tracker but not in the document; some have been addressed and removed from the document
kerry agrees not to work on these on-the-fly
kerry issue number "46" is an issue ;-) (the scribe got a bit confused here....what is an issue and what is not)
<kerry> there is another issue-99 that we missed too " Why is the SOSA documentation 'non-normative"
ahaller2_ the OZ team will work on this later during the (next) day...
<laurent_oz> Discussion on normative vs. non normative (and what's going in a REC eventually)
billroberts a note document is none normative...
kerry notes: non normative
kerry SSN is normative- the SSN document should mark normative and non normative text
<eparsons> very nearly lunchtime
ahaller2_ that means some parts should be changed/marked normative/no normative
<jtandy> +1
eparsons we are breaking for lunch
<laurent_oz> * Laurent waving goodbye for today
we will back at 13:00 GMT
<laurent_oz> * Raul do you want to have a chat over IRC tomorow?
<ChrisLittle> Bye and thanks
<RaulGarciaCastro> laurent_oz: OK
we will start in 5 mins
<jtandy> chair: jtandy
jtandy let's look at the BP document for 20 mins and then vote on the topics/sections that we need to prioritise
http://www.w3.org/TR/sdw-bp/#bestPractices
ChrisLittle: we need to add references from the BP document to other documents
<RaulGarciaCastro> Yes
jtandy we need to review the BP document and make sure all the citation/evidence are up-to-date
jtandy we take 20mins to read the BP document
http://www.w3.org/TR/sdw-bp/#bestPractices
<jtandy> meeting resumes at 13:40 UTC
<kerry> me asks is webex broken -- I have lost sound?
yes we are here
<jtandy> resuming discussion in 3 minutes ... we're looking to prioritise our efforts over the next 2 days around the BP
<jtandy> ... 1 minute
we are back
jtandy we are now going to identify the priorities
jtandy going through the webx list and asking about the priorities
jtandy there will another session tomorrow afternoon about BPs
billrobe_ 1) BP4- it would be nice if we can be more specific about what schema.org proposes to use and the metadata form schema.org and discuss how to do this
billrobe_ 2) BP8: when talk... there could be some overlap with spatial ontology; mapping to geospatial ontologies/spatial things being linked to different thongs and different resolutions - BPs how to do this
ClemensPortele sent a list list of comments to the mailinglist
ClemensPortele would like to raise two items 1) when we have rich models that use many ISO concepts; in GML and related schema we have representations for this generic objects; but in JSON we have a problem on how to describe this complex concepts... we provide some describe for geometry part but not for other parts... we should provide more descriptions for people who use JSON more than RDF
ClemensPortele is not clear about BP1- for his it doesn't make much sense that it is inconsistent with some of the descriptions/criticism we have about how the metadata is handled in SDIs; here it seems we say that how in fact we should dod this; this seems to be confusing.
ClemensPortele for example in GML we do have an annex that all the ISO classes are mapped to show what are the equivalent concepts; there is perhaps some mapping between O&M and SOSA and we need to be explicit about these
jtandy refers to the discussion at TPAC and what is in the scope and what we should include
ClemensPortele 's concern is that we shouldn't be very domain specific... e.g. we shouldn't say how to model your road specific ontology....but some building blocks are in the scope
Klaus: modelling of multiple geometries for resources
<billrobe_> Payam: prepared list of missing items per best practice
<billrobe_> ...in each BP there is a section 'how to test'
<billrobe_> ...should we keep that and will we have time to fill them in? or should we remove
<billrobe_> jtandy: we should retain the how-to-test section
<billrobe_> ...for example in BP7 this can be very simple - find a spatial thing and see if it has a URI
<billrobe_> Payam: in BP2, there is an example mentioning SSN, but linking to top level document. Would be better to link to a specific relevant part
<billrobe_> kerry: there could be useful references in EO-QB or QB4ST, more relevant than SSN particularly
<billrobe_> Payam: BP5, issue 125 on positional accuracy - is there someone who can add more detail to that?
<billrobe_> jtandy: example 9 illustrates how to do this with DQV
AndreaPerego there seem to be a problem with your audio
<billrobe_> hi kerry - yes we are, dealing with interference on the webex sound
cna you please mute
<billrobe_> kerry: I could add an example of using SSN to describe measurement accuracy
<billrobe_> jtandy: yes examples would be useful
issue 125; do you think it is resolved?
issue 125 resolved; agree?
+1
<Linda> +1
<billrobe_> +1
<ClemensPortele> +1
AndreaPerego you audio is ok now
<kerry> +1 to putting in a sao example
<billrobe_> Payam: BP6, issue 196 - 'things change over time'. Also issue 356 about time series. Payam has an example of using a stream annotation ontology example of time series
<billrobe_> Clemens: one option is to only include the latest version, then do something like the Wayback machine if you want to get older versions
<billrobe_> ...maybe just include metadata on when it is updated
ClemensPortele understand it as an option to only keep the last observations but not all the previous data; only add the metadata for the latest updates
<AndreaPerego> I wonder whether DWBP B7 ("Provide a version indicator") may be relevant here: https://www.w3.org/TR/dwbp/#VersioningInfo
kerry recording time-series data should be captured here and also what ClemensPortele said
<Linda> @Andrea It's referenced already in our BP
jtandy it will be useful something like SAO but he is concerned about RDF bias
ClemensPortele there is an ongoing activity in "moving features" OGC14.3
jtandy it will be useful to add an encoding such as cov-json
billrobe_ we are risking to make this BP too comprehensive but less useful
billrobe_ we should differentiate between time-series model and versioning model
jtandy we have RDF semantic, OGC and JSON community and we often provide 3 different examples; it will be good if we can find some points of convergence between these communities
jtandy if we find some less comprehensive examples then we might be able to find some areas for this convergence between the communities
ClemensPortele if we put too much detail we risk that people won't read it; we should focus on important concepts and for other related concepts add links to other sources; we only discuss examples that specify crucial points and concepts related to the BPs.
ClemensPortele examples can be brief descriptiabouts about e.g. you can use model/standard "..." and then providing a link to the source that describes that model/standard
kerry is happy with this approach
kerry time-series should still stay relevant
<billrobe_> Payam: BP4 issue 180: 'example required for search engine indexing of dataset'
<billrobe_> ...issue 179 closely related
<billrobe_> jtandy: Clemens offered to write some examples from LD Proxy work, which would cover 447
<billrobe_> ...search engines index primarily HTML (maybe also XML documents such as GML and KML). As far as we know they don't index JSON
<billrobe_> Clemens: that's documented in the report we produced around this. I could add some info from that work
<billrobe_> ...how we used schema.org
<billrobe_> ...and could refer to that report on what works and what doesn't
<billrobe_> jtandy: we could add a Note on what search engines will index
+q
<billrobe_> Clemens: first and foremost they index HTML. Can potentially improve the ranking (to an unknown extent) by schema.org annotations
<billrobe_> ...also when others link to your data
<Linda> http://geo4web-testbed.github.io/topic4/
ACTION ClemensPortele to update BP4 examples and add a description on what is indexed and maybe link to some examples
<trackbot> Error finding 'ClemensPortele'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
ACTION ClemensPortele to update BP4 examples and add a description on what is indexed and maybe link to some examples
<trackbot> Error finding 'ClemensPortele'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
ClemensPortele we shouldn't get into search engine optimisation
ClemensPortele we can report on what search engines look at
ClemensPortele look at what search engine providers say about the type of documents that they index and providing more annotated data according to those
Klaus: we should also look at
what could happen in future
... BP is telling people what are is the ways of doing things
at the moment and ....
ACTION ClemensPortele to provide an edit/update of BP4 by end of January 2017
<trackbot> Error finding 'ClemensPortele'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
<scribe> ACTION: CPortele to update BP4 examples and add a description on what is indexed and maybe link to some examples [recorded in http://www.w3.org/2016/12/15-sdw-minutes.html#action04]
<trackbot> Created ACTION-232 - Update bp4 examples and add a description on what is indexed and maybe link to some examples [on Clemens Portele - due 2016-12-22].
<scribe> ACTION: CPortele to provide an edit/update of BP4 by end of January 2017 [recorded in http://www.w3.org/2016/12/15-sdw-minutes.html#action05]
<trackbot> Created ACTION-233 - Provide an edit/update of bp4 by end of january 2017 [on Clemens Portele - due 2016-12-22].
<scribe> ACTION: Eparsons BP4: to provide a schema.org snippet and to add a reference and/or some statistics related to schema.org places [recorded in http://www.w3.org/2016/12/15-sdw-minutes.html#action06]
<trackbot> Created ACTION-234 - bp4: to provide a schema.org snippet and to add a reference and/or some statistics related to schema.org places [on Ed Parsons - due 2016-12-22].
jtandy proposes to close issue 181
<Zakim> AndreaPerego, you wanted to stress the objective of making spatial data discoverable - without knowing in advance where to find them
AndreaPerego one of the principle issues how to get out of the current situation of the spatial data and understand the issue that search engines do not index most of the spatial data on the web
AndreaPerego for example it is common to go to a catalogue and find a dataset but this often is not the case for the spatial data
AndreaPerego giving more visibility to spatial data on the web
jtandy summarises: one of the most important things we should encourage people to do is to make their data visible to search engine; creating web pages that describes the datasets...
ClemensPortele we need these entry points
eparsons even having an HMTL page that describes there is a wms dataset here can be useful
jtandy we should make it simple; say what it is, how to access it and ....
ClemensPortele says this in fact should be BP1;
ClemensPortele the first BP should be the most important one
ClemensPortele most people won't be interested in service itself;
<Linda> Example landing page from testbed: http://www.ldproxy.net/bag
ClemensPortele you need links to access data or a sub-set of it
eparsons indexible by search engines is just a preset that says make it readable and usable on the web- if it is not human readable/useable but it not useful for search engines as well...
<Zakim> LarsG, you wanted to talk about order of BPs
<eparsons> +1 to implied significance of BP order (human nature)
LarsG we should tell people where to start and what to do (using the BP document)
<kerry> +1 to ed's comment
eparsons we should deal with metadata at last stage
eparsons suggests to re-arrange the numbering for the final version
jtandy BP numbers will change
q
AndreaPerego publishing spatial data on human readable way- technically this is trivial
AndreaPerego we don't do that- we access geo-spatial services but they are not meant to be usable on the web
AndreaPerego people should be able to access the original data and follow the links to ...
AndreaPerego technologies applied to spatial data on the web should benefit both human and machines
ClemensPortele it doesn't always work out of the box- some of the common practices are not designed to provide persistent links; the links or data behind it change over time; we need to make sure the links are persistent
<AndreaPerego> +100 to ClemensPortele - something needs to be changed on how geodata are managed.
eparsons we need to talk about sharing data and what sharing data means
ClemensPortele the thought is there...
<jtandy> ... coming to @AndreaPerego in a moment
AndreaPerego in order to share spatial data on the web, we need to change how we manage the data... it is not only bringing the data to the web level; it is also important to see how the data is managed and how it is used...
AndreaPerego: making data more sharable outside geo-spatial domain - but a consistent use of identifiers would be beneficial for the geospatial infrastructure itself.
we are going to take a coffee break (for 15 mins); they have nice coffee here
<AndreaPerego> s/AndreaPerego making daya more sharable outside geo-spatial domain/AndreaPerego: making daya more sharable outside geo-spatial domain - but a consistent use of identifiers would be also beneficial for the geospatial infrastructure itself.
15: 35 GMT/UTC
<RaulGarciaCastro> ok
thanks @AndreaPerego for the update
<eparsons> And we are back !!
next is BP7
<eparsons> Kerry go to bed !!!
we are discussing issue 440
this is related to use of a third-party URI
@jtandy explains that much of this BP is updated to reflect the concept that there are already some URIs that explain the data or asking people to create their own
eparsons databases we have (for the same thing?) might be different and have different URIs
jtandy reads the BP description and Anne Frank's house example
ClemensPortele doesn't see any real example that you use a DBPedia URI for one's spatial data; but one can create a link to her/his spatial data and add link to DBpedia
billrobe_ describes RDFCube ... it is easier that people use the same identifier to the same data; but you ned to make sure that the other URI describes all the attributes that you want...
ClemensPortele suggests to create your own URI and then adding link to other URI
billrobe_ then there could be several URIs referring to the same thing
ClemensPortele this a question on how the URI should be used
billrobe_ it is not a desirable situation that you have all in one description....
jtandy using an identifier to refer to subject of a record
billrobe_ when we are using identifiers we are using them as the object of triples ...
ClemensPortele we use them as subjects...
ClemensPortele we can reference a DBpedia entry as an object
jtandy summarises: using URIs make sense to be used as a subject and as the subject .... and then you can provide an API to query based on object identifiers...
ClemensPortele making links to other well-known objects
Klaus: describing and identifying your resources and then linking to other related entries
Linda when you publish your won data make your own URI; don't look for other URIs
ClemensPortele DWBP seems to suggest: reuse URIs
ClausStadler: there are two use-cases for their suggestion/approach: people refer to the same thing using the same URI; or linking to the same objects....
<Linda> When you're publishing your own resources, create your own URIs. When you're linking to objects look if wellknown resources already exist and link to those; this is described in BP14.
ClausStadlerStadlerStadler: for best practice makes sense don't use DBpedia as your primary identifier
my apologies @ClausStadler - I have been misspelling his name... sorry :-(
We can close 440; agree?
jtandy will do an update and will close 440
jtandy issue 358; we have covered this in the BP text
eparsons wished if we could express geo-spatial containment relationships - it is not going to happen....
Linda can we add one more example- a clearer example
<ClausStadler> To rephrase my statement: In order to be able to discriminate where statements related to a resource originate, e.g. different agencies making statements about the population of London, each agency should mint their own resource for that expressing this information. However, when creating an integrated view of London for analysis, you may attach all the external information to that identifier. However, I would not consider publishing such a datase[CUT]
jtandy will update this BP
<ClausStadler> Instead, one should mint new URIs for the integrated view and link it to the resource its an integrated view of
we will discuss issue 208 for the next revision
next topic: @billrobe_
@billrobe_ discusses WP8
billrobe_ how you link to different geometry
billrobe_: we have some data about some regions with different geometry; CRS is one of the issues; in the UK different CRSs are used;
billrobe_ we want to offer both CRS descriptions
billrobe_ wants to allow people to link from a geometry to their own entries
billrobe_ people most probably care about have access to GIS and linking to a geo-json?
jtandy we tend not to use RDF and/or triple stores
jtandy in geo-json you are limited to one geometry
jtandy with geo-json you are limited to one CRS... the easiest way to use two service points; one gives you the ..polygon... and one ....
ClemensPortele .... you could say in an API or a URI that you can specify CRS and/or resolution - WSF and RGS(?) services do this
ClemensPortele geometry can be resource and if a feature has multiple resources ; the geometry should have sufficient metat-data to differentiate between them
eparsons we don't want to add too much requirements that will discourage people...
jtandy if you do have the need to have to CRSs then you should be able to do this and there should be a best practice for it
eparsons could be different end-point solution
Linda talking about an example from a Dutch system in which they use multiple entries...
Linda they publish feature, feature has geometry; geometry has WKT property which has a coordinate in global positioning system; in addition they have a sub-property; and the sub-property is a WKT-RD (RD stands for Dutch coordinate system)
billrobe_ if there is a consensus way we should follow that....
ClausStadler won't model it that way... then you have one resource with two literals and then you won't be able to differentiate how to ...
ClausStadler he would make it possible to use meta-data to differentiate between resources
ClausStadler refers to geometry resources
ClemensPortele that's why the CRS is there
jtandy on the web you make an HTTP requests you get something back; in a triple store is you return a CRS that is good; how do you differentiate when your data has multiple CRSs; @ClemensPortele said .... have been using a query parameter to address this.
eparsons when you chose to publish your data... it should be explicitly mention that what versions of data you publish (be explicit about your CRS); you can publish them or generate them on-the-fly but you need to explicit about this; this should be part of metadata when you offer the data.
eparsons having an endpoint that you link to.... try to publish a global and local version of that....
jtandy summarises: how you store things is your decision; when you publish be explicit about your CRS (at least one); if you have more than one you should allow people to choose between them either by using a parameter or @eparsons using different end-points/URIs
<AndreaPerego> +1 to URIs for geometries.
Linda Irish... don't provide link to all their geometry....
+q
ClemensPortele if you want spatial thing you want the geometry of it....
<Linda> [recap] Irish spatial linked data publication doesn't give URI to their geometries, they are blank nodes. They want people to link to their spatial things not the geometries.
<billrob__> http://statistics.gov.scot/doc/statistical-geography/S12000033?tab=downloads
billrob__ what we currently don't have is a recommended way to provide machine-readable metadata from a resource to its geometry data
billrob__ this group can make a recommendation to address this
jtandy summarises: if you want to give people the opportunity to choose a geometry, you prefer to get it from an API (to say what CRS) is available
billrob__ this is one step ahead; RDF metadata can provide the main information regarding the geometry
eparsons we are getting to spatial ontology issues
Linda expects the spatial ontology to provide (some_ of) these...
jtandy it won't be only rdf; we have other forms...
jtandy making names and providing metadata about them;
ClemensPortele and ClausStadler do not agree with this approach...
billrob__ in practice we would like to serve the geometry from a file (instead of a database)
ClausStadler explains an example that provides the geometry from a file
eparsons we must not forget the other BPs (being indexible and persistent)
jtandy at some point you need to know which file you should pick
billrob__ says that there not standard way to do this;
jtandy can we recommend a way to do this?
jtandy we can talk about the problems and patterns that are used
ClausStadler with current practices and patterns these are possible but these maybe not the best practices
jtandy an action to come back to what @billroberts mentioned and discuss how to address some of the existing issues
<scribe> ACTION: jtandy to speak with @billroberts and update BP8 [recorded in http://www.w3.org/2016/12/15-sdw-minutes.html#action07]
<trackbot> Created ACTION-235 - Speak with @billroberts and update bp8 [on Jeremy Tandy - due 2016-12-22].
jtandy asking a question: asking @billroberts as an implementer what would you tell an implementer how you publish your data and what vocabulary you use.
billroberts depends on what you want to do.....
billroberts providing persistent identifier for things (e.g. hospitals), providing information about where it is ... .giving it an address and a postcode (using schema.org); our choice is schema.org it is simple, can be indexed by search engines; we chose our particular CRSfor compatibility
Thank you and speak tomorrow!
<AndreaPerego> Have a nice evening! Meet you (virtually) tomorrow.
<RaulGarciaCastro> Bye!
<AndreaPerego> Just realised this action was not added to the tracker (nickname "ahaller2_" not in the tracker):
<AndreaPerego> ACTION: ahaller2 to update issue with jtandy 's text [recorded in http://www.w3.org/2016/12/15-sdw-minutes.html#action08]
<trackbot> Created ACTION-236 - Update issue with jtandy 's text [on Armin Haller - due 2016-12-22].