- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Tue, 27 Oct 2015 16:03:07 -0700
- To: public-sdw-wg@w3.org
- Message-ID: <563002AB.4010806@ucsb.edu>
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
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net
Received on Tuesday, 27 October 2015 23:03:39 UTC