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

Re: SpatialThing and feature (again)

From: Jeremy Tandy <jeremy.tandy@gmail.com>
Date: Sun, 07 May 2017 07:40:37 +0000
Message-ID: <CADtUq_1qg9Vi_K-okRn=WNvE6w-z4aeRVJWjQ+QP+mRP7Cuy6Q@mail.gmail.com>
To: Joshua Lieberman <jlieberman@tumblingwalls.com>, andrea.perego@ec.europa.eu
Cc: Clemens Portele <portele@interactive-instruments.de>, matthew.perry@oracle.com, public-sdw-wg@w3.org
> We are adopting a WWW practice that it is unnecessary to make a formal
assertion that a SpatialThing as an information entity abstracts and
therefore stands in for a physical entity

+1 to Josh's comment.

I recall from TPAC in Sapporo (way back in 2015) that Sir Tim made the
comment "it turns out that no one really cares about the difference between
the electronic vCard and the person the vCard is identifying [...]" and
went on to suggest the splitting the abstraction and the real-world
phenomenon is somewhat academic.

I think we probably say enough about "abstractions" and "real world things"
already in the section that introduces Spatial Things [1]. And, in
particular, we state:

> The concept of “spatial thing
<http://w3c.github.io/sdw/bp/#dfn-spatial-thing>” is considered to include
*both* "real-world phenomena" *and* their abstractions (e.g. “feature
<http://w3c.github.io/sdw/bp/#dfn-feature>” as defined in [ISO-19101
<http://w3c.github.io/sdw/bp/#bib-ISO-19101>]). Furthermore, we treat it as
inclusive of other commonly used definitions; e.g. *Feature* from [NeoGeo
<http://w3c.github.io/sdw/bp/#bib-NeoGeo>], described as “A geographical
feature, capable of holding spatial relations”

The important thing is that we all agree that Spatial Thing is disjoint
from Geometry. No arguments there I think.

So I think that I'll leave things as they are, and see what comments arise
from wider review.

Jeremy

[1]: http://w3c.github.io/sdw/bp/#spatial-things-features-and-geometry

On Sat, 6 May 2017 at 22:36 Joshua Lieberman <jlieberman@tumblingwalls.com>
wrote:

> We may be overthinking, and over-asserting here. The use of the term
> “abstraction” is very limited in 19109. Since any information artifact
> cannot completely embody a physical entity, it must be an abstraction in
> the sense of simplification.
>
> I believe that we are not actually asserting that SpatialThing is both an
> information abstraction and the target physical entity itself. We are
> adopting a WWW practice that it is unnecessary to make a formal assertion
> that a SpatialThing as an information entity abstracts and therefore stands
> in for a physical entity. In the same way, someone may publish a Web page
> about London (UK) and not have to put something in the header asserting
> that London is in fact what the Web page is about. The existence of a
> SpatialThing as an information entity indicates that it represents the
> physical entity that it abstracts. We (contend that we) do not need a
> separate assertion of that connection. Generally we use the same name or
> identifier for both the SpatialThing and in “discoursing” about the
> physical entity and that suffices to connect them.
>
> It is actually more confusing in many, many ways to contend that a
> SpatialThing, as a concept and information entity, is also the physical
> entity itself. So I suggest that  "Spatial Thing ≡ geosparql:Feature” is
> really what we want. As in regular GIS, or on the Web, any ambiguity as to
> what real world phenomenon is being abstracted should be dealt with by
> documenting the process of abstraction, not by confusing the two with one
> concept.
>
> —Josh
>
>
> On May 6, 2017, at 3:53 PM, andrea.perego@ec.europa.eu wrote:
>
> About your footnote, Clemens:
>
> >*) I am ignoring here for simplicity that spatial thing includes not only
> the abstraction, but also the real-world entity.
>
> I think this is fundamental point. In the BP doc we have been
> programmaticaly using "spatial thing" for both real world phaenomena and
> their abstractions. And we have made it clear in many places that a feature
> (as per ISO 19109 and GeoSPARQL) is an abstraction of a real world
> phaenomenon - i.e., it is a subclass of "spatial thing".
>
> If we just say here that "Spatial Thing" ≡ geosparql:Feature, I see a risk
> of confusing readers (besides introducing inconsistency).
>
> To address this, we could at least add a sentence in the relevant place(s)
> of the note to re-state that "spatial things" include also real-world
> phaenomena.
>
> E.g., we could:
>
> 1. revise the first paragraph:
>
> [[
> Although we have borrowed the description of spatial thing from
> [W3C-BASIC-GEO], the formal [RDF-SCHEMA] definition of w3cgeo:SpatialThing
> doesn't quite suit our purpose as there is the potential for confusion
> about whether it is disjoint from geometry. The definition of
> geosparql:Feature, which is derived from the [ISO-19109] definition of
> Feature, is a better semantic fit for spatial thing as it is explicity
> specified as being disjoint from geosparql:Geometry.
> ]]
>
> as - re-using Clemens's note ;) :
>
> [[
> Although we have borrowed the description of spatial thing from
> [W3C-BASIC-GEO], the formal [RDF-SCHEMA] definition of w3cgeo:SpatialThing
> doesn't quite suit our purpose as there is the potential for confusion
> about whether it is disjoint from geometry. The definition of
> geosparql:Feature, which is derived from the [ISO-19109] definition of
> Feature, is a better semantic fit for spatial thing as it is explicity
> specified as being disjoint from geosparql:Geometry (for simplicity, here
> we are ignoring that, differently from geosparql:Feature, spatial things
> include not only the abstraction, but also the real-world entity).
> ]]
>
> 2. revise the last paragraph:
>
> [[
> So in summary, it's safer to say that our spatial thing equates to
> geosparql:Feature, and that it is not the same as w3cgeo:SpatialThing.
> ]]
>
> as:
>
> [[
> So in summary, it's safer to say that our spatial thing equates to
> geosparql:Feature, and that it is not the same as w3cgeo:SpatialThing -
> with the important difference that spatial things include also real world
> phenomena.
> ]]
>
>
> Cheers,
>
> Andrea
>
> ----
> Andrea Perego, Ph.D.
> Scientific / Technical Project Officer
> European Commission DG JRC
> Directorate B - Growth and Innovation
> Unit B6 - Digital Economy
> Via E. Fermi, 2749 - TP 262
> 21027 Ispra VA, Italy
>
> https://ec.europa.eu/jrc/
>
> ----
> The views expressed are purely those of the writer and may
> not in any circumstances be regarded as stating an official
> position of the European Commission.
>
> ------------------------------
> *From:* Clemens Portele [portele@interactive-instruments.de]
> *Sent:* 02 May 2017 18:18
> *To:* Jeremy Tandy
> *Cc:* Matthew Perry; public-sdw-wg@w3.org
> *Subject:* Re: SpatialThing and feature (again)
>
> Hi Jeremy,
>
> I see your point and I guess you are right. I still think that the
> description is quite fuzzy and it is not obvious that "anything with
> spatial extent" is not meant to be narrower than the ISO 19109 concept of a
> feature *), which is partly why I started the thread. But the text is quite
> challenging for new readers already due to all the legacy of terms and
> definitions that are not well aligned and adding more nuanced discussion is
> probably not helpful. So I am ok with leaving it as it is. We always
> reference back to the email thread ;)
>
> Thanks,
> Clemens
>
> *) I am ignoring here for simplicity that spatial thing includes not only
> the abstraction, but also the real-world entity.
>
>
> On 2. May 2017, at 17:52, Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>
> Hi - I'm just in the process of updating the BP document to reflect our
> discussion.
>
> Clemens suggested that we explicitly call out things like "home loan" as
> an example of a spatial thing. Having read through the text, it feels like
> this is a fairly nuanced statement that A/ may lead to more confusion,
> unless B/ we take time to describe why something that appears to not have
> spatial extent really does.
>
> Personally, I'd rather leave this complexity out.
>
> What do you think? (especially Clemens)
>
> Jeremy
>
> On Tue, 25 Apr 2017 at 12:58 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>
>> Thanks all. I can amend the BP doc to clarify as per Simon's proposal.
>> Jeremy
>> On Tue, 25 Apr 2017 at 12:54, Matthew Perry <matthew.perry@oracle.com>
>> wrote:
>>
>>> That looks correct to me as well.
>>> Thanks,
>>> Matt
>>>
>>> On 4/25/2017 12:29 AM, Joshua Lieberman wrote:
>>>
>>> Yes, I think.
>>>
>>> On Apr 25, 2017, at 12:19 AM, <Simon.Cox@csiro.au> wrote:
>>>
>>> Ø  ... and reaffirm that _we_ see Feature (SpatialThing) as disjoint
>>> from geometry, but that this might be at odds with some people's
>>> interpretations. As Josh says: "we can’t really say there is a mapping from
>>> W3C Basic Geo to/from anything based on 19109."
>>>
>>> We need to be very clear here:
>>>
>>> geosparql:SpatialObject         includes both features and geometries –
>>> they are disjoint subclasses
>>> w3cgeo:SpatialThing               is superclass of w3cgeo:Point, but
>>> (OWA) potentially also has a class of features as another subclass
>>> (disjoint from Point) – so this could all be OK and consistent (but we
>>> mustn’t credit w3cgeo as having been the result of much deep thought).
>>>
>>> So where does bp:SpatialThing fit in? Looks to me like the key thing is
>>> to point out that it is **not** the same as w3cgeo:SpatialThing,
>>> because the latter includes geometries. But it **is** the same as
>>> geosparql:Feature, which is disjoint from Geometry.
>>>
>>> Simon
>>>
>>> *From:* Clemens Portele [mailto:portele@interactive-instruments.de
>>> <portele@interactive-instruments.de>]
>>> *Sent:* Tuesday, 25 April, 2017 01:27
>>> *To:* Jeremy Tandy <jeremy.tandy@gmail.com>
>>> *Cc:* Josh Lieberman <jlieberman@tumblingwalls.com>; Cox, Simon (L&W,
>>> Clayton) <rob@metalinkage.com.au>; Andreas Harth <harth@kit.edu>;
>>> public-sdw-wg@w3.org
>>> *Subject:* Re: SpatialThing and feature (again)
>>>
>>> Hi Jeremy,
>>>
>>> I think we should add a green note in chapter 5 to explain how the
>>> "anything with spatial extent" definition is consistent with features like
>>> a "home loan" in a spatial dataset as it is not obvious.
>>>
>>> Clemens
>>>
>>>
>>>
>>> On 21. Apr 2017, at 17:33, Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>>>
>>> Hi all-
>>>
>>> I've spent more than a few minutes parsing through the email chain.
>>>
>>> 1/ Clemens' summary (from mid way though) suggests that (a) ISO 19109
>>> Feature is [also] a geosparql:Feature, (b) these may or may not have
>>> attached geometry properties
>>> 2/ Andrea suggests that "only [those] ISO 19109 Features [with spatial
>>> extent] are Spatial Things according to the BP definition" - but Josh
>>> suggests we're using "spatial extent" as a shorthand for "real-world
>>> phenomena", and that "making the connection [between abstraction and
>>> real-world thing] formal and explicit is not necessary for Web purposes"
>>>
>>> So I'm seeing that there's no inconsistency to explain away.
>>>
>>> Please confirm that I've read this OK. Apologies if I've missed the
>>> point!
>>>
>>> And, talking of Points ... I see that there is potential for confusion
>>> regarding the "Feature/Geometry amalgam".
>>>
>>> We could insert a "green note" into the BP document identifying the
>>> potential for inconsistency - as defined in Andreas' example:
>>>
>>> > Because a w3cgeo:SpatialThing has lat/lon, some people might equate a
>>> w3cgeo:SpatialThing with a geosparql:Geometry.
>>> >
>>> > Because the w3cgeo:SpatialThing is an instance of foaf:Person,
>>> some other people find it natural to equate the w3cgeo:SpatialThing with a
>>> geosparql:Feature.
>>> >
>>> > Based on data from different source we now have an
>>> inconsistency, because the w3cgeo:SpatialThing is an instance of both
>>> geosparql:Feature and geosparql:Geometry, which are defined as disjoint.
>>>
>>> ... and reaffirm that _we_ see Feature (SpatialThing) as disjoint from
>>> geometry, but that this might be at odds with some people's
>>> interpretations. As Josh says: "we can’t really say there is a mapping from
>>> W3C Basic Geo to/from anything based on 19109."
>>>
>>> Am I summarising correctly?
>>>
>>> Thanks, Jeremy
>>>
>>>
>>> On Fri, 21 Apr 2017 at 15:33 Joshua Lieberman <
>>> jlieberman@tumblingwalls.com> wrote:
>>>
>>> Ah, I had thought that the domains of geo:lat and geo:lon were
>>> geo:Point, since that is what is generally referred to in narrative. If a
>>> resource carrying the lat/lon properties implies that it is a SpatialThing,
>>> not only the Point subclass, adding the properties doesn’t resolve any
>>> feature / geometry ambiguity. Your equivalences are certainly possible, but
>>> geosparql doesn’t / shouldn’t support adding direct positions to features,
>>> so entailing something with geo:lat and geo:lon as geosparql:SpatialObject
>>> rather than geosparql:Geometry doesn’t really work. And if we can’t derive
>>> that use of geo:lat and geo:lon imply both a feature and a geometry, than
>>> Andrea is correct that we can’t really say there is a mapping from W3C
>>> Basic Geo to/from anything based on 19109. That may be unfortunate.
>>>
>>> —Josh
>>>
>>>
>>> On Apr 20, 2017, at 8:38 PM, simon.cox@csiro.au wrote:
>>>
>>>
>>> Hold on a moment folk – does this problem really exist?
>>>
>>> I’m looking at http://www.w3.org/2003/01/geo/wgs84_pos#
>>> <http://www.w3.org/2003/01/geo/wgs84_pos> which is the RDF/XML
>>> serialization of W3C Basic Geo.
>>> Here’s the key axioms.
>>>
>>> geo:lat   rdfs:domain geo:SpatialThing .
>>> geo:long rdfs:domain geo:SpatialThing .
>>> geo:Point rdfs:subClassOf geo:SpatialThing .
>>>
>>>
>>>
>>> And from
>>> http://schemas.opengis.net/geosparql/1.0/geosparql_vocab_all.rdf
>>> since
>>>
>>> geosparql:Geometry rdfs:subClassOf geosparql:SpatialObject .
>>>
>>> then it looks to me like
>>>
>>> geo:SpatialThing owl:equivalentClass geosparql:SpatialObject .
>>> geo:Point rdfs:subClassOf geosparql:Geometry .
>>>
>>> and there is no inconsistency. Appearance of geo:lat and geo:long
>>> properties only entails that it is a geosparql:SpatialObject, so can be
>>> either a Feature or a Geometry.
>>>
>>> Am I missing something?
>>>
>>> Simon
>>>
>>> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au
>>> <rob@metalinkage.com.au>]
>>> *Sent:* Thursday, 20 April, 2017 06:24
>>> *To:* Joshua Lieberman <jlieberman@tumblingwalls.com>; Andreas Harth <
>>> harth@kit.edu>
>>> *Cc:* public-sdw-wg@w3.org
>>> *Subject:* Re: SpatialThing and feature (again)
>>>
>>>
>>> This could also be resolved by thinking of geo:long as a property that
>>> can entail a geometry property of the feature - maybe its even a geometry
>>> property in the same way that a 2D point is a partial representation of a
>>> 3D location?
>>>
>>> Rob
>>>
>>> On Thu, 20 Apr 2017 at 02:38 Joshua Lieberman <
>>> jlieberman@tumblingwalls.com> wrote:
>>>
>>> Andreas,
>>>
>>> It may not be worth delving too deeply into this...
>>>
>>> W3C Basic Geo defines SpatialThing and then subclasses it to Point
>>> carrying the lat and long properties. No one defines their own
>>> SpatialThings, they simply add geo:lat and geo:long properties to some
>>> resource X to turn it into “also a Point”, in other words “also a
>>> geometry”. This implies for most users but does not actually assert that
>>> resource X is both a feature and a geometry. One could form a subclass of
>>> geo:SpatialThing that was actually disjoint with geo:Point or other
>>> geometry,  which would then align more-or-less with iso geosparql:Feature,
>>> hence the assertion that some geo:SpatialThings are geosparql:Features.
>>> This is largely hypothetical.
>>>
>>> There is a similar property in GeoRSS, the point(pos) property, but this
>>> doesn’t try to create one feature-geometry amalgam. It’s simply a shortcut
>>> for a longer expression that identifies some resource as a _Feature with a
>>> “where" object property connecting to a Point geometry resource.
>>>
>>> It might be most accurate to say that your example of using W3C Basic
>>> Geo to represent feature and geometry in the “style” of geosparql is
>>> actually the longhand of what people are trying to do when they do use
>>> geo:lat and geo:long, identifying a resource as a real world feature and
>>> giving it a closely allied point geometry.
>>>
>>> —Josh
>>>
>>> > On Apr 19, 2017, at 11:54 AM, Andreas Harth <harth@kit.edu> wrote:
>>> >
>>> > Hi,
>>> >
>>> > On 04/19/17 13:29, Joshua Lieberman wrote:
>>> >> My understanding based on the limited documentation is that
>>> w3cgeo:SpatialThing covers both features and models such as geometries, so
>>> >
>>> > that's my understanding too.  With the W3C WGS84 vocabulary you can
>>> write:
>>> >
>>> > @prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#
>>> <http://www.w3.org/2003/01/geo/wgs84_pos>> .
>>> > @prefix : <#> .
>>> >
>>> > :bob a geo:SpatialThing ; geo:lat "52.5196143" ; geo:long "13.4065603"
>>> .
>>> >
>>> > So the resource with the URI :bob is both the "feature" and the
>>> "geometry".
>>> >
>>> > In other representations (NeoGeo, GeoSPARQL), you would identify two
>>> separate
>>> > resources:
>>> >
>>> > @prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#
>>> <http://www.w3.org/2003/01/geo/wgs84_pos>> .
>>> > @prefix : <#> .
>>> >
>>> > :bob a :Feature ; :geometry _:bnode .
>>> > _:bnode a :Geometry , geo:Point ; geo:lat "52.5196143" ; geo:long
>>> "13.4065603" .
>>> >
>>> > The URI :bob now represents the "feature" resource, and the blank node
>>> _:bnode
>>> > represents the "geometry" resource.
>>> >
>>> > I wouldn't know how to write OWL axioms to map the two modeling
>>> choices though.
>>> >
>>> > Best regards,
>>> > Andreas.
>>> >
>>> >
>>>
>>>
>>>
>>>
>
>
>
Received on Sunday, 7 May 2017 07:41:24 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 7 May 2017 07:41:25 UTC