- From: Peter Baumann <p.baumann@jacobs-university.de>
- Date: Tue, 29 Sep 2015 10:30:14 +0200
- To: Jon Blower <j.d.blower@reading.ac.uk>
- CC: "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Jeremy Tandy <jeremy.tandy@gmail.com>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
- Message-ID: <560A4C16.1080904@jacobs-university.de>
Hi Jon, actually, identification and access are just two sides of the same coin. The request uniquely identifies the resource and sub-resource desired. You can see a GetCoverage request as one node utilizing sort of a (standardized) microsyntax if you will, or it can be broken down into several RDF elements - that's still independent. BTW, this does not preclude identifiers for subsets. But if an identifier really is not supposed to carry any semantics inside then we're done: it is just an ID. However, this doesn't say how to _get_ the actual subset identified, ie: there is no way of resolution. If you want that, you are going to have semantics in the URI, and we are back with an RDF submodel or microsyntax. cheers, Peter On 2015-09-29 10:01, Jon Blower wrote: > Hi Peter, > > Yes, of course, WCS can *access* subsets of a coverage (so can other protocols > like OPeNDAP) but I think we need a protocol-independent way to *identify* the > subsets. > > I’m picturing an RDF fragment that encodes things like the band/variable, > spatiotemporal (or index) coordinates, and anything else. Given that URIs are > supposed to be opaque (i.e. we’re not supposed to encode semantics in the > URL), I think we have to define URIs that point to subset definitions. > > Clearly any mechanism needs to be compatible with the data models of WCS (and > CIS), but I don’t think we should just adopt the WCS GetCoverage URL as the > identifier for subsets. > > Cheers, > Jon > >> On 29 Sep 2015, at 09:32, Peter Baumann <p.baumann@jacobs-university.de >> <mailto:p.baumann@jacobs-university.de>> wrote: >> >> that's what we typically do with a GetCoverage request as a URL, it allows >> for trimming and slicing a coverage (down to single pixels). Beyond that, you >> can link to single bands, representations of the coverage in other CRSs, >> scaled versions, etc. And it's standard by OGC and soon INSPIRE and ISO. >> -Peter >> >> On 2015-09-29 03:04, Simon.Cox@csiro.au wrote: >>> >>> Ø probably don’t want to link between individual pixels in a satellite image? >>> >>> >>> >>> Not always, but sometimes. It always seemed to me that a key requirement for >>> joining gridded data and linked data was to have a URI for a subsets, >>> perhaps even down to a single pixel. Does QB help here? >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:*Jon Blower [mailto:j.d.blower@reading.ac.uk] >>> *Sent:* Tuesday, 29 September 2015 7:13 AM >>> *To:* Jeremy Tandy <jeremy.tandy@gmail.com> >>> *Cc:* SDW WG Public List <public-sdw-wg@w3.org> >>> *Subject:* Re: [linking-data] What should I link to? (or link between) >>> >>> >>> >>> Is this a question about granularity? E.g. we definitely want to link >>> between datasets, but probably don’t want to link between individual pixels >>> in a satellite image? >>> >>> >>> >>> One use case we are seeing in MELODIES a lot is that we want to link to >>> *features* that we extract from images, but probably not the raster data itself. >>> >>> >>> >>> Cheers, >>> >>> Jon >>> >>> >>> >>> >>> >>> On 24 Sep 2015, at 09:30, Jeremy Tandy <jeremy.tandy@gmail.com >>> <mailto:jeremy.tandy@gmail.com>> wrote: >>> >>> >>> >>> Email thread for collecting discussion on the question: "What should I >>> link to? (or between)" >>> >>> >>> >>> The related wiki entry for this questions is here [1] >>> >>> >>> >>> For instructions about how to engage with this discussion, please see my >>> previous email [2]. >>> >>> >>> >>> Many thanks. Jeremy >>> >>> >>> >>> [1]: >>> https://www.w3.org/2015/spatial/wiki/Linking_Data#What_should_I_link_to.3F_.28or_link_between.29 >>> >>> [2]: https://lists.w3.org/Archives/Public/public-sdw-wg/2015Sep/0044.html >>> >>> >>> >>> >>> >> >> -- >> Dr. Peter Baumann >> - Professor of Computer Science, Jacobs University Bremen >> www.faculty.jacobs-university.de/pbaumann >> mail: p.baumann@jacobs-university.de >> tel: +49-421-200-3178, fax: +49-421-200-493178 >> - Executive Director, rasdaman GmbH Bremen (HRB 26793) >> www.rasdaman.com, mail: baumann@rasdaman.com >> tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 >> "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083) >> >> > -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baumann@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baumann@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
Received on Tuesday, 29 September 2015 08:30:51 UTC