Re: Rewrite of the BP narrative [SEC=UNCLASSIFIED]

Hi-

@bill ... thanks for responding. You say:

> I think the driving force for the 'reinventing' is the first point of the
stated mission of the working group: "to determine how spatial information
can best be integrated with other data on the Web".
>
> Some of the existing approaches, while serving their existing communities
of (mostly expert) users well, tend to use the web as a transport mechanism
for files to be analysed offline.  In order to integrate with other data on
the web, we need to look at web identifiers and links 'inside' the data,
and to find ways of expressing spatial data that is compatible or
inter-linkable with other web-based information about places.

and emphasise that:

> existing tools and formats generally serve the expert user of spatial
data quite well, and we are not trying to replace those but to supplement
them.

+1 from me.

Picking up some points from @bruce.

> add some complementary perspectives from the point of view of the end
users of the published data and of how they would utilise that data

I can see the benefits of this; data provision is a two-sided coin :-) ...
Within the narrative that I have outlined, there are a number of stages
where actors are using spatial data to get their job done (although I have
skipped over these actions in favour of data publication bits). Examples:
* web developer uses inundation coverage data to build a web app that
returns discrete (vector) Features for inundation areas
* web developer determines which administrative areas 'touch' inundation
areas
* emergency teams prioritise critical infrastructure to protect by
identifying categories of assets that are 'within' inundation areas - or
care-homes to assist with evacuation
* emergency teams determine hazard exposure by requesting water depth at
coordinates of critical infrastructure
* section (5) illustrates combining census data that is geocoded by
administrative areas with the administrative areas that are affected by
inundation
* emergency teams create the evacuation plans; refuges and safe transit
routes- no doubt a complex piece of GI analysis
* media and news agencies use the evacuation plans to build simple web
applications- e.g. using reverse geocoding from the geo-location provided
by a user agent to find the administrative area they are within; then
finding the associated evac plan ... and displaying the refuges / transit
routes on [web] maps
* emergency teams (for example) using social media reports of flood extent
observations to track the flood impact in real time
* ... etc.

So there's lots of opportunity to talk about usage of spatial data in this
scenario - I just skipped over those activities :)

> end users will need to undertake some kind of spatial analysis for their
own purposes, probably using very specialised applications and processes
that have evolved over many years

As @bill says, we're trying to complement the expert systems by exposing
spatial data for use _in_ the Web; in this work, we're wanting to use the
Web as the [data sharing] platform. That said, we need to recognise that it
will often be the case that the expert GI community will need to find &
consume data for their (offline) spatial analysis (such as the creation of
evacuation plans highlighted above).

> In the case of multi-dimensional array data described in several of these
examples, we have formats like netCDF and services like WCS

netCDF is great - but, to my knowledge, you can't work with it _in_ the
browser. Similarly, WCS provides significant capability, but is complex to
use (& implement) and the response formats for coverage data can't be
[easily] processed in a typical user-agent. That said, I think there's talk
of taking the CoverageJSON work [1] as the basis of a JSON coverage
encoding supported in the WCS spec.

> I'm personally not seeing much attempt at reusing the good aspects that
have come from the OGC community

On my radar I see: GeoSPARQL, Application Schema for Coverages / ISO 19123,
O&M / ISO 19156, SensorThings API.

You will also see in the Geonovum testbed topic 4 report [2] work to figure
how to make SDI compatible with Web architecture.

OK; citing GeoSPARQL highlights the gap you identify:

> very, very few had any understanding of the Linked
Data/Data Semantics concepts

This is something we need to actively address. We want to achieve the goals
of Linked Data (that's what we've agreed as a WG) but without forcing
people to eat the RDF and OWL pies. Manu Sporny (one of the creators of
JSON-LD) describes a similar concern when talking about his aspirations for
JSON-LD [3] ("JSON-LD and why I hate the semantic web" ... watch for some
colourful language!).

> I need good, pragmatic, approaches that allow me to work with federated,
consistent, data services to underpin global analysis of a number of
inter-related scientific domains. I need to understand the semantic nuances
within the federated data services, the semantic relationships in the
concepts between domains, together with the need for a very good
understanding of data quality and data provenance. So I'm not just after a
way of finding linked resources, I need to be able to analyse them and
exploit the rich information contained within.

I think this is a good summary of concerns that I will strive to braid into
our efforts. I had hoped that we are headed in that direction already ... I
see the need to make this explicit in our work.

> </Rant>    ...with apologies.

No apology needed. We're all on the same side :)

Jeremy

[1]: https://github.com/Reading-eScience-Centre/coveragejson
[2]: http://geo4web-testbed.github.io/topic4/
[3]: http://manu.sporny.org/2014/json-ld-origins-2/

On Wed, 27 Apr 2016 at 09:38 Bill Roberts <bill@swirrl.com> wrote:

> Hi Bruce
>
> I think you identify a good point, that for any working group like this it
> is always tempting to invent new things, rather than review and perhaps
> augment existing things - so as a group, we should always question
> ourselves and test the justification for any recommendation to do something
> other than use current common approaches.  Perhaps there is scope to do
> that more rigorously or more completely, though I have been involved in
> several discussions on variations of that topic.
>
> I think the driving force for the 'reinventing' is the first point of the
> stated mission of the working group: "to determine how spatial information
> can best be integrated with other data on the Web".
>
> Some of the existing approaches, while serving their existing communities
> of (mostly expert) users well, tend to use the web as a transport mechanism
> for files to be analysed offline.  In order to integrate with other data on
> the web, we need to look at web identifiers and links 'inside' the data,
> and to find ways of expressing spatial data that is compatible or
> inter-linkable with other web-based information about places.
>
> So my feeling (and I'm not claiming to speak on behalf of the working
> group in any way) is that the existing tools and formats generally serve
> the expert user of spatial data quite well, and we are not trying to
> replace those but to supplement them.
>
> To connect spatial data to other data on the web means that the users and
> creators/curators of the other data on the web should be able to understand
> it.  Some aspects of spatial data are inherently complicated, but if we can
> identify ways in which some common use cases can be supported simply, then
> we stand the chance of greatly increasing the overall value that can be
> gained from using spatial data.
>
> While doing that, we should ensure that we are clear about which users we
> are targeting and which design choices we are making - to ensure that we
> are not just inventing a new (but probably less well supported and tested)
> equivalent of what already exists.
>
>
> Best regards
>
> Bill
>
> On 27 April 2016 at 02:04, Bruce Bannerman <B.Bannerman@bom.gov.au> wrote:
>
>> Hi Jeremy,
>>
>>
>> You do not have an enviable task. Well done for persevering!
>>
>>
>>
>> @All,
>>
>>
>> I note that these user stories are from the perspective of the data
>> publisher and to be honest using concepts that are alien to most current
>> data publishers.
>>
>>
>> Perhaps we can add some complementary perspectives from the point of view
>> of the end users of the published data and of how they would utilise that
>> data. In many (perhaps most) cases, for this type of situation, I suspect
>> that end users will need to undertake some kind of spatial analysis for
>> their own purposes, probably using very specialised applications and
>> processes that have evolved over many years. Most of these users will
>> similarly find many of the concepts expressed to be alien. Most of these
>> users will probably not be web developers.
>>
>>
>> I'm personally at a loss to understand why we are trying to invent data
>> formats and data services when we have perfectly adequate representations
>> available now as 'Best Practice'. In the case of multi-dimensional array
>> data described in several of these examples, we have formats like netCDF
>> and services like WCS.
>>
>>
>> Why do we want to reinvent the wheel?
>>
>>
>> What is it about the current approaches that aren't working?
>>
>>
>> Perhaps this is where we can target the 'Best Practice'. Use what is good
>> and can be effectively used now. And envision a better way for the aspects
>> that aren't working well.
>>
>>
>> Just my 2c as a frustrated W3C SDWWG observer trying to make sense of
>> this from 'data publisher' and 'spatial data analyst user' perspectives.
>>
>>
>>
>> <Rant>
>>
>> I can see a lot of potential from Linked Data and Data Semantics
>> approaches, that is why I'm investing time with this working group. But I
>> don't want to see the good work from many people over many years
>> disregarded out of hand with no clear rationale provided.
>>
>>
>> This is supposed to be a joint W3C and OGC working group, but I'm
>> personally not seeing much attempt at reusing the good aspects that have
>> come from the OGC community.
>>
>>
>> By way of a reality check: I recently attended our national spatial
>> information forum. This is a cross disciplinary and technology neutral
>> forum. Most people had a reasonable understanding of open spatial standards
>> and services, but very, very few had any understanding of the Linked
>> Data/Data Semantics concepts that we're discussing here. When discussed in
>> presentations it was typically referred to as a research concept that may
>> possibly have some relevance at some time in the future.
>>
>>
>> We have an opportunity here to make a real difference with Linked Data
>> and Data Semantics, just don't throw the baby out with the bath water
>> please.
>>
>>
>> I need good, pragmatic, approaches that allow me to work with federated,
>> consistent, data services to underpin global analysis of a number of
>> inter-related scientific domains. I need to understand the semantic nuances
>> within the federated data services, the semantic relationships in the
>> concepts between domains, together with the need for a very good
>> understanding of data quality and data provenance. So I'm not just after a
>> way of finding linked resources, I need to be able to analyse them and
>> exploit the rich information contained within. I cannot see that I will be
>> able to do this effectively with just using current approaches, but we do
>> appear to be on the right path when we start complementing them Linked Data
>> and Data Semantics approaches.
>>
>>
>> Spatial Information is not a simple concept. People undertake substantial
>> tertiary study to understand the basics.
>>
>>
>> </Rant>    ...with apologies.
>>
>>
>>
>>
>> Bruce
>>
>>
>>
>> ------------------------------
>> *From:* Jeremy Tandy <jeremy.tandy@gmail.com>
>> *Sent:* Wednesday, 27 April 2016 7:55 AM
>> *To:* SDW WG Public List
>> *Subject:* Rewrite of the BP narrative
>>
>> All-
>>
>> In working through ACTION 162
>> <https://www.w3.org/2015/spatial/track/actions/162> I've taken a good
>> look at the narrative we plan to use for the Best Practice document. We
>> needed to include tangible examples the we can elaborate on ...
>>
>> I offer a second version of the narrative [1] that tries to do this.
>>
>> You'll find 9 discrete parts, each of which can be elaborated with
>> detailed examples.
>>
>> This doesn't represent consensus between the editors as we've not had the
>> opportunity for wider discussion. However, I wanted to share this with the
>> wider group prior to the plenary call tomorrow.
>>
>> Comments welcome - even if it's "back to the drawing board please".
>>
>> Regards, Jeremy
>>
>> [1]: https://www.w3.org/2015/spatial/wiki/BP_Narrative_2
>>
>
>