Re: Initial thoughts

Sounds good. Glad you found that useful - i didnt see much other feedback,
so i'm guessing i didnt miss much. Its such a multi-headed beast that I
guess its quite hard to get a handle on for specialists in a particular
area.

 Can I make one suggestion that the three groups will have some different
priorities - but it is perhaps the interoperabiity between these that
matters most - i.e. what needs to be common. Lets have a go at a simple way
to highlight this.

I would also assume N groups and 3 as an initial focus.  For example I can
see additional cases that perhaps dont fit in to the normal interpretation
of those groups
1) The internet of Things - how would sensors get linked to more static
resources such as metadata, models, literature etc?
2) Numerical models
3) augmentation of SDI - such as annotations, VGI and applications built on
top of SDI (the SDI providing the opportunity to identify that the same
thing is being referenced.

perhaps some of these can get wrapped up in spatio-temporal data - or
handled by careful scoping of the cases.

The scenario planned easily covers these - and perhaps could be used to do
a high-level anaysis of the need to have a hybrid architecture for real
 world problems - and LD as a fit to glue the peices together.. IMHO thats
a pretty profound clarification and guide - and can be a driving force to
say which stars are going to matter most for different groups.

As it happens, I'll have an opportunity to develop a demonstrator based on
spatio-temporal narratives on an SDI using these emerging BP - so will be
able to ramp up my involvement.

Cheers
Rob

On Thu, 25 Feb 2016 at 00:43 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:

> Hi Rob-
>
> Many thanks for your review and analysis. We spent some time during the
> recent SDW F2F meeting in Amersfoort [1] discussing your feedback.
>
> Fundamentally, we agree with your assessment! There is still a long way
> for us to go until the doc is a useful resource.
>
> Looking at the BPs, I agree that these are all quite low level. I think
> there is opportunity to group some of them together to (a) avoid
> duplication and (b) make the best practices clearer.
>
> Additionally, we agreed that we need to expose the best practices within a
> narrative. Given the interests of the group, we have selected an emergency
> response scenario concerned with flooding. Bart van Leeuwen has begun
> drafting an outline for the scenario [2] into which we editors will fit the
> best practices.
>
> For me, I think that the best practices break down into 3 groups:
>
>    - those for people with existing SDIs
>    - those for people who have previously been publishing on the web as
>    unstructured / semi-structured data
>    - those for people publishing data with spatial aspects through social
>    media (where they have less control over what they can do)
>
> We aim to make the best practices clear for each group, indicating that
> "_this_ is what you should aim to achieve" - even if we may suggest more
> than one way to do that; it's unlikely that a one-size approach will suit
> everyone. Given multiple choice we will need to help people determine which
> is best for them ...
>
> As you infer, we need to bring all the best practices together into
> something coherent ... what does an 'interoperable web' look like for
> spatial data?
>
> We think that Linked Data is the target pattern for interoperability ...
> but recognise that there's value to be had from achieving fewer than
> 5-stars (TBL's 5-star rating [4]). I think you are right that we need to be
> clearer about the architectural pattern we're aiming for that will enable
> the "web to be used as a data sharing platform".
>
> We, the editors, aim to have another release of the best practices by end
> April. During the intervening time we will work through each of your
> concerns and respond to your email [3]. We'll also be trying to take on
> board the 'big picture' changes too!
>
> Particularly with respect to the [discoverability] of links, I would like
> to work closely with you to capture your insights for inclusion in the next
> publication of the best practices Working Draft. Hoping we can find time to
> skype etc.
>
> Thanks for the feedback and comment. Thanks in anticipation for helping us
> improve the BP further :-)
>
> Jeremy
>
>
> [1]:
> https://www.w3.org/2015/spatial/wiki/Meetings#Amersfoort_.28Amsterdam.29
> [2]: https://www.w3.org/2015/spatial/wiki/BP_Narrative
> [3]:
> https://lists.w3.org/Archives/Public/public-sdw-comments/2016Feb/0021.html
>
> [4]: https://www.w3.org/DesignIssues/LinkedData.html#fivestar
>
> On Mon, 8 Feb 2016 at 05:16 Rob Atkinson <rob@metalinkage.com.au> wrote:
>
>> I have looked over the draft BP - and not seen a lot of comments emerging
>> - so I'd like to kick of some discussions before I worry about detailed
>> comments.
>>
>> The "big ticket" item I feel is that there is a quite extensive list of
>> Best Practices - at quite a low level - enough to be daunting - but there
>> is not a clear sense of which set to apply under which circumstances.
>>
>> Its fair to say that, given the scope is (understandably) proven best
>> practice - application of these practices is not a guarantee that an
>> interoperable Web of Data can be built (as current practices have not
>> achieved such a thing in any substantial way - it is still basically
>> impossible to discover the nature of content exposed via services).
>>
>> I think that there needs to be a introductory treatment that a single
>> implementation architecture is not being specified - and the user is
>> essentially on their own to choose which BP are applicable to their chosen
>> approach.
>>
>> A key question is where relationships are expressed and discoverable -
>> the links.
>> There are multiple options, each with pros and cons and some practice -
>> and these options are not mutually exclusive - but no "best" practice is
>> identified (or can be yet IMHO). These options include:
>>
>> 1) data publishers are responsible for embedding links into information
>> resources returned when URIs are dereferenced
>> 2) many resources in arbiitrary locations may embed relationships - and
>> some crawling infrastructure is to collate these resources and present them
>> to the user - perhaps by hijacking the dereferencing mechanism to invoke
>> services to replace or augment the information resources available by
>> default?
>> 3) Well-known metadata (e.g. robots.txt, VoiD documents in standard
>> locations for a domain)
>> 4) well-known services where related resources can be registered by a
>> third party
>>
>> On top of this are all the questions about canonical formats - RDFa,
>> JSON-LD, etc - which I think are orthogonal to the content disposition
>> issue. I think you need to address the disposition contracts before the
>> usefulness of specific formats can be evaluated.
>>
>> These are are at the heart of Semantic Web concepts - Open World,
>> Non-unique Naming and AAA - but there is really no obvious BP for
>> implementation - in fact most projects seem to deal with these issues by
>> ignoring them in favour of a centralised repository.
>>
>> If we are truly going to link data - and especially if we are going to
>> handle spatial data exposed by specialised service interfaces - then these
>> basic architectural patterns need to be discussed. Without it I fear the BP
>> is not going to be easily assimilated or provide useful guidance.
>>
>> This then has the follow-up advantage of allowing the many BP in the
>> current discussion to be grouped or cross-references to which patterns they
>> are relevant for.
>>
>> Regards
>> Rob Atkinson
>>
>>
>>