Re: [linking-data] What should I link to? (or link between)

In general, I think that the idea of opaque URL's is both widely misunderstood and obsolete. There is a difference between recognizing a well known URL pattern as an identity and parsing one for navigation information. With the availability of extensive re-writing and forwarding capabilities, giving some random server control over the global locator for a resource is really not necessary.

The OGC services can certainly constitute mechanisms for resolving / de-referencing links however those URL's are defined, but access to fine-grained navigation and metadata information is not for the most part there yet in a RESTful OGC services binding. It's close, and the group's work on linking requirements can help to push it along.

Josh

Joshua Lieberman, Ph.D.
Principal, Tumbling Walls Consultancy
Tel/Direct: +1 627-431-6431
jlieberman@tumblingwalls.com

> On Sep 30, 2015, at 08:01, Clemens Portele <portele@interactive-instruments.de> wrote:
> 
> Sure, IMHO the good practice is to use URIs that will resolve as long as the resource is relevant and may be referenced by others. If you can guarantee that a WxS access URL will work over that expected timeframe that URI should work fine.
> 
> It is just not the case in my experience over the last years. It also means (to take the WCS example and let’s assume that WCS will be used for a long time) that even if there is a new WCS 2.0.2 or WCS 2.1.0 version, the provider would still have to support the WCS 2.0.1 interface, if existing URIs should remain valid as "version=2.0.1" is part of the URL. The longer a resource is relevant, the more care has to be spent in specifying your URIs. This has nothing to do with any religious wars. 
> 
> And of course a WxS URL is much better than no URI in any case. In a star ranking I just would give it less stars than a URI that is designed for long term stability, usually with some infrastructure in place. 
> 
> Take the OGC URIs for coordinate reference system definitions maintained by EPSG as another example. http://www.opengis.net/def/crs/EPSG/0/4326 is intended to be persistent, even if the backend implementation changes. Otherwise there would have been no point for OGC to specify that URI and everyone could have used http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:crs:EPSG::4326 or whatever the URI is that OGP/EPSG as the authority exposes.
> 
> Clemens
> 
> 
>> On 30 Sep 2015, at 12:55, Peter Baumann <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> 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 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>
>>>>> Cc: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; Jeremy Tandy <jeremy.tandy@gmail.com>; 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> 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> 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)
>> 
>> 
>