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

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

From: Jeremy Tandy <jeremy.tandy@gmail.com>
Date: Mon, 27 Feb 2017 15:10:50 +0000
Message-ID: <CADtUq_0QAQ=sat4opUtNjLN29DrK=grVx7Ak4vVK=6cUtKtNRw@mail.gmail.com>
To: Bill Roberts <bill@swirrl.com>, SDW WG Public List <public-sdw-wg@w3.org>
Thanks Bill.

> Probably a better option would be to propose it to danbri for addition to
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's consideration)

Thanks. Jeremy


On Mon, 27 Feb 2017 at 13:43, Bill Roberts <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 as a property for things of type schema:Place ?
>
>
>
> On 27 February 2017 at 11:44, Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>
> Hi - for this sprint in development of the Best Practice document, we're
> updating BPs about "linking" and "vocabularies" ...
>
> On multiple previous occasions (most recently the London F2F) we've
> mentioned that we should propose a "samePlaceAs" property. In essence, I
> think we see this as a subjective statement (that a human might make)
> rather than a mathematical / topological statement, matching on the spatial
> characteristics only.
>
> This addresses the concerns about the VERY restrictive owl:sameAs. At
> TPAC2016, @clemens said that a "relaxed relationship is better [for
> cross-referencing identifiers] (e.g. samePlaceAs) … but if you _can_ state
> owl:sameAs then you should do so … " [from my notes]
>
> We said at TPAC2015 "samePlaceAs would be a 'social relationship' - based
> on people's perception".
>
> The domain and range should both be "spatial things" (which definition of
> spatial thing do we refer to - the new one coming from @josh's work or
> w3cgeo:SpatialThing?
>
> We're looking to resolve this question BEFORE the Delft F2F.
>
> WG members: what do you think?
>
> Many thanks, Jeremy
>
> further notes below:
>
> ---
>
> My notes from the most recent discussion during London F2F are here:
>
>    - "samePlaceAs"
>    - it would be an IANA link relation identifier
>
>
>    - equivalence at a geographical level - without a formal definition of
>       that equivalence
>       - geography related
>       - don't express as a sub-property of, for example, "so:matches" [
>       https://files.ifi.uzh.ch/ddis/iswc_archive/iswc/pps/web/iswc2010.semanticweb.org/pdf/261.pdf]
>       … we're only indicating that the _spatial_ properties match ... and
>       property hierarchies just get complicated to 95% of humans
>       - not a mathematical statement (like the topological relationships)
>       - avoid any "mereological" confusion [ :) ]
>       - nearby? (& other fuzzy relationships) ... same-place-as is _so_
>       common that we'll deal with it as a special case and _not_ cover these
>       other spatial relationships for now
>       - which ontology? IANA Link Relations
>    - ... not used today- so not a _best_ practice
>    - ... assert as a [recommended] approach to resolve problems we see in
>    evidence today- especially regarding incorrect use of owl:sameAs
>
> ---
>
> And back on the BP call on 9-Nov we said:
>
> *jtandy:* Another aspect to discuss is the reuse of identifiers ("to keep
> the global graph intact").
>
> ... But to be able to add additional information and make it retrievable
> it requires a new identifier with a sameAs-like link to the "known
> identifier"
>
> ... "samePlaceAs"?
>
> *eparsons:* samePlaceAs sounds restrictive
>
> *jtandy:* agrees, we want to avoid the strong nature of sameAs
>
> *ByronCinNZ:* likes the idea, very geographic statement. In which
> ontology would this reside?
>
> *ClemensPortele:* I think we said it would be an IANA link relation
> identifier
>
> *jtandy:* As it does not exist yet, we cannot claim it is a "best
> practice"
>
> *eparsons:* I think this problem will be hard to avoid, but it could be
> described as a way to address the issue
>
> *ChrisLittle:* worried about "samePlaceAs". How does it fit with the
> algebra of polygons?
>
> *jtandy:* we don't want to be too specific
>
> ... ... at TPAC we had a discussion about the well-defined topological
> relationships
>
> *eparsons:* to get something done quickly we should try to keep it simple
>
> ... ... relationships could be tackled later
>
> *jtandy:* so we agree that samePlaceAs is not intended as a mathematical
> statement
>
> <*ClausStadler_*>
> https://files.ifi.uzh.ch/ddis/iswc_archive/iswc/pps/web/iswc2010.semanticweb.org/pdf/261.pdf
>
> <*ClausStadler_*> "so:matches Two URIs refer to possibly distinct things
> that share all the prop- erties needed to substitute for each other in some
> graphs. Th is property is symmetric but not necessarily reflexive.
> so:matches is a super-property of so:identical ."
>
> *ByronCinNZ:* agrees, and this is probably the most important of the
> topological relationships
>
> *ClausStadler_:* Explains the paper and "so:matches" reference (see above)
>
> *jtandy:* yes, there is overlap. we want to focus on the spatial match.
>
> *ClausStadler_:* could be a sub-property
>
> *jtandy:* worried on nesting, maybe it makes it overcomplicated
>
> I agree with the concern
>
> <*eparsons*> +1
>
> *eparsons:* worried about complication, too
>
> <*AndreaPerego*> +1
>
> *ByronCinNZ:* should be a top-level relationship
>
>
>
Received on Monday, 27 February 2017 15:17:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 27 February 2017 15:17:15 UTC