things and features

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?

Received on Monday, 26 October 2015 11:51:38 UTC