Re: things and features

Thanks Ed. Will check through today's notes too and contribute if I can. Time zones and other travel at my end have made it hard to be more closely involved





> On 27 Oct 2015, at 09:07, Ed Parsons <eparsons@google.com> wrote:
> 
> 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