- From: Phil Archer <phila@w3.org>
- Date: Tue, 9 Feb 2016 14:56:36 +0000
- To: SDW WG Public List <public-sdw-wg@w3.org>
Minutes from today's F2F meeting are, of course, at
https://www.w3.org/2016/02/09-sdw-minutes.
The text version is pasted below.
Thank you Linda, thank you Geonovum, for hosting us.
Thank you Kerry for staying the course to 02:00!
Spatial Data on the Web Working Group Teleconference
09 Feb 2016
[2]Agenda
[2] https://www.w3.org/2015/spatial/wiki/Agenda_F2F3
See also: [3]IRC log
[3] http://www.w3.org/2016/02/09-sdw-irc
Attendees
Present
ahaller2, eparsons, kerry, BartvanLeeuwen, Lina, Linda,
AndreaPerego, phila, frans, DanhLePhuoc, jtandy, aharth,
LarsG, billroberts, ChrisLittle, rachel, jonblower,
ClausStadler
Regrets
Chair
eparsons
Scribe
BartvanLeeuwen, billroberts, Linda, phila, aharth
Contents
* [4]Topics
1. [5]SSN stuff
2. [6]SSN
3. [7]Collaborative tool
4. [8]assigning tasks
5. [9]Coverages
* [10]Summary of Action Items
* [11]Summary of Resolutions
__________________________________________________________
<eparsons> [12]https://www.w3.org/2015/spatial/wiki/Agenda_F2F3
[12] https://www.w3.org/2015/spatial/wiki/Agenda_F2F3
<kerry> scribe: BartvanLeeuwen
<kerry> scribeNick BartvanLeeuwen
<kerry> scribeNick: BartvanLeeuwen
<phila> agenda:
[13]https://www.w3.org/2015/spatial/wiki/Agenda_F2F3
[13] https://www.w3.org/2015/spatial/wiki/Agenda_F2F3
<phila> chair; Ed
<phila> chair: Ed
SSN stuff
SSN
<kerry>
[14]https://www.w3.org/2015/spatial/wiki/SSN_Tasks#Modularisati
on_topic
[14]
https://www.w3.org/2015/spatial/wiki/SSN_Tasks#Modularisation_topic
kerry: 1st thing, modularisation
... this is the most indemand thing, we had a discussion about
this already
... can we do our FPWD about this
... the task of modularizing SSN is a significant thing to do,
to get feedback
jtandy: I agree, that breaking it up in small chunks is making
the vocabulary easier to use.
ahaller: will DULC be a module
kerry: it will be external, a vocabulary which imports SSN and
DULC
ahaller2: shouldn't we just have one vocabuarly, and a
lightweight IOT deliverable
kerry: I don't have big objection that, but probably a lot of
other have
... others might argue that SSN including DOLCE is too
difficult
frans: I wonder what the modularization is about, it seem to
split it in several files
<ChrisLittle> preseent+ ChrisLittle
frans: how does that influence usability, it could be a barrier
to have different namespaces for different properties
kerry: I'm inclined to agree with you
frans: which problem is being solved by modularization?
<ahaller2> agree too, too many modules may prevent usage
DanhLePhuoc: do we do modularization on base of previous work
on SSN, or on newly chartered requirements
kerry: if we don't want to split SSN and take out DOLCE, I
don't have a problem with that, we do have new requirements
which we could do a new vocabulary
... I've put something on the list which is something like a
'profile' which a reasoner could put back together
... on of the other calls is about lightweight IOT vocabulary
... I'd like to relate that to SSN
... I'm not pushing the idea we need to split up SSN
<Zakim> jtandy, you wanted to ask how / if modularisation will
help _users_ of the vocabulary? other than providing it in
smaller conceptual chunks
jtandy: I'm thinking why I said modularization is a good thing,
what are the key benefits of modularization here? Is this going
to work with OWL ontology
... are we making it easier for users, or does it introduce
problems with multiple namespaces
... is it easier to maintain. Key question what is it what we
want to achieve ?
DanhLePhuoc: I have some answer why we might need to split up,
if you have small devices we need to have a option to build a
small device we need to be able to load a subset of the
ontology on the reasoner.
... it is also a strong requirement in wht WOT group, how can
we do processing on the micro controler
<jtandy> [wow - I hadn't realised that @DanhLePhuoc & others
was intending to load reasoners onto embedded devices!]
frans: I wonder how the usage of ontologies on the devices will
work, if I have a array of devices do I just implement SSN, or
do I subset it.
<Zakim> phila, you wanted to talk about SHACL and IoT Lite
phila: in a seperate domain I keep comming up into application
profiles, which puts wonderfull ideas of ontologies in
something practical one can use.
... what is in my head, SSN is being put forward as a REC,
including modularization you talked about, parallel to that we
publish a NOTE which is already written, IOT-Light a member
submission
... it fits in this group, and the internet of things interest
group
... if the group agrees we could jointly review this submission
and publish this jointly
... we could also publish a machine readable SHACL which
represent the profile
<jtandy> [SHACL: [15]https://www.w3.org/TR/shacl/]
[15] https://www.w3.org/TR/shacl/]
eparsons: with you proposal, is there any sequencing needed ?
phila: no, NOTEs are not normative
... if we do decide to do this, we have no idea what that means
to the OGC/W3C publising scheme
eparsons: its a different domain in OGC
phila: its interesting to see how this needs to be processed
<jtandy> [a good job that Scott S is our rep from OGC :-) ]
kerry: steve liang, the sensors things person, did show up on
our meetings.
<phila> [16]SHACL
[16] https://www.w3.org/TR/shacl
<phila> [17]IoT Lite Ontology
[17] https://www.w3.org/Submission/2015/SUBM-iot-lite-20151126
kerry: I posted on the list how to create a extraction of SSN
DanhLePhuoc: regarding the joined forced the WOT I talked to
people in WOT IG about the joined work
... we have large project with 13 partners about IOT , we have
a strong will for standarisation
... it is a good idea to have joined force, the WOT will go for
a working group bringing a lot of industry.
<ahaller2> +1 to collaborate with WOT on the Lite ontology
eparsons: is this working group thinking about publishing SSN
and do a IOT light note, or still do modularization of SSN
kerry: I'm happy with the plan phila put forward, a profile of
SSN sounds like a smart thing to do, not sure how SHACL fits in
aharth: I think modularization has a couple of benefits, it
keeps modeling small, lowering the learning curve
<frans> I can see how modularization helps the ontology
developers. If users only use profiles the modularization won't
bother them
aharth: it allows to reuse certain parts of existing
vocabularies, e.g. coverage of SDW, units vocab by NASA or
Data-Cube
<Zakim> phila, you wanted to separate SHACL and profile issues
aharth: this could be the benifit of reuse instead of inventing
your own.
<kerry> +q
<kerry> SHACL uses RDF and RDFS vocabulary (in particular
rdf:type, rdfs:Class, rdfs:subClassOf, rdf:Property, rdf:List,
rdf:langLiteral, and rdfs:Resource) and notions (notably
classes, instances, and subclasses). However, SHACL does not
always use this vocabulary or these notions in exactly the way
that they are formally defined in RDF and RDFS [rdf11-mt].
phila: a Profile is a document describing the profile, doesn't
have to contain SHACL
kerry: I don't like what I see from the beginning of the SHACL
spec
<ahaller2> kerry point to the github
<kerry>
[18]https://lists.w3.org/Archives/Public/public-ssn-cg/2012Jun/
0000.html
[18]
https://lists.w3.org/Archives/Public/public-ssn-cg/2012Jun/0000.html
kerry: the charter mentions modularisation in particular
<ahaller2>
[19]https://github.com/AGLDWG/TR/blob/master/ontology
[19] https://github.com/AGLDWG/TR/blob/master/ontology
kerry: I did a sketch of what is written in the email
<kerry>
[20]https://www.w3.org/2015/spatial/wiki/SSN_Tasks#Modularisati
on_topic
[20]
https://www.w3.org/2015/spatial/wiki/SSN_Tasks#Modularisation_topic
kerry: yellow arrows are imports
... The design pattern on the top is about how sensors work,
but not really usefull
... it imports DOLCE on the right
... the left imports the sensor descriptions
<jtandy> [BTW: @kerry is describing this picture:
[21]https://www.w3.org/2015/spatial/wiki/File:Ssn_modular.png]
[21] https://www.w3.org/2015/spatial/wiki/File:Ssn_modular.png]
kerry: SSN has problems without DOLCE, I started with modules,
but needed DOLCE in the end
<kerry>
[22]https://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628/imag
es/OntStructure-Overview.jpg
[22]
https://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628/images/OntStructure-Overview.jpg
<Zakim> jtandy, you wanted to ask about O&M and sampling
features
jtandy: <wrongtime> one of the things we wanted to do is to
bind in observations/ measurements from the OGC in SSN, do we
need to mention that in the FPWD </wrongtime>
... does modularisation allow blending in
observations/measurments form OGC
kerry: I think this would blend in via import with
modularization
... there are allignment issues
jtandy: Simon recently published something on
observations-light and measurements-light
Linda: without knowing the details, I did see some work on
using a profile instead of DOLCE
<jtandy> [Simon = Simon Cox]
Linda: without knowing the details, I did see some work on
using a PROV-O instead of DOLCE
<Linda>
[23]http://www.slideshare.net/drshorthair/ontology-alignment-is
-provo-good-enough
[23]
http://www.slideshare.net/drshorthair/ontology-alignment-is-provo-good-enough
kerry: a SSN alignment with PROV-O is publised a while ago
... I don't see where DOLCE and PROV-O are alternatives
ahaller2: from the original SSN the modularization is imho a
bit to fine grained
... I think if we modularize DOLCE so that we can load it
seperatly
<kerry> [24]http://ceur-ws.org/Vol-1401/paper-05.pdf
[24] http://ceur-ws.org/Vol-1401/paper-05.pdf
kerry: I'm inclined to agree
... the number of namespace you need to remember is large, the
cost of the modularization is high
<ahaller2> ahaller2: we may want to consider modules for O&M
and Actuators, though, i.e. the new stuff we want to add
eparsons: the argument for modularization is about replacing
certain parts which might not be of your liking
frans: modularization is about being able to replace parts
kerry: I disagree, there is universal agreement that DOLCE
should not be tied to much to SSN as it is now
... so pull out DOLCE
... there is potential use of including others e.g. PROV-O and
Data-Cube
<aharth> qudt has units and measurements:
[25]http://www.qudt.org/
[25] http://www.qudt.org/
kerry: other then DOLCE there is nothing we should take away
<ahaller2> +1 to modularise DOLCE out
DanhLePhuoc: I could agree with kerry that multiple namespaces
is a terrible idea to work with sensors
... just splitting the SSN in smaller pieces is not something
wel should do
ahaller2: in terms on the namespaces we could use slashes in
stead of hash so the main part of the namespace stays the same
<frans> If users only use a profile they only have a single
namespace, don't they?
<aharth> @prefix ssn: <[26]http://ssn.example.org/schema/> .
[26] http://ssn.example.org/schema/
<aharth> and then multiple files:
[27]http://ssn.example.org/schema/dolce.rdf,
[28]http://ssn.example.org/schema/core.rdf and
[27] http://ssn.example.org/schema/dolce.rdf,
[28] http://ssn.example.org/schema/core.rdf
<aharth> so on
<DanhLePhuoc> +1 for associate namespace with a profile
ahaller2: this will not solve that DOLCE is part of SSN so it
needs to be imported anyway
<kerry> propose: for modularisation we work with michael's
proposal (but remove dul and replace with native appropriately)
and serve it using /uris and redirects as sugested by Armin
<phila> PROPOSED: for modularisation we work with michael's
proposal (but remove dul and replace with native appropriately)
and serve it using /uris and redirects as suggested by Armin
<eparsons> +1
<aharth> +1
+1
<AndreaPerego> +!
<AndreaPerego> +1
<ahaller2> +1
<jtandy> +1 ... seems fair, I'm no expert tho
<kerry> +1
<DanhLePhuoc> +1
<Linda> +1
RESOLUTION: for modularisation we work with michael's proposal
(but remove dul and replace with native appropriately) and
serve it using /uris and redirects as suggested by Armin
<LarsG> +1
ahaller2: on which infrastructure do we do that?
phila: that was my question, it can be done on w3/NS space
<phila> ==PAUSE==
<ChrisLittle> Thanks for scribe Bart
<eparsons> Scribe : billroberts
kerry: are there any other serious proposals on the table
kerry thanks Bart for rotating her picture
no proposals in the meeting room for other SSN modularisation
approaches
next on agenda is: Armin's proposal for collaborative editing
<kerry> [29]https://www.w3.org/2015/spatial/wiki/SSN_Tasks
[29] https://www.w3.org/2015/spatial/wiki/SSN_Tasks
ahaller2: has reviewed predictability of tool behaviour when
working with ontologies and how that might work with Github
... with imported ontologies, Protege is unpredictable in terms
of serialisation, which would cause problems if storing the
output in Github
Collaborative tool
ahaller2: web-protege looks promising as it has the main
features that people will want
... there is a widget where you can type in axioms directly
... Vocol requires typing turtle, so Armin would prefer
Webprotege
... TopBraid has predictable serialisation so would work well
with Github
... Webprotege has advantages for collaborative working as it
is software as a service
kerry: if you use this editing approach (line based editing in
Webprotege), do you lose the Protege advantages of keeping you
in OWL-DL
ahaller2: it claims full OWL2 support but documentation is
sparse so would need to check
<Zakim> jtandy, you wanted to ask if web protege =
[30]http://webprotege.stanford.edu ... is there a better link?
[30] http://webprotege.stanford.edu/
jtandy: is the above link the correct one?
ahaller2: that is the correct link
<jtandy> billroberts: how far are you planning to go with the
OWLy parts (axioms) in addition to the classes and properties?
<jtandy> ... for just classes and properties I use a text
editor- but this doesn't scale to big ontologies
kerry: the ontology already contains things beyond simple
classes and properties, for example role compositions and
multiple inheritance
so it's already complex enough that tool support is likely to
be needed
kerry: will Webprotege be sufficient to support those features?
ahaller2, DanhLePhuoc - discussion of whether RDFS is
useful/appropriate - easy and efficient though limited
capabilities. Is it enough?
kerry: good idea, is it possible to add an RDFS view of the
ontology? could be another module, similar to IoT-Lite
ahaller2: "SSN-Lite" might be effectively another module
kerry: don't want to take existing things out of SSN, because
it might be already in use by the user base
DanhLePhuoc: we'll need to consider complexity of processing
kerry: bringing discussion back to the question of
collaborative tools
... only feasible choice appears to be Webprotege
ahaller2: alternative: just put it on Github and people can use
their own choice of tools, as long as they check the
serialisation
kerry: would be easy to break the ontology, using that appraoch
... does Webprotege support versioning?
ahaller2: not sure of details, would need to investigate
kerry: could we use Github diff to determine changes?
<Zakim> jtandy, you wanted to ask @phila what his other teams
do?
ahaller2: webprotege manages changes internally, but we can't
use git with it
jtandy: what are other working groups using for developing
vocabs?
<frans> a canonical serialization was mentioned once?
phila: there has been much discussion of this. No standard tool
is available at W3C
... DWBP - ontology developed as a diagram and phila manually
created the Turtle
... in most other groups it has not been collaborative.
Collaboration makes it hard
... wishes there was a better tool available
ChrisLittle: wikipedia notes 200,000 users for Protege "highly
recommended, most used ontology tool"
... sounds a good reason for choosing Protege
jtandy: challenge is collaboration versus desktop tool
kerry: so only choice appears to be WebProtege
... there was a question on serialisation tools. Using those is
difficult
... vote needed?
eparsons: no
<ahaller2> i have already created a project on webprotege
<ahaller2>
[31]http://webprotege.stanford.edu/#Edit:projectId=dc983c6a-c14
4-4d5a-a2a2-1f8d25d1ad54
[31]
http://webprotege.stanford.edu/#Edit:projectId=dc983c6a-c144-4d5a-a2a2-1f8d25d1ad54
Decision made: use Webprotege
RESOLUTION: The SSN editors will use Web Protege as the
collaborative editing tool
discussion of access to the collaborative tool
kerry: ok for people to see work in progress, just want to
control editing rights
assigning tasks
anyone have a link to the task list?
kerry: reviews task list
<Linda> [32]https://www.w3.org/2015/spatial/wiki/SSN_Tasks
[32] https://www.w3.org/2015/spatial/wiki/SSN_Tasks
kerry: volunteers?
<DanhLePhuoc> I can do 3.
<phila> DanhLePhuoc++
ahaller2 will do 1.1 on WebProtege
kerry will do 1.2
<phila> ahaller2++
<ahaller2> ahaller2 helps with 1.2 too
DanhLePhuoc volunteers for 1.3, to be reviewed by kerry
<phila> ACTION: DanhLePhuoc to Reconsider O&M alignment (see
O&Mlite) - as alternative to DUL [recorded in
[33]http://www.w3.org/2016/02/09-sdw-minutes.html#action01]
[33] http://www.w3.org/2016/02/09-sdw-minutes.html#action01]
<trackbot> Error finding 'DanhLePhuoc'. You can review and
register nicknames at
<[34]http://www.w3.org/2015/spatial/track/users>.
[34] http://www.w3.org/2015/spatial/track/users
<phila> ACTION: Phuoc to Reconsider O&M alignment (see O&Mlite)
- as alternative to DUL [recorded in
[35]http://www.w3.org/2016/02/09-sdw-minutes.html#action02]
[35] http://www.w3.org/2016/02/09-sdw-minutes.html#action02]
<trackbot> Error finding 'Phuoc'. You can review and register
nicknames at <[36]http://www.w3.org/2015/spatial/track/users>.
[36] http://www.w3.org/2015/spatial/track/users
<phila> ACTION: Danh to Reconsider O&M alignment (see O&Mlite)
- as alternative to DUL [recorded in
[37]http://www.w3.org/2016/02/09-sdw-minutes.html#action03]
[37] http://www.w3.org/2016/02/09-sdw-minutes.html#action03]
<trackbot> Created ACTION-139 - Reconsider o&m alignment (see
o&mlite) - as alternative to dul [on Danh Le Phuoc - due
2016-02-16].
<phila> ACTION: Haller to clearly separate observation, sensor,
and deployment parts of SSN [recorded in
[38]http://www.w3.org/2016/02/09-sdw-minutes.html#action04]
[38] http://www.w3.org/2016/02/09-sdw-minutes.html#action04]
<trackbot> Created ACTION-140 - Clearly separate observation,
sensor, and deployment parts of ssn [on Armin Haller - due
2016-02-16].
<phila> ACTION: kerry to disentangle SSN from DUL (this may
require adding things to SSN that are needed from DUL)
[recorded in
[39]http://www.w3.org/2016/02/09-sdw-minutes.html#action05]
[39] http://www.w3.org/2016/02/09-sdw-minutes.html#action05]
<trackbot> Created ACTION-141 - Disentangle ssn from dul (this
may require adding things to ssn that are needed from dul) [on
Kerry Taylor - due 2016-02-16].
kerry: leave task 2 (align with Prov-O) until the previous
tasks have been completed as there is a dependency
... ACTION-140 has already been done?
<phila> action-140?
<trackbot> action-140 -- Armin Haller to Clearly separate
observation, sensor, and deployment parts of ssn -- due
2016-02-16 -- OPEN
<trackbot> [40]http://www.w3.org/2015/spatial/track/actions/140
[40] http://www.w3.org/2015/spatial/track/actions/140
ahaller2: Michael's modularisation is too fine grained, so it
does need further thinking
... will create a WebProtege file that separates DOLCE and SSN
... is happy with action 140
kerry: that's enough for now.
DanhLePhuoc will review previous work for aligning RDF Data
Cube with SSN.
DanhLePhuoc: requires first draft of modularisation
<eparsons> action Danh will review previous work for aligning
RDF Data Cube with SSN
<trackbot> Created ACTION-142 - Will review previous work for
aligning rdf data cube with ssn [on Danh Le Phuoc - due
2016-02-16].
eparsons: that's the end of items scheduled for this morning
kerry: we've set up initial actions around modularisation and
removal of DUL, perhaps incorporating data cube context into
SSN in a better way. Do you think that is enough for a first
public working draft? or do we also need to address use cases,
wishlist, O&M etc
phila: is that enough for someone outside to read the document
and understand what you are doing and make suggestions
... enough to show people the direction you are heading in,
then it's enough for a first public working draft
kerry: thinks that would be about 2 months away. Would that be
ok?
sorry!
typo
eparsons: soon would be good
kerry: plan for FPWD is 9 April
RESOLUTION: Target date for FPWD of SSN is 9 April (ish)
eparson: thanks kerry. End of SSN discussion
eparsons: there is an hour of discussion time available.
topics?
BartvanLeeuwen: question on terminology. Use of 'GIS' and 'SDI'
eparsons: thinks of GIS as the tool to manage spatial content
<jtandy> see definitions in BP doc:
[41]http://w3c.github.io/sdw/bp/
[41] http://w3c.github.io/sdw/bp/
eparsons: once you have lots of data you want to publish,
that's when you move to SDI
<jtandy> GIS: Geographic information system or geographical
information system, a system designed to capture, store,
manipulate, analyze, manage, and present all types of spatial
or geographical data. (ref. Geographic information system)
<jtandy> SDI: Spatial Data Infrastructure, a data
infrastructure implementing a framework of geographic data,
metadata, users and tools that are interactively connected in
order to use spatial data in an efficient and flexible way.
(ref. Spatial Data Infrastructure (SDI))
eparsons: so expected that SDI is discussed much more than GIS
in SDWWG context
ChristLittle: desire to expose the details of the data on the
web. How do you get 'inside' the GIS in a web context
eparsons: make distinction bewteen private internal view and a
public external view - maybe a subset, maybe with extra
metadata
jtandy: we have definitions in the BP glossary. Maybe they
could be improved, but we have them (see Appendix D)
BartvanLeeuwen: reason would be to help people who think of
themselves as GIS experts to understand what in the BP is
relevant for them
eparsons: sharing my GIS with someone else might be a new use
case
BartvanLeeuwen: might just want to share a shapefile with
someone. Don't really want to set up a full SDI for that
frans: maybe SDWWG will offer a simpler alternative to sharing
shapefiles for exchanging this kind of info
<Zakim> kerry, you wanted to talk about glossary
eparsons: shuold describe simple sharing of info in our
narrative
kerry: early on we had a partial glossary, some of it copied
from Point of Interest working group, and ISO documents
... consistency of BP glossary with that other list?
would be good to be consistent across deliverables
<kerry>
[42]https://www.w3.org/2015/spatial/wiki/Glossary_of_terms
[42] https://www.w3.org/2015/spatial/wiki/Glossary_of_terms
kerry: eg we have more than on definition of coverage
<frans> I like the idea of having a shared glossary. I think it
is needed to reach different audiences
eparsons: agrees. Action on editor of every document to ensure
consistency
jtandy: Github issue 212 to address this for BP
<jtandy> see [43]https://github.com/w3c/sdw/issues/212
[43] https://github.com/w3c/sdw/issues/212
frans: there is an online glossary and we could link to those
definitions
... could turn simple words into links to the glossary
eparsons: it's a working document,not a separate deliverable
frans: should be a public glossary
eparsons: yes useful, but not required by the charter
jtandy: respec has some automatic tools to link to glossary
within the same document
frans: replicate a shared glossary to each document?
jtandy: but you might get lots of terms not relevant for that
document
<Linda> scribe: Linda
wiki page can be internal glossary which could be partially
duplicated to different documents
<jtandy> scribenick: Linda
kerry: the docs should each have their own glossary internally,
and against having glossary as separate deliverable. But we
need to be consistent.
The wiki glossary should help with that.
scribe: definition clashes should be addressed when needed by
editors
ed: agrees
eparsons: agrees and good point brought up by BartvanLeeuwen
frans: is this a new action for the UCR editors?
... it has no glossary section now
eparsons: it's up to you to have one or not
<Zakim> jtandy, you wanted to suggest looking at public
comments
jtandy: let's take a look at the public comments of the SDW BP
first draft
<jtandy>
[44]https://lists.w3.org/Archives/Public/public-sdw-comments/20
16Feb/0021.html
[44]
https://lists.w3.org/Archives/Public/public-sdw-comments/2016Feb/0021.html
jtandy: Rob Atkinson had a comment that needs some unpicking
... it's about the structure of the doc which is lacking (just
a long list of BPs)
<jtandy>
[45]https://lists.w3.org/Archives/Public/public-sdw-comments/20
16Feb/0019.html
[45]
https://lists.w3.org/Archives/Public/public-sdw-comments/2016Feb/0019.html
jtandy: another one is from a 'Bergi' do we know him?
BartvanLeeuwen: I encouraged him
jtandy: we could also look at his comments
eparsons: lets look at Robs comment first
... agrees with structure comment
... how much will introducing narrative around emergency
response help in solving this?
BartvanLeeuwen: agrees that structure is currently missing
... has funding to work on emergency response narrative
jtandy: currently the BPs are grouped by theme, but it's not an
easy road in
... the first BP will probably remain first
... agree that more structure is needed
... a pathway into the doc is needed for different user groups
... have the BPs in order of sequence of steps to take
... the data on the web BP people have tried to use a common
theme for their examples as well
... we could use the emergency response theme in example
snippets in the BPs, and have a longer narrative of the ER
theme in an appendix.
eparsons: makes sense
jtandy: maybe have two main sections:
... one for web content people, one for data publishers.
eparsons: one group is actors who already have GIS systems and
another group is people who use data on the web. Both involved
in the same scenarios.
... but coming from different directions.
frans: I think their are more audiences than two.
... the BP could be seen as a data cube. Different user groups
need different information from the doc.
... a narrative requires reading the doc from top to bottom. We
should allow people to pick the information they need out of it
without doing that.
... so self contained sections / modules needed
... not too many links from sections to other sections.
eparsons: raises a fundamental point: the narrative could be a
completely separate doc.
... the BP itself is then more a reference doc.
... the narrative would point to the BP relevant sections
... maybe we could use the event tomorrow where we have 'normal
people' to ask them what would be the best way in for them.
jtandy: this is certainly one of the questions to ask them
BartvanLeeuwen: the DW BP now asks a lot from the reader.
... not sure if suggestions so far help readers
jtandy: Rob's suggestion is to add a section that explains the
document is not prescribing one way of doing things. We should
do this.
eparsons: but there's a balance, we're also helping people pick
the right approach, not just providing a menu.
... to be useful we do need to make recommendations
jtandy: Rob gives four different options which are too detailed
to unpick here.
eparsons: they are fair comments and not surprising to us
jtandy: working through the ER narrative might help us
illustrate in our own minds how it will actually work. This
will help us describe it.
... Geonovum testbed results will hopefully help us.
action jtandy to respond to Rob Atkinson's comments
<trackbot> Created ACTION-143 - Respond to rob atkinson's
comments [on Jeremy Tandy - due 2016-02-16].
BartvanLeeuwen: let's talk about Bergi's comments
GeoJSON and JSON-LD conflict in the way they are constructed.
BartvanLeeuwen: has been discussed a lot, conclusion is it
cannot be solved
... if you add LD to GeoJSON it will not work in current
toolkits
... is unlikely to be supported.
... should we take this problem on?
frans: let's say there is a single spatial ontology with a
geometry datatype:
... then this will not be a problem anymore.
BartvanLeeuwen: but still the problem of tool support
frans: a common datatype like WKT would help
aharth: what they did was extend geosparql ontology with their
own property.
... they didn't want to use WKT but their own format they had
already.
... this is a repeating thing, everyone wants to use their own
format and keep doing that.
frans: that's a problem we need to solve because otherwise we
don't have interoperability.
aharth: but that will not fly with these guys.
<Zakim> AndreaPerego, you wanted to mention Simon's comment on
geometry encoding in GeoJSON
frans: we should compare different solutions
AndreaPerego: simon Cox had a good comment on the mailing list
about in GeoJSOn using JSON arrays for this is sensible.
BartvanLeeuwen: but the problem with the array is if you
serialise this back it is screwed up
LarsG: if we standardise one format would this prevent others
from doing their own thing anyway?
frans: in the relational DB world it worked
eparsons: is it really an interoperability issue on the level
we're talking about?
... aren't we more concerned about interoperability on the
Thing level instead of the encoding?
BartvanLeeuwen: i suggested to Berni et al to separate the geo
part and LD part on the web, but they want the whole package
LarsG: so Bart is saying use content negotiation and choose an
encoding depending on which format is requested.
... but this asks more of the publisher
frans: geometry should be considered a data type that should be
used the same in any format
LarsG: is anyone in close contact with geojson community?
eparsons: nobody really
... they are busy at IETF
phila: we had contact with them before Sapporo
... we could ask eg if they are ok with WKT
LarsG: that would solve our problem what to write in the BP
billroberts: they would probably not want that
frans: we need to look at the pros and cons of having coords in
one string or in an array
... the advantage of one datatype is you don't need any
conversion
aharth: they want to use javascript to draw coordinates on a
map
... wkt will be more difficult for them to parse
frans: it would need only a small library.
billroberts: they want to use it natively, not using a library
jtandy: in rdf it is not useful to separate geometry into
triples. Literal is good
... having coordinates in literal is a recommendation. Not
saying it should be wkt especially.
... seems like there is a common ground: treat it as a literal
object, not as a nested array
frans: a datatype is more durable, json might go away and be
replaced
billroberts: having big rdf literals is a pain in practice.
... having a triple refering to a separate web resource would
be good
... maybe geosparql extension needed to still be able to do
spatial things with the geometries
<Zakim> phila, you wanted to ask about NeoGeo treatment of
literals
billroberts: but the serialization doesn't matter that much
phila: neogeo doesn't put the geometry into one literal, what's
your experience?
aharth: a good way of doing it.
... if it's not one big file, but links to geometries outside,
this makes file sharing more difficult.
eparsons: break for lunch
... back at 13:00 CET, 1 hour from now.
<phila> ==LUNCH==
<phila_> scribe: phila
<phila_> eparsons: Recommences the meeting
<phila_> ... We need to talk about coverages etc. this
afternoon
Coverages
<phila_> eparsons: It's the thing we've done least development
on, but I think we're ready to make a start.
<phila_> billrobe_: I asked for it to be on the agenda to
discuss what we're going to do and how.
<phila_> ... I agreed to be one of the editors
<phila_> billrobe_: My background is in the LD work, but less
so in coverages - I'm going to need help from the WG
<phila_> jon: What is the scope?
<phila_> billrobe_: Quotes the charter
<phila_> ... mentions Data Cube, WaterML
<phila_> ... subsetting
<phila_> ChrisLittle: WaterMl recognises that the coverage is
in time, not space
<phila_> billrobe_: So what worries me is, to what extent will
that ISO standard constrain things
<Zakim> AndreaPerego, you wanted to say that RDF rep may be
useful for some specific cases (e.g., centroids, bboxes)
<phila_> jtandy: When I wrote that paragraph in the charter,
compliant with 19123, it was so you could figure out how your
data maps to 19123, not conformant to it.
<phila_> ... We know about domains and ranges... the intention
was never a formal line by line compliance.
<phila_> jtandy: This could be a Rec track doc. It says in the
charter we're going to do this. We could decide that a mapping
to 19123 could be the weay to do it.
<Zakim> kerry, you wanted to ask if sound can be improved?
<phila_> kerry: I can't follow what's going on...
<phila_> ... It was better this morning
billrobe_: So the other thing I'd welcome explanation on, what
does it mean that it will be a formal Recommendation?
jtandy: Rec Track
billrobe_: Does that say anything about the style or content of
the doc?
jtandy: It has an implication on the process you need to work
through.
... Particularly you need to be able to refer to 2 independent
implementations of all its features.
frans: In the UCR, a note was added to the description of the
coverages deliverable, about new work in OGC being relevant.
jtandy: So that refers to Peter Baumann's 'CIS' which has been
approved as a work item in the ISO process, which is hte
beginning of the road, not the end.
... An implementation schema is more detailed than a conceptual
schema.
... CIS will eventually be 19123 Part 2
billrobe_: So if there is existing work on this it makes sense
to reuse.
jonblower: So if a Rec has to be implementable, what if wanted
to weaken that and say intelligent things about related things.
Do we have to come up with an implementable thing?
jtandy: We have the ability to publish more or less what we
like as a Note.
... The BP doc is a Note. SSN Vocab will be a Rec.
... As will Time
... How you prove that you have 2 implementations of a vocab is
that the terms are used more than once.
... If we get to the point where we don't want to make a Rec
then we can decide as a group to do that.
jonblower: I think doing something implementable could open a
can of worms and involve a lot of people.
... I'm happy to put forward what we've done in MELODIES, but
it's early days and not BP at this stage.
... I might be comfortable talking about the issues, like when
would you use Data Cube? When would you use JSON, when is OGC's
CIS right etc.
kerry: I don't understand why we wouldn't do a Rec Track. I see
this as an ontology for combining EO data with he data Cube
... I can find some old work that pre-dates the data Cube
... Implementation evidence is just that all terms have been
used
... All being well, I'll have a student project soon with 6-7
students implementing what we're talking about here. For them
to benefit most, implementing it in the Australian GeoScience
model would be good.
... I'd be interested in that, provided others are too.
billrobe_: The other thing that I wanted to raise ... who do we
think it's for? We have our overall remit, but within that,
it's about levels of sophistication.
... Is it aimed at people who do this all day every day?
Non-specialists?
eparsons: I think that's fundamental and will guide us in our
scope.
<kerry> if we are not aiming at the "nonspecialists' we have
nothing to do
jtandy: When I wrote the bit in the charter was - there are
already infrastructures for handling big binary files, we're
not going to help them
... And there's the LD community.
... What we need to do is to be able to use some array-based
data and apply it to areas.
... My intention was app developers who want to use LOD and
coverage data in a single application. That's what I was aiming
for.
... It's hard to do at the moment.
<kerry> +1
eparsons: Are people interested in both?
jtandy: The MELODIES project recognises 8 application areas
where they're linking EO data with LOD. So 8 different areas
where we can say that the problem exists.
jonblower: Yep.
<eparsons> Steps out for 30 minutes
frans: Coverage is a concept from the OGC. It's a broad
concept, time series, point clouds...
... Is it useful to apply that on the Web?
... I can image that there are several ways of modelling a time
series that don't need to bother with a coverage.
... Do we want to say to the Web that it shoujld accept the
concept of a Coverage?
<kerry> chair: kerry
jonblower: As well as following on from Jeremy - I think Frans
makes a good point.
... There's a use case extraction job here. There's addressing,
accessing, annotating coverages
... That might point us to a range of solutions.
... We might want to think about a specialisation of that.
... What sort of thing do people actually want to do.
<Zakim> kerry, you wanted to answer frans question
phila: Highlights the CEO-LD project and its aims
kerry: I was looking at the use cases. I got the response that
people want the EO data to be more visible and more
interlinked.
... The same techniques should be available to everyone.
... Making the data available to Web develeopers is a good
thing. As is making liefe easier for specialists.
... We had that conversation about how complicated coverages
data is in Barcelona. I'm not sure that we made a decision in
that meeting.
... For me it's clear that we should talk about data that is
mappable to Data Cube.
... We talked this morning about using Data Cube with SSN. is
the data Cube too much for time series data?
... Does it work for EO? Yes.
... So I would reduce it just to data Cube.
jonblower: To relate this to the work with the CEO-LD group -
is focussing on satellite imagery. The coverage world is wider
than that.
... Time series, numerical models, etc.
billrobe_: Next question - the schedule. I see we're due an
FPWD by last September so we're starting 5.5 months behind
schedule
... with a target end dat of end of 2016
<kerry> +1 to frans comment
frans: I wanted to say something about the previous subject. I
get the impression that a lot of the UCs are about EO data. OGC
covers more. Maybe we start wieth the EO data?
... That might help reduce the complexity?
... I can also think of use cases that are not in the OGC
definition. The microscopy slides UC for example. That gives
you raster data that may not fit the OGC defn.
... So we *could* just think about the raster data, and that
might be what people ar elooking for? Somrthing to consider.
<Zakim> jtandy, you wanted to make a comment that datacube was
illustrative
jtandy: Whilst it's attractive to focus on raster data in the
EO community, it woujld miss out time series, numberical models
etc.
... Maybe in our work we can set a boundary of the topologies
to look at.
... Data Cube was mentioned as an illustrative way of saying
how a coverage could be encoded. There's some commonality, not
that we need to end up with a recommendation that says we must
use Data Cube.
<Zakim> billrobe_, you wanted to talk about data cube
<frans> Does the data cube vocabulary suffice for time series?
jonblower: On Kerry's point. I think it woujld be good to have
a look at Data Cube and see how it applies. But I don't think
we should restrict ourselves to one model A coverages model
includes all use cases. All coverages havea the same kind of
properites and attributes, so I don't see how we would do
something that only applied to EO data.
<jtandy> +1 from me ... not restrict ourselves to RDF DataCube
model
jonblower: Great of Kerry has students to look at it
ChrisLittle: The microscopic slides are a coverage and they are
covered by the 19123 model.
... The Data Cube issue - you might get 2 data cubes you might
have one with geospatial coordinates defined as dimensions and
on where they're not.
<billrobe_> I agree with what Jon and others have said on data
cube
kerry: Understandint that coverage is much broader in an OGC
sense... but we have the Data Cube available to most of us, and
it can handle time series
... My suggestion is to limit oursleves to coverages that can
sensibly be encoded in the Data Cube.
jtandy: Which data cube do you mean?
kerry: the RDF Data Cube (not the geosci Aus one)
<rachel> s/Understandint aht/Understanding that/
<jtandy> [I included the 'timeseries' coverage in the charter
statement specifically so we didn't focus only on EO satellite
/ raster data]
jonblower: Kerry, you added a word in your last sentence that
changed my view: 'sensibly.'
... So you mean relatively low volume ones, cf. 10^3 x 10^3
pixel images
kerry: It was more the mapping of the data model, where it fits
the cube model that i was after.
jonblower: So you're talking about coverages with orthogonal
axes, rather than triangular reference systems.
<ChrisLittle> +1 to john's comment
jonblower: Right, OK, now I understand.
billrobe_: I like Data Cube - I do a lot of it for statistics,
but I think it would be very restrictive to only look at things
that only worked in data Cube.
... The good thing is its flexibility, the bad thing is its
verbosity.
<frans> I agree with Bill.
<jtandy> +1 to billrobe_ ... look at datacube from evaluative
perspective
billrobe_: I wouldn't want to exclude otehr things at this
stage.
<Zakim> jtandy, you wanted to note that the datacube might
still work for describing the coverage metadata
<jonblower> I also agree with Bill
jtandy: Even if you have 10^6 points, the Data Cube might have
been a useful way to describe the coverage.
... My thought was that it might be good for the metadata,
maybe not the payload.
... I agree with Bill that we should start with the solution.
ChrisLittle: Can I come back on the comment about ruling out
point clouds. They are amenable to being represented in a data
Cube... I'd vote to have point clouds in.
<jtandy> we should draw the line of coverages to exclude those
with triangular mesh networks ... and point clouds - such as
lidar for example
jonblower: My response to Chris would be that in that case you
could represent anything in an RDF Data Cube. Whether it would
be useful, smart or efficient, is another question
<Zakim> phila, you wanted to make a suggestion about elephant
eating
<kerry> +1
phila: Can we start simple nad see how we go?
<kerry> +1 to billrobe_
billrobe_: It would perhaps be a good idea to look at the use
cases we've got and see where that leads us. I know we don't
want to add more but we haven't reviewed the UCs yet with this
in mind.
<jtandy> [jtandy also noted that rectilinear grids (whose axes
are not necessarily orthogonal / 90degrees) should be _in_
scope ... jonblower agreed]
<frans> I like Phil's and Bill's suggestions
<scribe> ACTION: bill to review the use cases from a Coverages
point of view [recorded in
[46]http://www.w3.org/2016/02/09-sdw-minutes.html#action06]
[46] http://www.w3.org/2016/02/09-sdw-minutes.html#action06]
<trackbot> Created ACTION-144 - Review the use cases from a
coverages point of view [on Bill Roberts - due 2016-02-16].
rachel: One of the use cases I submitted requires point cloud
data anda LIDAR so I'd like those to be attempted.
ChrisLittle: It's nice to have an ally in the Env SCiences
jtandy: But we only have a finite resource. Maybe we should
identify the order in which we'll tackle things.
<rachel> +1 to Kerry's students working on this
kerry: If I get the student support, we might have a
significant extra capacity.
... But that leads on to the timing question that Bill was
talking about.
billrobe_: Coming back to what we're obliged to do, and the
time scale. I don't know whether that's possible
... So we have to work through these steps and have some idea
of ther work involved. ANd then meet up with the schedule.
<Zakim> billrobe_, you wanted to talk about schedule
jtandy: If I can talk to the schedule. All W3C WGs have a time
line associated with them. If you want an extension, you need
to demonstrate that you are making progress and that there is
an end in sight.
... So if we can demonstrate community support and progress, we
can asl for an extension.
<kerry> +1
phila: Talked a bit abouit asking for an extension when you
have a realistic new timeline, not waiting until the lsat
minute.
jtandy: So by May we should have an idea of when we want to
finish?
kerry: Would anyone like to say that extending wouldn't be
possible from their POV?
... Any more comments about coverages at this point?
jonblower: There is some stuff that we've been doing in the
MELODIES that I can show.
... If that would be useful.
<rachel> fine by me
ChrisLittle: I just wanted to say, I don't see any mileage in
talking more about time.
==Short Pause for tea making==
<rachel> [use case for point cloud, irregular mesh coverages:
[47]http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirement
s.html#DisseminationOf3DGeologicalData]
[47]
http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#DisseminationOf3DGeologicalData]
<billrobe_> are you there kerry and rachel?
<kerry>
[48]https://www.w3.org/2015/spatial/wiki/SSN_Tasks#Modularisati
on_topic
[48]
https://www.w3.org/2015/spatial/wiki/SSN_Tasks#Modularisation_topic
<kerry> chair: edparsons
<rachel> I'm back !
<aharth> scribe: aharth
<eparsons> thanks aharth
jonblower: presents current state of the melodies project
... coverage is any kind of mapping between points in
space/time to data values
... satellite images, temperatures in space/time, point
clouds...
... different kinds of coverages are distinguished by coverages
in space and time
... basically a grid of data in space and time
<frans> Why is point geometry not a coverage?
jonblower: land cover product on screen is a kind of coverage
... three data objects make up a coverage
... the domain is the set of points for which we have data
values
... the domain varies between coverages
... the range is just the list of data values
... in many encodings there are rules for mapping points in the
domain to items in the list of the range
... the range can just be a list of numbers
... terminology taken from mathematical functions
... then there's the range metadata
... how to interpret the values in the range
... in applications domain, range and metadata are separate
bits of information that might be used separately
... the ogc coverage implementation schema consists basically
of domain, range and range metadata
... rdf is not good at representing the range values
... but rdf could be useful to describe range metadata,
possibly domain
... issue is to encode range values, one possible solution from
the melodies project is shown
... how do you get data from server to web browser that the
data can be manipulated and processed within the web
browser/client
... CoverageJSON format specification
...
[49]https://github.com/Reading-eScience-Centre/coveragejson/blo
b/master/spec.md (?)
... we defined specifications for the types of coverages we are
interested in (e.g., grids)
... data values can be represented in-line or as a separate
document
[49]
https://github.com/Reading-eScience-Centre/coveragejson/blob/master/spec.md
phila: domain is quite terse, range values can be big
... why is domain small, and range rather large?
jonblower: domain can be represented more compactly, you do not
need to list the full cartesian product
<Zakim> LarsG, you wanted to ask if Jon's explanation of
coverage is available somewhere
jonblower: plus there can be several ranges (for example,
measure temperature and other things)
... some satellite product have up to 200 different ranges
LarsG: thank you for the explanation what coverage is about
... is that written up somewhere?
... we could refer that from our documents for people who are
not versed in geographical sciences
<rachel> [thanks Jon, very clear explanation]
<eparsons>
[50]http://external.opengeospatial.org/twiki_public/CoveragesDW
G/WebHome
[50]
http://external.opengeospatial.org/twiki_public/CoveragesDWG/WebHome
frans: the idea that coverage consists of three different bins
is very helpful
jonblower: that works for every discrete coverage
<kerry> also see
[51]https://www.w3.org/2015/spatial/wiki/Cov_References
[51] https://www.w3.org/2015/spatial/wiki/Cov_References
jonblower: for analytical coverages (based on mathematical
functions that are continuous/infinite) that might not work
well
eparsons: then you'd need to specify a sampling frame?
jonblower: yes
billrobe_: supposed i have data for manchester, do i need to
read the whole domain?
jonblower: we'll come to that
... for the "metadata" bits, coordinate systems, parameters on
range metadata..., that basically is RDF in disguise (via
JSON-LD)
... explains JSON-LD @context header/document
... the example includes data like profiles, calendar
systems...
... for the range, you might want to have something more
efficient than JSON
... then again, compression works well on JSON text
... gzipped json is efficient compared to binary formats
... range values can be served in different ways, that's where
the api comes in
... haven't considered the standardisation discussion yet,
wanted to have something first that works for us
ChrisLittle: what is "Gregorian"? with our without leap
seconds?
jonblower: we reference an external definition, defined there
... the coverage community ignores small coverages
... some coverages might be fairly small, but you have lots of
them
... coverage collections is something we have to think about
... CoverageJSON is a format to describe single coverages
... but you might have 10k, and you only want to select 1k
... we looked into designing a REST API, but that's quite
experimental
... we want to bring coverages to people who do not want to
deal with a complex service
... we support content negotiation, that you can use curl/wget
to access data
... we use HTTP headers to control what the client requests and
the server returns
... paging, for example, is handled via HTTP headers
... idea is to break datasets into smaller bits, provide an api
to allow people to inquire about smaller bits
frans: why did you use pages, not tiles?
jonblower: a server that does not have spatial subsetting
capability (e.g., a web server) you need something simple
... if the server supports spatial subsetting, you can do that,
basically use the opensearch capabilites for bounding box
queries
<Zakim> jtandy, you wanted to ask is spatial / temporal filter
is on collections or cover
<billrobe_>
[52]https://github.com/Reading-eScience-Centre/coveragejson
[52] https://github.com/Reading-eScience-Centre/coveragejson
jtandy: how do represent spatial and temporal filters?
... how to access sample points?
jonblower: there is a way to access the point of the domain
based on an index
frans: how to apply the slicing/subsetting functionality in QB
ChrisLittle: we've done some initial work on tiling in ogc
<Zakim> jtandy, you wanted to talk about datacube slices and
subsets
jtandy: inside QB, they talk about subsets and slices, but it's
pretty arbitrary how to set that up
... shouldn't get hung up on QB slices
frans: interesting to have a more general api
jtandy: in QB you specify how to slice your data when you
publish it, with the CoverageJSON api you can do query-time
slicing
ChrisLittle: here's a trade-off between scalability and
flexiblity
jonblower: shows examples of hydra descriptions for the api
... there are other things as part of a stack on top of the
coverage foundations
... on the github page
[53]https://github.com/Reading-eScience-Centre/coveragejson/
... initial work on api spec, javascript libraries, plugin for
leaflet are available
... we use the technologies in a demo portal within a web
browser (HTML5..., subsetting on the server side via api)
... we also provide GeoDCAT AP descriptions
... because we have the data in a browser we can apply mappings
and process the data locally in the browser (e.g., remap
melodies land cover to modis scheme)
[53] https://github.com/Reading-eScience-Centre/coveragejson/
eparsons: quite quick, how big is the data?
jonblower: around 4k data points in the north, 2k data points
in east/weast
... loads as tiles, preloaded before the demo, zooming triggers
reloading of higher resolution tiles
frans: so you have a pyramid of tiles?
jonblower: generated on the fly, data fits in memory on the
server, we do tiling on-demand
... we think we describe the data well enough to access
multiple different coverages and integrate those (e.g., using
inference in OWL)
jtandy: just to confirm, the data is in json arrays which is
sucked into a browser
jonblower: before we had a mapping service to get tiles from
the server with many roundtrips
... running in the browser is possible though with increased
bandwidth and better browser performance
... the api could also work based on static files if you would
like to do that
<Zakim> phila, you wanted to ask about how we can help
jonblower: not necessariliy needed to implement a server
... javascript used to plot data as a zoomable widget
phila: sounds as if there's a lot of stuff there
... you showed two documents: coverageJSON, which is JSON-LD
jonblower: not fully JSON-LD because of the range values
phila: we could take that approach as basis for
standardisation?
... turn the vocabulary which has linked data where it makes
sense and does not use linked data where it does not make sense
... one hesitation is that subsetting work is a big one, but
not sure how well the existing method would work
... but there's almost a working draft there
... http link headers are useful
eparsons: there are some challenges in socialising that back to
the ogc community
... there are well-established views on how to handle coverages
jonblower: there are discussions around getting a json view on
coverages
... but still ongoing work, concepts of json serialisation
might deviate from the concepts of the xml serialisation
ChrisLittle: good way to go forward as far as i have seen here
... there's active work in ogc on coverages
... the QB misses some geo things
... for example, slicing/dicing the cube is missing
eparsons: do you see a division between qb and coverage
... the people involved are different, concepts might be
similar
ChrisLittle: there are similarities, for example city 3d work
... mechanisms are similar
... and fits into a bigger map
<kerry> see [54]https://www.w3.org/2011/gld/track/issues/34 for
the qb:subslice that was dropped from the datacube
[54] https://www.w3.org/2011/gld/track/issues/34
billrobe_: i like what jon presented, it works, simple,
principled, powerful in practice, web-y
... what i don't know are the alternatives
... we need to enumerate the alternatives
jtandy: don't know if there are many alternatives
... goes into similar direction to what peter baumann did with
the xml stuff
... but targeted for web developers
... direction is right, details might need discussion
... one thing you might want to do is processing in the browser
jonblower: we do some client-side processing
frans: two questions
... metadata is DCAT, does the metadata identify format and api
or are they separate?
... in DCAT you have a distribution, and the distribution has a
format
... file-centric view based on documents
AndreaPerego: for example, you cannot say that something is a
sparql endpoint, you need void for that
jonblower: we used to use mime types
frans: one problem with coverage is that you have large blobs
of data
... but the subsetting would take care of that?
eparsons: you could use whatever technology you want on the
server side
... all what jon describes is the mechanisms for interaction
frans: you need to limit the amounts of data that the api
serves
eparsons: wfs does not have a mechanism like that
jonblower: at least need mechanism to tell the client: "the
result is too big"
... do a http get on a large coverage collection
... and you would get a redirect to the first result page
... and links to next/prev
frans: how about not getting any data at all, but only the
metadata
... that you can pose smaller queries
jonblower: we use hydra to partially describe the api
... difficult to describe the api in a general way that a
general client can understand
... curl does at least http redirects
billrobe_: sounds like a good way to start
... we should see how to reconcile w3c/ogc views
jtandy: we should read the material before we go to china
<scribe> ACTION: jonblower to chase mike to update the
JSONCoverage document [recorded in
[55]http://www.w3.org/2016/02/09-sdw-minutes.html#action07]
[55] http://www.w3.org/2016/02/09-sdw-minutes.html#action07]
<trackbot> Created ACTION-145 - Chase mike to update the
jsoncoverage document [on Jon Blower - due 2016-02-16].
<eparsons> action billrobe_ to update on coverage plans
following China Trip
<trackbot> Error finding 'billrobe_'. You can review and
register nicknames at
<[56]http://www.w3.org/2015/spatial/track/users>.
[56] http://www.w3.org/2015/spatial/track/users
jonblower: there is the interleaved format (which is
domain:range pairs, rather like a csv file)
... especially for streaming and smaller formats
... but we do not have that in CoverageJSON
<rachel> [should that be chase maik (Reichert) instead of chase
Maik ?]
eparsons: i worry about our bandwidth, there are many
activities going on
... are the telecons we have are enough now that we have many
things going on in parallel
<kerry> not an unnecessary panic!
eparsons: the subtopics are more of interest to particular
groups
<kerry> +q
eparsons: one possibility would be to have separate telecons
for different groups, with the "main" telco to sync up
kerry: we might have to do that, issue could be that people
only go to the meeting of the particular subtopic
... time/coverage/ssn and best practice could be split
ChrisLittle: maybe split off time, maybe have a large meeting
every fortnight
... specialised ones maybe in parallel
<Zakim> phila, you wanted to talk about task forces and weekly
rotations
ChrisLittle: we could then better fit the meeting times
<kerry> +q
phila: what the DWBP does is to rotate through the deliverables
each week
... there are three deliverables
... short bit for each of the three, and then the focus is on
one of the three topics
jtandy: so once a fortnight a plenary, other weeks the
subtopics in parallel
kerry: i understand the proposal, is parallel at the same time?
eparsons: not necessarily, depending on what the groups wish
kerry: rational proposal to start from, rotating through
different deliverables one a week might be too slow
eparsons: we will make a proposal to the group for the modus
operandi moving forward
<jtandy> [subtopics: BP, Coverage, Time, SSN ... the use case
issues will be rolled into the subtopics; don't need a separate
call for UCR]
kerry: we may not have enough chairs to manage all the meetings
phila: need to involve the editors for organising meetings
eparsons: any other comments/issues?
jtandy: given we have four subtopics, some people might be
interested in more than one, i'm interested in coverage and bp
... de-conflict meeting times as much as possible
ChrisLittle: agenda page then could have the list of different
meetings
eparsons: we would like to have some regularity in the meeting
times so that other people can drop in
... we are about done, thanks for the hosts, linda for
organising
RESOLUTION: Thank you Geonovum
<scribe> ... done, meeting adjourned
<ChrisLittle> and thank you Linda for the chocolate
<rachel> claps Linda for hosting, Kerry for staying up late,
bye!
<ChrisLittle> bye
Summary of Action Items
[NEW] ACTION: bill to review the use cases from a Coverages
point of view [recorded in
[57]http://www.w3.org/2016/02/09-sdw-minutes.html#action06]
[NEW] ACTION: Danh to Reconsider O&M alignment (see O&Mlite) -
as alternative to DUL [recorded in
[58]http://www.w3.org/2016/02/09-sdw-minutes.html#action03]
[NEW] ACTION: DanhLePhuoc to Reconsider O&M alignment (see
O&Mlite) - as alternative to DUL [recorded in
[59]http://www.w3.org/2016/02/09-sdw-minutes.html#action01]
[NEW] ACTION: Haller to clearly separate observation, sensor,
and deployment parts of SSN [recorded in
[60]http://www.w3.org/2016/02/09-sdw-minutes.html#action04]
[NEW] ACTION: jonblower to chase mike to update the
JSONCoverage document [recorded in
[61]http://www.w3.org/2016/02/09-sdw-minutes.html#action07]
[NEW] ACTION: kerry to disentangle SSN from DUL (this may
require adding things to SSN that are needed from DUL)
[recorded in
[62]http://www.w3.org/2016/02/09-sdw-minutes.html#action05]
[NEW] ACTION: Phuoc to Reconsider O&M alignment (see O&Mlite) -
as alternative to DUL [recorded in
[63]http://www.w3.org/2016/02/09-sdw-minutes.html#action02]
[57] http://www.w3.org/2016/02/09-sdw-minutes.html#action06
[58] http://www.w3.org/2016/02/09-sdw-minutes.html#action03
[59] http://www.w3.org/2016/02/09-sdw-minutes.html#action01
[60] http://www.w3.org/2016/02/09-sdw-minutes.html#action04
[61] http://www.w3.org/2016/02/09-sdw-minutes.html#action07
[62] http://www.w3.org/2016/02/09-sdw-minutes.html#action05
[63] http://www.w3.org/2016/02/09-sdw-minutes.html#action02
Summary of Resolutions
1. [64]for modularisation we work with michael's proposal (but
remove dul and replace with native appropriately) and serve
it using /uris and redirects as suggested by Armin
2. [65]The SSN editors will use Web Protege as the
collaborative editing tool
3. [66]Target date for FPWD of SSN is 9 April (ish)
4. [67]Thank you Geonovum
[End of minutes]
__________________________________________________________
Received on Tuesday, 9 February 2016 14:56:37 UTC