Re: things and features

Thanks Krzysztof, for your comments.. I will leave it to the editors to
make any response, but duly noted thank you !

ed


On Tue, 27 Oct 2015 at 23:04 Krzysztof Janowicz <janowicz@ucsb.edu> wrote:

> Hi,
>
>
>
> Hope things are going well in Sapporo and sorry not to be able to join
> you.
>
>
> Same here. I was also trying to follow the IRC protocol and would like to
> comment on the owl:sameAs issue. I agree with ahaller2's statement that we
> should not ignore what is and has been best practice for Linked Data over
> the years. There are clearly some issues with the broad and often
> misleading use of owl:sameAs but it is still the only relation we have that
> has a formal semantics. It also states that two URIs point to the same
> thing which is a very useful and powerful statement as it establishes
> identity.  There is a lot of new work that proposes a nested solution by
> introducing weaker statements as well. Typically, these solutions combine
> owl:sameAs with SKOS (e.g., skos:closeMatch) and rdfs:seeAlso. Predicates
> such as samePlaceAs have been proposed in the literature but their
> semantics remained unclear and this is why we do not see them in the wild.
>
> Best,
> Krzysztof
>
>
>
> On 10/27/2015 02:12 AM, Bill Roberts wrote:
>
> 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
>
>
>
> --
> Krzysztof Janowicz
>
> Geography Department, University of California, Santa Barbara
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
>
> Email: jano@geog.ucsb.edu
> Webpage: http://geog.ucsb.edu/~jano/
> Semantic Web Journal: http://www.semantic-web-journal.net
>
> --

*Ed Parsons*
Geospatial Technologist, Google

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