W3C home > Mailing lists > Public > public-sdw-wg@w3.org > May 2017

Re: WG discussion: shall we recommend a "samePlaceAs" property?

From: Linda van den Brink <l.vandenbrink@geonovum.nl>
Date: Sat, 6 May 2017 07:22:37 +0000
To: Jeremy Tandy <jeremy.tandy@gmail.com>
CC: Joshua Lieberman <jlieberman@tumblingwalls.com>, Frans Knibbe <frans.knibbe@geodan.nl>, SDW WG Public List <public-sdw-wg@w3.org>
Message-ID: <04DAEF7F-CEDD-4925-8E93-DE4B13B2E885@geonovum.nl>
Much improved now that it's two best practices!

One thing; I still see the samePlaceAs proposal in BP10, and not in the conclusions/gaps section.

Op 6 mei 2017 om 00:08 heeft Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>> het volgende geschreven:

All- just a quick advisory to say that I've updated the BP doc to reflect our discussions in Delft about spatial thing.

BP10 [1] has had what looks like a comprehensive re-write - but mostly this is just moving stuff around to improve the reading flow.

The proposal about "samePlaceAs" has been moved to the conclusions [2] as it is clearly _not_ a best practice; but responds to a gap in practice. I also refer to the rather too general definition of schema.org/Place<http://schema.org/Place> ...

Come the finish, I didn't add a property like "colocatedAt" because I felt that these semantics were reasonably well covered by things like geonames:nearby. ... not perfect, but close.

I think I have represented the difference between location and place.

FWIW, the Pull Request is #811 [3] - but you might struggle to see all the material changes as I've moved stuff around.

[1]: http://w3c.github.io/sdw/bp/#entity-level-links
[2]: http://w3c.github.io/sdw/bp/#c-sameplaceas
[3]: https://github.com/w3c/sdw/pull/811

On Sun, 19 Mar 2017 at 16:24 Joshua Lieberman <jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>> wrote:
Hi Frans,

I agree that Place should be understood as a SpatialThing, but not all SpatialThings should be Places. Whether relations between SpatialThings should be named differently than those between SpatialModels such as Geometries is a separate question.

Topics for discussion!

—Josh

On Mar 16, 2017, at 3:53 PM, Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>> wrote:

Hi Josh,

I thought the current proposal is to try to make a schema:samePlaceAs property, with domain and range both being schema:Place. As it is all taking place in schema.org<http://schema.org/>, definitions are not very strict. But  schema:Place could be taken to mean a spatial thing. A future spatial ontology that defines SpatialThing could express some kind of equivalence between space:SpatialThing and schema:Place. So possible properties of SpatialThings, like topological relationships, could also be made applicable to schema:Places. That would mean there is no need for something like 'inSamePlaceAs'. For keys left in a place, spatial relationship 'Within' could be used, for the supernova/black hole example spatial relationship 'Equals' could be used. I must admit that it would be stretching things to say that a bunch of keys is a place. But it is a spatial thing.

Let's suppose that the spatial ontology is finished and that it defines a set of computable topological relationships for geometries and a set of noncomputable (qualitative) topological relationships for spatial things. In the latter set of relationships there will an 'Equals' relationship. Wouldn't that be just what we are looking for? We could then say thing like:

ns1:12345 space:sEquals ns2:London

or

:myKeys space:sWithin :myLeftFrontTrouserPocket

(the prefix 's' in space:sWithin would mean the SpatialThing property is meant, not the Geometry property)


Regards,
Frans






On 16 March 2017 at 14:48, Joshua Lieberman <jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>> wrote:
Hi Frans,

The problem with this use of “Place” is that it is not taken to be synonymous with “location” or “position”. Place is clearly used as a type of geographic feature that people put a name to -> “placename”. So the implication of “samePlaceAs" is that two entities are both places and in fact are the same place feature. It is as if you were saying that the keys are the same feature as the tabletop, which I think is not the intended consequence.

The intent also does not seem to be that two entities share the same precise numerical position. The desired sense appears to be, rather, that one feature / SpatialThing has the same general location as another. I suggested before the two-way relation “collocated”, but “sameLocationAs” has the same implication.

Looking more closely at your example,  I note the expression “in the same place”. So it makes some sense to have a property “inSamePlaceAs” to assert that two entities share a place, but it is still a bit odd not to identify the place being shared. So we would probably also need “inPlace” and “placeFor” for that purpose.

—Josh

On Mar 16, 2017, at 9:03 AM, Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>> wrote:

Hello,

There is a established need for having something like 'samePlaceAs'. I think it is basically what the Subject equality requirement<https://www.w3.org/TR/sdw-ucr/#SubjectEquality> is about. It often happens that data about spatial things are held in different systems that use different models to describe the real world. There is a need to be able to state that different data representations are about the same spatial thing. I think the proposed schema:samePlaceAs could do a decent job at meeting the requirement.

As for limiting the application of the term to geography (mentioned in the London F2F bullet points in the first message of this thread): Why not make it applicable to all things spatial? That way we can express things like 'you probably left your keys in the same place as yesterday' or 'the black hole is in the same place as the supernova that was seen by Kepler in 1604'. The definition of schema:Place seems to strongly hint at geographic places only. Can we assure that samePlaceAs cab be used as a spatial (not just geographical) property?

Regards,
Frans

On 16 March 2017 at 07:02, Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>> wrote:

Just a reminder about the semantics of owl:sameAs if you're not fully across it it - it means properties can be transitively assigned

A sameAs B
A costs X
B isA FrogCollar

means
A isA FrogCollar
B costs X

if this is not _exactly_ what you intend, then dont use owl:sameAs




On Thu, 16 Mar 2017 at 13:16 Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>> wrote:
I agree with Rob. Personally, I still do not see the need for the relation nor do I fully understand what it should be used for that is not covered otherwise; see my previous emails for details. Also, is this going to be an isolated samePlaceAs relation or is there a bigger picture/ontology here? Finally, owl:sameAs is not all that scary and dangerous as it is often being portrait. The problems with owl:sameAs were due to mistakes in its early usage of Linked Data. This was clearly something that had to be addressed and explained in 2010, but it is not that relevant anymore for 2017. OWL:sameAs is one of the most important properties on the Linked Data web.

Cheers,
Jano



On 03/15/2017 05:29 PM, Rob Atkinson wrote:

If you are going to use terms that are not explicitly geographic, but relate to similarity, of matching you would be better off using skos:closeMatch, skos:exactMatch etc.

This also allows you to use skos:broader/narrower with transitive versions, and doesnt preclude using a more nuanced geographical relationship that is a subProperty of skos relationships.

This keeps it within the W3C canon, consistent with other OGC usages of SKOS, and is about _relationships between concepts_

If on the other hand the semantics is explicitly about geographic relationship of related but distinct things, then i would suggest using GeoSPARQL or fall back to general advice about re-use of vocabularies.

whatever vocab falls out as BP in the future should have a specific set of functions it supports - and the nuanced differences between the many similar terms it will require will probably only be understood in terms of what the results of such different functions would yield.

Rob





On Thu, 16 Mar 2017 at 10:31 Stephane Fellah <stephanef@imagemattersllc.com<mailto:stephanef@imagemattersllc.com>> wrote:
Hi,

During OGC Testbed 10, I raised the issue related to the misuse of owl:sameAs.

Here the section relevant (12.3.10.1) from the Engineering Report OGC-14-029<https://portal.opengeospatial.org/files/?artifact_id=59336>


To denote that a place in a gazetteer is the ‘same’ as another one in another gazetteer, the intuitive way is to use the owl:sameAs relation. However owl:sameAs has been misused in many existing linked data due to misunderstanding of the rules of inference defined in OWL. The following paper discusses some of the issues with the misuse of owl:sameAs: http://www.w3.org/2009/12/rdf-ws/papers/ws21.A

A separate property was proposed gaz:sameLocationAs instead. This property is transitive and symmetric, so it will infer the mapping on other instances.


Regards


Stephane


On Wed, Mar 15, 2017 at 2:46 PM, Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>> wrote:
Yes. It's not place / location domain-specific... but the OSi example shows it being used in the way I was thinking for samePlaceAs.

Jeremy

On Wed, 15 Mar 2017 at 18:44, Clemens Portele <portele@interactive-instruments.de<mailto:portele@interactive-instruments.de>> wrote:
Jeremy,

doesn’t "similar to" has a different meaning than "same place/location as"?

Clemens

On 15 Mar 2017, at 18:58, Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>> wrote:

Hi. As agreed during the plenary call on 8-Mar, I have updated BP14 to include a proposal for "samePlaceAs".

However, having just taken a look at an example from data.geohive.ie<http://data.geohive.ie/> (the "Irish example" from [1]), I see use of an alternative to 'samePlaceAs':

<http://open.vocab.org/terms/similarTo> : "Having two things that are not the owl:sameAs but are similar to a certain extent. It is thought of being used where owl:sameAs is too strong but rdfs:seeAlso is too loose."

In the snippet below you can see the relationship stated to a dbpedia resource:

<http://data.geohive.ie/resource/county/2AE19629144F13A3E055000000000001>
      rdf:type <http://ontologies.geohive.ie/osi#County> , geo:Feature ;
      rdfs:label "DUBLIN"@en , "DUBLIN" , "Baile Átha Cliath"@ga ;
      ov:similarTo <http://dbpedia.org/resource/County_Dublin> ;
      ... ;
      .

What do you think?

(side-bar discussions already give +1 votes from Linda and Andrea)

Jeremy

On Tue, 28 Feb 2017 at 21:58 Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>> wrote:
I think we can only point to ad-hoc, and sometimes downright bad practices (owl;sameAs pointing to google maps interface.... )
Need to add this to the "open issues" list IMHO

Rob

On Wed, 1 Mar 2017 at 06:04 Joshua Lieberman <jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>> wrote:
Agreed. There is certainly interest in defining qualitative spatial relationships that can be asserted and inferred even if geometrically they are  imprecise or complex to calculate. However, “Place” is not just a position or even a geometry, but a type of feature. samePlaceAs asserts a much more detailed relationship than “collocated” or “notSpatiallyDisjoint”, which may be closer to what the proposers were considering.

—Josh


On Feb 28, 2017, at 1:53 PM, Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>> wrote:

Hi,


Generally speaking I don't think that a predicate as samePlaceAs would be very useful. As far as I recall, Todd Pehle tried to introduce such predicate a few years ago and it was not really used.

First, we would also need samePersonAs, sameEventAs, and so forth, and secondly, the meaning of samePlaceAs remains unclear. The issue is not only that owl:sameAs is more formal in a mathematical sense (which, as stated in this thread, is not always desired), it also related to URIs to each other by stating that both of them point to the same feature (e.g., the same place in the physical world).  What would samePlaceAs do? If it would relate two places (not URIs), what does it mean for two places to be the same or even similar?

Cheers,
Jano



On 02/28/2017 02:38 AM, Kerry Taylor wrote:
+1

From: Jeremy Tandy [mailto:jeremy.tandy@gmail.com]
Sent: Tuesday, 28 February 2017 2:11 AM
To: Bill Roberts <bill@swirrl.com><mailto:bill@swirrl.com>; SDW WG Public List <public-sdw-wg@w3.org><mailto:public-sdw-wg@w3.org>
Subject: Re: WG discussion: shall we recommend a "samePlaceAs" property?

Thanks Bill.

> Probably a better option would be to propose it to danbri for addition to schema.org<http://schema.org/> as a property for things of type schema:Place ?

You're right that that sounds like a better home.

@danbri: what do you think? (& can you remind us how we might propose this for schema.org<http://schema.org/>'s consideration)

Thanks. Jeremy


On Mon, 27 Feb 2017 at 13:43, Bill Roberts <bill@swirrl.com<mailto:bill@swirrl.com>> wrote:
I support creating a samePlaceAs relation. As well as an IANA link relation, can we have a URI for it to allow use in RDF?

Possibly related, I see in BP10 that we refer to ongoing work to update GeoSPARQL - what's the status of that? Would this property/relation make sense as part of the new GeoSPARQL? Maybe the deliberate vagueness of 'samePlaceAs' might not fit well with the otherwise generally precise geosparql relationships.

Probably a better option would be to propose it to danbri for addition to schema.org<http://schema.org/> as a property for things of type schema:Place ?
Received on Saturday, 6 May 2017 07:23:12 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 6 May 2017 07:23:13 UTC