Re: BP narrative comments

Thanks Rob.

Step 1: maybe I was reaching a bit too far to get an excuse to play with
complex vector geometries? Could you suggest a different path for our story?

Step 2: I agree that we mustn't assume that there's a single
representation. Content negotiation is not enough when you have two "views"
of the resource that use the same format. Ref. your experiments with named
views and, similarly, Eric Wilde's "profile" link header (RFC 6906 [1]) ...

Also, we can't assume that a resource is immutable- things change over time
... However, at any point in time all the representations need to be
consistent (I'm not sure if that's fully "isomorphic").

Jeremy


[1]: https://tools.ietf.org/html/rfc6906
On Mon, 4 Jul 2016 at 23:38, Rob Atkinson <rob@metalinkage.com.au> wrote:

> Hi Jeremy,
>
> Am around - shall i look for you on skype or do you want to set up a call
> - and does anyone else want to join in or do you want to manage the first
> cut at disentangling issues ?
>
> re Step1 - i started thinking about the coverage publishing case but then
> got thrown by the concluding para "To make the flooding data easier to
> use a volunteer developer publishes a Web application that converts the
> flooding coverage dataset to discrete Features with vector geometry that
> represent the flooded areas.  Each flooding area is linked to the
> administrative areas that it touches."  - which made me think the scope
> had morphed to the client side of the service (volunteers dont generally
> get to play with the data delivery side, it smelt like a client processing
> a WCS output and linking to another resource :-)
>
> re Step 2,
>
> whilst I agree that the distinction between the thing and the digital
> representation is not worth getting upset about, I think the assumption
> that there is a single representation gets you into trouble.  You cant have
> content-negotiation and a single representation unless there is something
> to enforce the content is isomorphic.  And then we come to best practice in
> the wild, and the UK Linked Data example (and my own experiments around
> this) confirm that it is feasible and useful to support multiple views of
> an object - i.e.
>
> IMHO this is the critical factor - as ilustrated by the coastline example.
> Any "premature simplification" around this will simply degenerate into
> chaos sooner rather than later.
>
> On Tue, 5 Jul 2016 at 01:30 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>
>> Hi Rob. Am now trying to digest you comments ...
>>
>> Overview:
>> ... I agree with your suggestion that we rephrase to concentrate on a
>> web-centric activity; I'll try to incorporate this
>>
>> Step (1):
>> ... reading your points, I'm thinking that perhaps my intent differs from
>> your expectation? I don't think we're trying to write a "flood prediction &
>> monitoring" best practice- only to use the flooding scenario as a basis for
>> explaining how various types of spatial data would be published on the web.
>> For this element, I simply wanted the "excuse" to work with coverage data.
>> I'm sure that all of the points you raise (from triggers through to input
>> of local conditions) are valid- but I lack the expertise to provide a
>> comprehensive description of these aspect.
>>
>> Step (2):
>> ... "administrative information": yes, too broad. Intended to refine this
>> as more detail appeared in the narrative.
>> Reading the discussion about URIs and URLs; I think the key point is
>> about distinguishing between the *Thing* and the *Representation(s) of
>> the thing*. What is the best practice here? I think that this concern is
>> well illustrated in the [draft] W3C URLs in Data Primer [1]; it talks about
>> the "Landing Page" that "describes" the "Thing". The Primer provides some
>> Recommendations. Do these begin to address your concerns? Also, I'm
>> reminded of a discussion with TimBL (during TPAC 2015) where he talked
>> about his experience with vCard; the distinction became "overly academic"
>> (I'm paraphrasing), it was simple for data consumers figure our that the
>> vCard represented the _Person_; no-one cared about the electronic
>> representation of a business card. That is, most of the time, you tell
>> through context whether you're talking about the Thing or the Landing Page.
>> You also mention "in-bound links" that enable other related information
>> to also be discovered ... from my POV, I don't yet see any best practice
>> here. Offline, we've talked around this issue a number of times. Is there
>> any concrete practice that is being used "in the wild"?
>>
>> As ever, Rob, you're right in the thick of the thorny issues (and
>> probably seeing things that I don't!).
>>
>> Are you available for a call so we can talk through these things verbally?
>>
>> BR, Jeremy
>>
>> [1]: https://www.w3.org/TR/urls-in-data/
>>
>> On Fri, 1 Jul 2016 at 06:14 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>>
>>> Hi Rob. Thanks for beginning to work on this. I'm still tied up with
>>> meetings at WMO today but will take a detailed look on Monday. Hope to
>>> catch up soon ... Jeremy
>>> On Thu, 30 Jun 2016 at 16:55, Rob Atkinson <rob@metalinkage.com.au>
>>> wrote:
>>>
>>>> Hi - I've started reviewing the narrative and have got some substantive
>>>> comments to address before going much further.  These may seem scary, but
>>>> it illustrates IMHO the value of the narrative in teasing out the role of a
>>>> BP here :-)
>>>>
>>>> [image: pasted1]
>>>>
>>>