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

Hi Jon,

that I see as possible as well, but the initial question was: how can we
describe subsetting "into" a coverage, and my point was that for this particular
case a GetCoverage request URL is quite handy.

And, yes, I was more than surprised by the RESTful reaction on result encoding
at that time. (ha, but in our WCS REST extension draft content negotiation _is_
included!)

-Peter

On 2015-10-01 18:46, Jon Blower wrote:
> Hi Peter,
>
> I guess DescribeCoverage might be a better identifier than GetCoverage - I
> doubt we want to point people directly to an endpoint that might give them
> terabytes! I think it’s fine for an identifier to point to a metadata
> document, which then directs to actual data, in cases where data volumes can
> get huge.
>
>> RESTafarians told us "no, it should be "f=GeoTIFF” 
>
> Really?? So they actually preferred a URL parameter over content negotiation?
> I suppose they must have had a reason for this, but I find that very
> surprising - and it causes some problems (e.g. if you want the same data in
> different formats you actually need separate identifiers, which appears to be
> against REST principles as I understand them).
>
> All this leads me to think that, for WxS, we need a different identifier that
> behaves “properly” in a Linked Data way, and resolves to a document that
> points to one or more access protocols (like DCAT does). I know it might not
> be ideal to introduce a new level of indirection, but I would tend to prefer
> this over using WxS URLs as LD identifiers themselves. But I’m sure there are
> different viewpoints.
>
> Cheers,
> Jon
>
>
>> On 30 Sep 2015, at 17:33, Peter Baumann <p.baumann@jacobs-university.de
>> <mailto:p.baumann@jacobs-university.de>> wrote:
>>
>> Hi Jon,
>>
>> On 2015-09-30 17:02, Jon Blower wrote:
>>> Hi Peter,
>>>
>>> I’m showing my ignorance of the details of WCS here, but is the following
>>> URL resolvable by itself?
>>>
>>>> http://www.acme.com/wcs?SERVICE=WCS&VERSION=2.0&COVERAGEID=DtmGermany25
>>>
>>> If so, then this could be a valid LD coverage identifier. But I thought
>>> (forgive me if I’m wrong) that you would need extra parameters to create a
>>> full DescribeCoverage or GetCoverage request that would be a valid request
>>> to the server.
>>
>> the only thing I forgot indeed is the GetCoverage command, so the below
>> should read:
>>    
>> http://www.acme.com/wcs?SERVICE=WCS&VERSION=2.0&REQUEST=GetCoverage&COVERAGEID=DtmGermany25
>> This downloads  coverage named DtmGermany25 in the same format and CRS as
>> stored on the server.
>>
>>>
>>>> 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.
>>>
>>> No that’s OK - I think we’re agreeing on this point.
>>>
>>> But it’s worth noting that you don’t *always* need the underlying data. For
>>> example, imagine that you want to make an assertion that “this dataset has
>>> low quality in the South Atlantic”. In this case you want to describe the
>>> subset you are talking about. The URI then resolves to this description
>>> (probably an RDF document), not necessarily the data itself. You don’t
>>> really need access to the data to get value out of that assertion, although
>>> it can help of course!
>>
>> no objection here! The use case, as I understood it, was to access a subset
>> of the data; for metadata, I'm absolutely on board with what you say.
>>
>>>
>>>> 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 :)
>>>
>>> I think you might have misunderstood me. Being a good “web citizen” doesn’t
>>> mean that everything has to be in RDF (I used RDF as an example only), but
>>> it does (in my view) involve using HTTP in a fairly standard way. My example
>>> was content negotiation - WxS uses a custom mechanism, but should (arguably)
>>> use the standard HTTP mechanism. It’s still fine to return NetCDF, GeoTIFF
>>> etc! (I’m sure these issues have been debated in the OGC-REST conversations.)
>>
>> ah, I see - so all in all we seem to be quite aligned.
>>
>> [BTW, content negotiation indeed is something I am highly impressed of, and
>> we had thought we build it into the RESTful interface to WCS, but then
>> RESTafarians told us "no, it should be "f=GeoTIFF" ". Currently we are stuck
>> with a (pretty much ready) WCS REST, hope to get insights from Testbed-11.]
>>
>> So we seem to converge on most items here after clarification :)
>>
>> -Peter
>>
>>>
>>> Cheers,
>>> Jon
>>>
>>>
>>>
>>>> On 30 Sep 2015, at 15:10, Peter Baumann <p.baumann@jacobs-university.de
>>>> <mailto:p.baumann@jacobs-university.de>> wrote:
>>>>
>>>> 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
>>>>
>>>
>>
>> -- 
>> 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)