13:05:37 RRSAgent has joined #sdwcov 13:05:37 logging to http://www.w3.org/2016/04/20-sdwcov-irc 13:05:42 zakim, code? 13:05:43 I have been told this is SDW Weekly https://mit.webex.com/mit/j.php?MTID=m4ecb967bb70c02dedc9eb66013281084, Access code 642 889 345, password sdw 13:05:50 scribe: phila 13:05:55 scribeNick: phila 13:05:58 kerry has joined #sdwcov 13:06:04 present+ kerry 13:06:10 minutes of last meeting: https://www.w3.org/2016/04/06-sdwcov-minutes 13:06:11 chair: Bill 13:06:15 present+ jtandy 13:06:18 zakim, code? 13:06:18 I have been told this is SDW Weekly https://mit.webex.com/mit/j.php?MTID=m4ecb967bb70c02dedc9eb66013281084, Access code 642 889 345, password sdw 13:06:20 PROPOSED: Accept last week's minutes 13:06:24 present+ Duo 13:06:26 +1 13:06:37 =) not present 13:06:38 +1 13:06:41 present+ sam 13:06:42 +1 13:06:45 present +Maik 13:06:47 present+ billroberts 13:06:47 +1 13:06:49 +0 - not present 13:06:51 +1 13:06:53 RESOLVED: Accept last week's minutes 13:06:54 present+ Maik 13:07:06 patent call: https://www.w3.org/2015/spatial/wiki/Patent_Call 13:07:12 Topic: Patent call 13:07:16 present+ phila 13:07:26 https://www.w3.org/2015/spatial/wiki/Meetings:Coverage-Telecon20160420 13:07:32 agenda: https://www.w3.org/2015/spatial/wiki/Meetings:Coverage-Telecon20160420 13:07:50 billroberts: First thing is to run through what we did last time 13:08:12 ... Discussed our prefered terminology and decided that 'extracts' was our favourite term for subsets. 13:08:27 ... Heard about ANU's work on something similar to, but not the same as, CoverageJSON 13:08:44 ... Looked at criteria for deciding how to choose solutions 13:08:47 https://www.w3.org/2015/spatial/wiki/Coverage_Solution_Criteria 13:09:02 billroberts: Made some rough notes on that page to open the topic 13:09:50 (Sorry, scribe distracted) 13:10:01 billroberts: Talking about what we have already 13:10:20 ... obvious question to raise, why not just use what already exists. 13:10:33 ... So if we think WCS is a good solution, job done 13:10:43 ... Bullet point notes in that page 13:11:05 What makes for 'web-friendly' ? Some initial ideas for discussion: 13:11:05 accessible over HTTP 13:11:05 follows the relevant parts of the SDW Best Practices 13:11:05 API follows patterns familiar to web data users and web developers? 13:11:05 can link to it, and can link from it to other relevant things 13:11:06 practical to receive data using HTTP over the network - extracts, option to get data in chunks etc 13:11:07 play nicely with web mapping tools 13:11:09 practical for a data owner to implement and operate a server following the standard 13:11:12 only a finite list of pre-prepared extracts available? (simple, quick, not very flexible) or allow arbitrary extracts to be requested and rely on the server to generate an appropriate response (flexible but complex to implement and may be performance challenges) 13:12:02 q+ to comment on points when ready 13:13:10 ack k 13:13:10 kerry, you wanted to comment on points when ready 13:13:41 kerry: First of all, thnk youi, Bill. Can't immediately see anything that's missing. 13:13:52 ... Slight concern over playing nicely with Web mapping tools 13:14:12 q+ to note "play nicely in common user-agents" 13:14:21 ... that might contradict some of what you said. Suppose there is no mapping tool at the moment that can consume what we think is best 13:14:30 billroberts: Fair point 13:14:32 ack j 13:14:32 jtandy, you wanted to note "play nicely in common user-agents" 13:15:02 jtandy: I wanted to suggest that rather than playing nicely with web mapping tools, it's data in a format that can work in most user agents which generally means a JavaScript engine 13:15:19 ... So I'd replace Web mapping with common user agents. 13:15:55 q+ to ask if we're talking about data [encoding] or APIs to access the data or both 13:16:03 billroberts: There's a balance between making it easy to use by a community familiar with a toolset and making it too brittle for when the toolset cahnges. 13:16:03 q+ 13:16:16 s/cahnges/changes/ 13:16:28 billroberts: XML was the solution to everything 0 years ago, now it's JSON. 10 years' time? 13:16:30 ack j 13:16:30 jtandy, you wanted to ask if we're talking about data [encoding] or APIs to access the data or both 13:16:49 jtandy: When we were talking in the CEO-LD environment, we noted that there are 2 parts. 13:17:13 ... One is making coverage data avialable in a JS engine, and there's the idea of grabbing a chunk of data to process locally. 13:17:19 just format or also API 13:17:36 jtandy: Are we defining an API that allows us to work with coverage data, request it etc, or... 13:17:55 ... just the format that we might give the data in for the UA to process 13:18:09 billroberts: Both I think, there's the API and what you get in response. 13:18:38 jtandy: So in the Coevrage JSON work that Maik and Jon have done they have the Coverage JSON and the API for requesting it. 13:18:45 billroberts: My feeling is that both are in scope for us. 13:18:46 ack k 13:19:06 kerry: I agree with the comment on playing nicely with a browser 13:19:28 ... The lost of reqs sounds like a RESTful API to me 13:19:36 q+ to suggest that an API should consider mechanisms to avoid overloading a user-agent 13:19:42 billroberts: I think your point about browser cf. web mapping tools. I'd say user agent 13:20:44 billroberts: I'd be interested to hear from people who have been using it, what people think of some of the existing solutions like OpenDAP and WCS 13:20:51 ... Why not just use WCS? 13:20:53 q+ 13:20:58 q+ 13:20:59 ack j 13:20:59 jtandy, you wanted to suggest that an API should consider mechanisms to avoid overloading a user-agent and to 13:21:23 jtandy: I'll skip the issue about overloading hte user agent. 13:21:28 ... On WCS... 13:22:02 W3C does a number of things. It's a combo of an API spec and a conceptual data model, how to package the info, and a number of binary encodings associated with it. 13:22:11 ... It's hard to unpick those 13:22:20 ... You end up with a lot of XML 13:22:28 rrsagent, make logs public 13:22:42 jtandy: The API has become very complicated as it deasl with the edge cases of an expert community. 13:22:52 ... It's complicated because it tried to do evereything. 13:23:06 billroberts: I'm sure we're not going to say there's anything wrong with WCS 13:23:08 ack s 13:23:34 ScottSimmons: Trying to avoid the conflict of interest... some of the extensions are making it more accessibile. Transactions, for example. 13:23:55 ... And there's some clever work odne on an XPath extension. Likely to become a discussion soon. 13:24:12 ... There's an evolutionary path ahead, editors are considering simplification. 13:24:40 q+ to note that the conceptual model for a coverage resource forms the basis of CoverageJSON 13:24:42 billroberts: There's a lifecycle with a standard. Things start simple and get more complex ad more edge cases are uncovered. then it's gets too complex so people start again 13:25:06 billroberts: I thinkw e shoould try and stick to what's simple. Optimise for simnplicity over capability? 13:25:10 +1 for optiising similicity 13:25:14 q+ 13:25:16 [made it to the gate without dropping wifi/audio connection!] 13:25:23 ack j 13:25:23 jtandy, you wanted to note that the conceptual model for a coverage resource forms the basis of CoverageJSON 13:26:06 jtandy: In terms of WCS, there has been some really good work in OGC taking a conceptual object... things like domain, range and rangeset 13:26:27 ... largely that's the basis of the Coverage JSON encoding that Jon and Maik have been working on. That work has an evolutionary path 13:26:29 q- 13:26:53 jtandy: There seems to be a desire to allow Coverage JSON to become on eof the encodings that WCS supports. 13:27:37 ... The work that Jon nad Maik have done is based on how developers use JSON, but if you just take the OGC model and encode it in JSON directly, it looks weird. 13:28:19 I agree to everything you said 13:28:23 billroberts: Jon and Naik can't speak here today. 13:28:40 s/Naik/Maik/ 13:28:48 billroberts: If we're talking about one specific community, then maybe Coverage JSON is a goood starting point. 13:29:08 .... Not sure what's involved in making CJ an official format of WCS. 13:29:15 q+ to ask Scott if he heard this beginning in Washington TC? 13:29:41 billroberts: So can we develop that list I started with? 13:29:52 +1 13:29:53 ... I'd also like to make sure we follow our own WG's Best Practices. 13:29:56 ack j 13:29:56 jtandy, you wanted to ask Scott if he heard this beginning in Washington TC? 13:30:30 haven't heard anything from the OGC meeting 13:30:30 jtandy: I think the Washington TC was happening a week after we were together - was there a conversation with Peter Baumann. 13:30:42 ScottSimmons: I heard the rumours, not of any progress. 13:30:56 ScottSimmons: Peter's interested but apparently is triple booked. 13:31:22 jtandy: So there may be an opportunity to progress that discussion in Dublin (the next TC) 13:31:28 q+ 13:31:56 ack me 13:32:44 phila: if coverageJSON ends up being a WCS encoding that's great. Will it be linkable enought o count as linked data? 13:32:47 +1 13:32:49 +1 :p 13:32:54 +1 13:33:15 we have defined "id" fields for most things where you are supposed to put in URIs 13:33:29 billroberts: From what I've seen... there clearly have been efforts in the CJ approach to use LD style approaches for the metadata so that you have things to link to. 13:33:43 you can give a URI to.... the coverage, the parameters, the abstract measured properties, the domain, ... 13:33:46 billroberts: If you have a URI then you can say things about it 13:34:17 billroberts: So that sounds like something we could take forwards being sufficiently linkable. 13:34:31 it is linkable, it is just not hitler-RDF 13:34:42 should be enough for most cases 13:34:50 billroberts: Anything more on this topics just now? 13:34:51 have to board the plane 13:35:04 thanks! 13:35:27 Topic: Report from ANU Team 13:36:02 https://github.com/ANU-Linked-Earth-Data/main-repo/wiki/Coverage-Recommendation-20-4-16 13:36:17 Duo: We weren't able to access the W3C wiki 13:37:03 ... So it's currently on this wiki 13:37:18 ... Hopefully Sam can talk about what we're going to do with the data Cube 13:37:50 sam: After the last meeting we looked back over what we've done with our Coverage JSON so far. More or less converting it to RDF. 13:37:59 ... You can't use SPARQL and just fetch that bit down 13:38:13 ... You have to fetch the whole lot and process it 13:38:38 ... So we tried RDF Data Cube. It's very verbose, yes, but it's very flexible with a URL for each observation 13:39:14 ... The huge space explosion is a problem, yes. We have a prototype that is looking at generating RDF triples on the fly that you don#t have to store 13:39:51 q+ to ask if there is a requirement to treat the coverage _data_ as RDF triples? 13:40:07 billroberts: That sounds sensible, you can use RDF when you need to but not when you don't. 13:40:59 billroberts: What struck me is cases where we're not talking about gridded coverages 13:41:09 ... Gridded is always more compact 13:41:19 ... A point cloud needs to lost all the coordinates 13:41:21 q? 13:41:40 billroberts: One of the things you talked about last time was a client app that can consume this data. 13:41:45 +1 13:41:49 ... Anything to report on that front? 13:42:26 Jo: We have changed everything around so we're starting from scratch now. Hoping to get a new prototye out i the next few weeks. 13:42:31 ... Ontology, client App, data etc. 13:42:53 Jo: Should be able to query a select set of arguments that you can provide. A time frame, a set of coordinates etc. 13:43:06 billroberts: That sounds very interesting 13:43:15 ack j 13:43:15 jtandy, you wanted to ask if there is a requirement to treat the coverage _data_ as RDF triples? 13:43:19 graph centric - just because you can encode coverage data in RDF, should you? 13:43:40 jtandy: Talking about encoding coverage data as RDF - just because we can, should we. What is the requirement? 13:44:00 ... When I look at the use of RDF, it's to create graphs of info, I canstitch multipel sources together. 13:44:17 ... But when we talk about geometry objects, we want the whole thing, not individual coordinates. 13:44:35 ... Do we need to just be able to query toe blob? 13:44:40 s/toe/the/ 13:44:52 jtandy: Is there really a need for the range data as triples? 13:45:22 billroberts: The kind of use cases I think of, we want to be able to relate things like land cover, and look at what crops farming are growing. 13:45:42 ... An ID might be for a parcel that is receiving a grant or whatever. 13:45:56 ... You want to see from the satellite what crop is actually being grown. 13:46:16 ... It may be that your coverage has 100 points in that polygon, or some sort of derived figure 13:46:29 ... Any solutions springing to mind? 13:47:12 jtandy: I think that's a good example. You have vector geometry intersecting with the coverage, you haev statistical data... 13:47:18 ... It ticks a lot of complicated boxes. 13:47:43 ... And probably allows us to explore whether there are benefits in encoding coverage values as RDF. 13:47:53 +q 13:48:04 ack k 13:48:26 RRSAgent, draft minutes 13:48:26 I have made the request to generate http://www.w3.org/2016/04/20-sdwcov-minutes.html phila 13:49:10 kerry: A similar example - working with statisticians. Models that would look like the data cube model. Modulo the scale problem, modelling things like Earth Obs data is conceptually similar. 13:49:43 ... So yes about the geometry. Remember we need to encode time series data. We have SSN as part of the picture. 13:50:01 ... So there's a natural fit that I think is worth investigating. 13:50:29 ... Instead of getting your head around a very differnet model which is what I see Coverage JSON as being. I don't think it's a natural data model to be working with for our targets. 13:50:53 ... This has been done before with Earth Obs data - some work from Munster. This is pre-RDF Data Cube model 13:51:10 ... their EO data - not a lot of it - but I find it pretty convincing in terms of usability. 13:51:28 billroberts: A lot of my work is around stat data as QB 13:51:41 ... the potential of that is about comparing different data sets about the same place. 13:51:52 ... So i certianly see value in elating EO data to that model. 13:52:07 ... The challenge is gridded data cf. data-backed polygons 13:52:32 ... If you're picking pixels off a picture and trying to work out which ones are relevant for my town, that's hard. 13:53:14 billroberts: Can we pick some use cases that we think are representative? 13:53:34 q+ to ask whether we should distinguish between (non)expert users 13:54:09 billroberts talks more about orders of magnitude and sense, or not, of using RDF for the range data 13:54:14 q+ 13:54:16 ack j 13:54:16 jtandy, you wanted to ask whether we should distinguish between (non)expert users 13:54:51 jtandy: One thing I think we're striving to do is to make the data more accessible. WCS queries are difficult. I imagine it woujld be hard to build a query for a QB 13:55:19 ... one of the BPs we have is that people should expose simple APIs that are easy to use as well as arbitrary query endpoints. 13:55:29 ... Should we look at that too? 13:55:30 billroberts: Yes. 13:55:59 jtandy: The good old fashioned bathing water data... all of the data is in QB. They have exposed it through a series of RESTful endpoints for eay browsinbg. 13:56:02 ack k 13:56:36 s/woujld/would/ 13:57:07 kerry: If we go towards Coverage JSON, we shoujld also connect it to an ontology model, similar to what Dimitri was presenting a couple of weeks ago. 13:57:19 ... That ontology model as JSON-LD might be worth exploring. 13:57:32 ... I don't want to limit ourselves to JSON without JSON-LD as well. 13:57:37 +1 - I think that the intent was to be able to expose coverageJSON as JSONLD 13:58:02 ... or at least the metadata 13:58:47 kerry: When Sam was speaking, he had a simple SPARQL query. What he's done is more like LD than just JSON. There's nothing complex about that SPARQL query. 13:59:02 RRSAgent, draft minutes 13:59:02 I have made the request to generate http://www.w3.org/2016/04/20-sdwcov-minutes.html phila 13:59:18 present+ Jo 13:59:19 https://www.w3.org/2015/spatial/wiki/CoverageJSON_/_REST_API_Reflection 13:59:27 https://www.gitbook.com/book/reading-escience-centre/coveragejson-cookbook/details 14:00:08 billroberts: I'll have proposals for next time 14:00:11 thanks Bill! 14:00:49 thanks everyone, sorry for abrupt end 14:02:07 phila has joined #sdwcov 14:02:13 RRSAgent, draft minutes 14:02:13 I have made the request to generate http://www.w3.org/2016/04/20-sdwcov-minutes.html phila 14:19:44 phila has joined #sdwcov 14:20:30 jtandy has joined #sdwcov 16:17:52 Zakim has left #sdwcov