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

as you say: a URI, in order to be referenceable, needs "some infrastructure in
place". A URI is a piece of data that needs to be evaluated by some instance, we
seem to agree on that. Then the question remains: how persistent is a particular
URI = service? IMHO this needs to be decided by a case-by-case basis.
For example, I have seen many URLs become invalid, whereas INSPIRE services are
maintained with a clear long-term perspective.

-Peter




On 2015-09-30 14:01, Clemens Portele 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
>> <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:05:19 UTC