Re: Initial thoughts

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
>
>
>