- From: Peter Baumann <p.baumann@jacobs-university.de>
- Date: Wed, 30 Sep 2015 16:10:36 +0200
- To: Jon Blower <j.d.blower@reading.ac.uk>
- CC: Clemens Portele <portele@interactive-instruments.de>, "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: <560BED5C.6010202@jacobs-university.de>
Hi Jon,
On 2015-09-30 14:10, Jon Blower wrote:
> Hi Peter,
>
> Yes, I agree up to a point, but I think that a WxS URL is very unlikely to be
> persistent for a “long” time - this is not a criticism of WxS, but a
> recognition of the fact that access protocols change quite rapidly - versions
> change, underlying data change, etc.
I get your point, still I don't see evidence for such a general statement. As
responded to Clements, INSPIRE services will stay, and
http://www.acme.com/wcs?SERVICE=WCS&VERSION=2.0&COVERAGEID=DtmGermany25
will remain valid for quite a long time.
Underlying data change does not affect this URL, nor do format changes.
PS: just to restate: I am _not_ advocating WCS here, but resolvable service URLs
in general, as such services will be the predominent future ecosystem.
> Of course, this problem is not WxS-specific and is not solved simply by
> switching protocol. But there are mechanisms for organisations to mint and
> care for persistent URLs, and these don’t map well to custom query-oriented
> protocols (at least, not yet). This is why I think we can persistently store a
> *description* of a coverage subset, even if we can’t guarantee long-term
> persistent access to the coverage itself through a consistent protocol and
> endpoint. If we separately store the subset description (a relatively simple
> task, probably...) we can map to different access protocols and endpoints as
> they evolve to permit access.
PS2: I am also not arguing against RDF _descriptions_; storing a complete
request is but one option. However, in order for a URI to be resolvable it
invariably will need some final, down-to-earth access protocol, be it a file
path, ftp, or a Web service. That was the point I meant to make. Sorry if I was
unclear on this.
>
> Also, there is the specific question of the behaviour of WxS, which don’t use
> standard HTTP mechanisms for content negotiation and other things. For
> example, ideally I would like a Linked Data URL to return RDF when I GET it
> with an appropriate Accepts header. I think this is part of what Ed was
> referring to when he talked about “good LD citizenship”. If WxS behaved more
> like the Web in general we might have fewer of these problems, but there is
> history in OGC dating back some time.
Not sure many people will want to get an image as RDF triples - this is where
Semantic World is opening itself to acknowledge foreign citizenships :)
cheers,
Peter
>
> Cheers,
> Jon
>
>
>
>
>> On 30 Sep 2015, at 11:55, Peter Baumann <p.baumann@jacobs-university.de
>> <mailto:p.baumann@jacobs-university.de>> wrote:
>>
>> From a practical perspective, any URI that wants to resolve will represent an
>> access method, there is no difference.
>>
>> In a static file path, the directory can change. A service offering can
>> change. Anything referenced in an RDF triple can change without informed
>> consent of the triple. Whether this is "very likely to change" obviously is
>> dependent on the individual service and cannot be stated in general. Taking
>> the below example, a WCS service is extremely unlikely to change its
>> parameter "SERVICE=WCS" ;-)
>>
>> REST has suffered from religious wars on what a "good URI" is, guess we don't
>> want to get stuck in this again. A client just needs some URI that resolves,
>> anything else is a matter of taste.
>>
>> my 2 cents,
>> Peter
>>
>>
>> On 2015-09-30 10:44, Clemens Portele wrote:
>>> Re 1) A WxS URL is in general not a good URI as it is unlikely to be
>>> persistent. It is technology and often also implementation dependent and
>>> both are very likely to change with time. Just consider parameters like
>>> service=WXS or version=2.0.0.
>>>
>>> Best regards,
>>> Clemens
>>>
>>>
>>>
>>> On Wed, Sep 30, 2015 at 10:31 AM, Jon Blower <j.d.blower@reading.ac.uk
>>> <mailto:j.d.blower@reading.ac.uk>> wrote:
>>>
>>> Sorry! My mistake, I managed to confuse myself (easily done). Yes, the
>>> URI doesn’t have to be opaque from the server’s point of view, but I
>>> meant that the client shouldn’t try to decompose the URL. This means
>>> that the client doesn’t necessarily know ahead of time that a URL
>>> represents a WCS (or whatever) query.
>>>
>>> The questions in my mind are:
>>>
>>> 1. Is a WxS, OPeNDAP or other Web Service URL a good Linked Data
>>> identifier? I’m not really convinced it is, but I’d need to unpick
>>> things further.
>>>
>>> 2. If I want to annotate an arbitrary subset of a dataset, it may not
>>> even be possible to specify this subset in a single URL, depending on
>>> the protocol(s) the server offers. So I think we might still need a
>>> mechanism to *describe* subsets independent of protocol.
>>>
>>> Cheers,
>>> Jon
>>>
>>>
>>>
>>>
>>>
>>>> On 30 Sep 2015, at 05:35, Simon.Cox@csiro.au
>>>> <mailto:Simon.Cox@csiro.au> wrote:
>>>>
>>>> Ø Given that URIs are supposed to be opaque …
>>>>
>>>>
>>>>
>>>> Not exactly. URIs are not required to be transparent, and from the
>>>> client’s point of view they should be treated as opaque. But there may
>>>> be a good reason from the server-side point of view for them to encode
>>>> a query – just think of it as a formula for minting a unique URI to
>>>> denote a subset. And (all other things being equal) there is no harm
>>>> done if a URI is predictable, and many of them on the web are!
>>>>
>>>>
>>>>
>>>> Furthermore, I find it hard to imagine an opaque URI if it denotes a
>>>> *query*, which is more-or-less essential if it is a regular subset.
>>>>
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> *From:*Jon Blower [mailto:j.d.blower@reading.ac.uk]
>>>> *Sent:* Tuesday, 29 September 2015 6:02 PM
>>>> *To:* Peter Baumann <p.baumann@jacobs-university.de
>>>> <mailto:p.baumann@jacobs-university.de>>
>>>> *Cc:* Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au
>>>> <mailto:Simon.Cox@csiro.au>>; Jeremy Tandy <jeremy.tandy@gmail.com
>>>> <mailto:jeremy.tandy@gmail.com>>; public-sdw-wg@w3.org
>>>> <mailto:public-sdw-wg@w3.org>
>>>> *Subject:* Re: [linking-data] What should I link to? (or link between)
>>>>
>>>>
>>>>
>>>> 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 <mailto: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>
>>>> <mailto:jeremy.tandy@gmail.com>
>>>> *Cc:* SDW WG Public List <public-sdw-wg@w3.org>
>>>> <mailto: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 <http://www.faculty.jacobs-university.de/pbaumann>
>>>>
>>>> mail: p.baumann@jacobs-university.de <mailto: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 <http://www.rasdaman.com/>, mail: baumann@rasdaman.com <mailto: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)
>>
>>
>
--
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 Wednesday, 30 September 2015 14:11:17 UTC