Re: things and features

Thanks Ed. This is a paper that I really like: 
http://iswc2014.semanticweb.org/raw.githubusercontent.com/lidingpku/iswc2014/master/paper/87960097-scientific-lenses-to-support-multiple-views-over-linked-chemistry-data.pdf 
. See, for instance, page 11. Their approach provides the flexibility 
many of us need without giving up on the formal characteristics.

Best,
Krzysztof

On 10/27/2015 06:22 PM, Ed Parsons wrote:
> 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 
> <mailto: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
>>     <mailto: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
>>>     <mailto: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
>>>         <http://lighthousecatalogue.com> where I say:
>>>         Beachy Head lighthouse is in England;
>>>                            has latitude 50.7337;
>>>                            has longitude 0.2414 .
>>>
>>>
>>>         Jeremy's rival lighthousespottersguide.com
>>>         <http://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
>>>         <http://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 <http://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 <mailto:jano@geog.ucsb.edu>
>     Webpage:http://geog.ucsb.edu/~jano/ <http://geog.ucsb.edu/%7Ejano/>
>     Semantic Web Journal:http://www.semantic-web-journal.net
>
> -- 
>
> *Ed Parsons*
> Geospatial Technologist, Google
>
> Google Voice +44 (0)20 7881 4501
> www.edparsons.com <http://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

Received on Wednesday, 28 October 2015 01:57:13 UTC