Re: things and features

Hi Bill,

In answer to your questions we ( the people in the room) came up with...

If we take the simple approach, does it lead to contradictions or data
consumption problems?
*That's life we accept it :-)*

Can we let people add spatial data to the web in the way that suits their
purpose and still make it useful and interoperable?
*Yes to be tested however against the BP work*

Where do we strike the balance between ease of publishing and understanding
vs strict standardisation/consistency for easier machine readability?
*Not sure what you mean, but this might be application specific - we need
to gather examples of different approaches.*

Thanks so much for taking a look at the minutes.

Ed




On Mon, 26 Oct 2015 at 11:52 Bill Roberts <bill@swirrl.com> wrote:

> Hi all
>
> Hope things are going well in Sapporo and sorry not to be able to join
> you.  I’ve been reading through the notes from Monday’s discussion and just
> thought I’d contribute the following, that I was writing up over the
> weekend.  If you’ve already covered this topic at the meeting, feel free to
> park this for now - I realise there are many other things to cover too.
>
> Things, Features, Spatial Objects
>
> I think we should try to accommodate a simple straightforward data model
> wherever possible.  That doesn't preclude a richer or more precise data
> model when circumstances require, but in many cases I think we can often
> just work with descriptions of a Thing (without having to puzzle about
> whether it's a thing or a feature or a spatial object).  There might be
> lots of different descriptions of that Thing from different sources in
> different contexts but that is already a well established practice on the
> web and in the world in general.
>
> I might want to set up lighthousecatalogue.com where I say:
> Beachy Head lighthouse is in England;
>                    has latitude 50.7337;
>                    has longitude 0.2414 .
>
>
> Jeremy's rival lighthousespottersguide.com ("For the lighthouse
> connoisseur") says
>
> Beachy Head lighthouse has geometry X .
> X asWKT "MULTIPOLYGON(blah)" .
> X asGML "<gml> blah </gml>" .
> Beachy Head lighthouse has a height of 43m;
>       is red and white ;
>       produces two white flashes every 20 seconds;
>       has web page <https://en.wikipedia.org/wiki/Beachy_Head_Lighthouse>
> .
>
> These are clearly two different representations but we don't necessarily
> need a spatial object or Feature to manage this situation.
>
> Jeremy and I might use the same URI for Beachy Head lighthouse or
> different ones.  If we use different ones, one or other of us, or a third
> party, might want to assert that those URIs have a sameAs relationship and
> then the faithful users of my Lighthouse Catalogue can also easily find out
> that it's red and white.
>
> In some cases, you might want to apply provenance or versioning
> information to those descriptions - and there are various ways to do that,
> whether by using the linked data 303 approach to separate real world thing
> and a document about it, or just having some document that has an
> identifier.  Maybe we should recommend how to do that for spatial data.
>
> Jeremy's side project, historyoflighthousesurveyingtechniques.com, might
> need to go further and introduce specific identifiers for different
> representations of the lighthouse over time. So that involves choosing a
> modelling approach appropriate to the data to be represented. But my simple
> list of where to find lighthouses shouldn't have to worry about that.
>
> I’m not sure of the answers to these questions:
>
> If we take the simple approach, does it lead to contradictions or data
> consumption problems?
>
> Can we let people add spatial data to the web in the way that suits their
> purpose and still make it useful and interoperable?
>
> Where do we strike the balance between ease of publishing and
> understanding vs strict standardisation/consistency for easier machine
> readability?
>
>
>
> --

*Ed Parsons*
Geospatial Technologist, Google

Google Voice +44 (0)20 7881 4501
www.edparsons.com @edparsons