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