Spatial Data on the Web Working Group Teleconference

<eparsons> https://www.w3.org/2015/spatial/wiki/Agenda_F2F3

<kerry> scribe: BartvanLeeuwen

<kerry> scribeNick BartvanLeeuwen

<kerry> scribeNick: BartvanLeeuwen

<phila> agenda: https://www.w3.org/2015/spatial/wiki/Agenda_F2F3

<phila> chair; Ed

<phila> chair: Ed

SSN stuff

SSN

<kerry> 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: 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> SHACL

<phila> IoT Lite Ontology

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> https://lists.w3.org/Archives/Public/public-ssn-cg/2012Jun/0000.html

kerry: the charter mentions modularisation in particular

<ahaller2> https://github.com/AGLDWG/TR/blob/master/ontology

kerry: I did a sketch of what is written in the email

<kerry> 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: 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> 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> 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> 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: 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: <http://ssn.example.org/schema/> .

<aharth> and then multiple files: http://ssn.example.org/schema/dolce.rdf, http://ssn.example.org/schema/core.rdf and

<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> 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 = http://webprotege.stanford.edu ... is there a better link?

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> 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> 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 http://www.w3.org/2016/02/09-sdw-minutes.html#action01]

<trackbot> Error finding 'DanhLePhuoc'. You can review and register nicknames at <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 http://www.w3.org/2016/02/09-sdw-minutes.html#action02]

<trackbot> Error finding 'Phuoc'. You can review and register nicknames at <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 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 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 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> 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: 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> 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 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> 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> 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 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: http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#DisseminationOf3DGeologicalData]

<billrobe_> are you there kerry and rachel?

<kerry> 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
... https://github.com/Reading-eScience-Centre/coveragejson/blob/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

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> 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 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_> 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 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)

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 https://www.w3.org/2011/gld/track/issues/34 for the qb:subslice that was dropped from the datacube

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 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 <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