Re: Agenda for Best Practice sub-group, 14:00UTC 1-June-2016

Hello all,

GeoSPARQL defines three core entities: Feature, SpatialObject and Geometry.
However, in my (possibly too naive) view we only need two core concepts:

   1. spatial things: (something like: things that have some kind of
   spatial presence, and that can have spatial relationships)
   2. geometry: (something like: an ordered set of n-dimensional points,
   can be used to model the spatial presence of a spatial thing)

Is there really a need to have a third concept (Feature)? If the world
could manage with two core concepts, that would be preferable, wouldn't it?

Regards,
Frans


2016-06-02 17:54 GMT+02:00 Joshua Lieberman <jlieberman@tumblingwalls.com>:

> Simon, Matt, et al,
>
> I’m struggling a bit with this right now. Theoretically, spatial
> relationships can only be computed / tested between geometries. Features
> are discerned Things in the world that don’t necessarily have spatial
> representations and so it makes sense that they are not themselves spatial
> objects. Features and geometries can be disjoint whether or not feature is
> a spatial object, but it gets awkward to make features disjoint from all
> other spatial objects (e.g. address, geographic name, region) if features
> are also spatial objects.
>
> [Topological relationship creation also requires topological elements,
> although there is a question in my mind whether those elements are directly
> spatial spatial objects or an algebraic reduction of certain spatial
> relationships. It is related to the dimensionality issue, since topo
> elements are distinguished by dimension. There is also a question in my
> mind whether features and topo elements have to be disjoint as features and
> geometries are or whether a road centerline can also be a topo edge.]
>
> Conceptually, though, one would like to express relationships between
> features themselves. For example, I would (very much) like to assert /
> infer / query that one hydrological catchment (a portion of a landscape) is
> inside of another one, not that one possible geometric representation of
> one catchment is interior to one possible geometric representation of the
> other catchment.
>
> It seems that we can relate the two with a property chain, so that a
> relationship between geometries implies a relationship between the
> features, but does it make sense to use the same relationships for both if
> feature is not a spatial object? Alternatively, we could create “feature
> relationships”, e.g. gfInside for inside:
>
> SubObjectPropertyOf(
>    ObjectPropertyChain( :hasGeometry ehInsite [ owl:inverseOf :hasParent]
> )
>    :gfInside
>  )
>
> In the end, I think we want to enable people to form the assertions that
> make sense to them, but also maximize the possibilities for query and
> inference. So I’m inclined towards creating feature-specific relations,
> some of which can be inferred from spatial object relations. Thoughts?
>
> —Josh
>
> On Jun 1, 2016, at 9:49 PM, simon.cox@csiro.au wrote:
>
> “Regional Shape” and “Regional Area” are both a bit iffy:
> “area” and “region” are approximate synonyms;
> “shape” sounds like just the outline.
>
> *From:* Joshua Lieberman [mailto:jlieberman@tumblingwalls.com
> <jlieberman@tumblingwalls.com>]
> *Sent:* Wednesday, 1 June 2016 11:23 PM
> *To:* matthew perry <matthew.perry@oracle.com>
> *Cc:* public-sdw-wg@w3.org
> *Subject:* Re: Agenda for Best Practice sub-group, 14:00UTC 1-June-2016
>
> Matt,
>
> Thanks for giving us a perspective on the current form of GeoSPARQL. Your
> point about qualitative relations is well taken. This was discussed fairly
> extensively last summer at the Vespucci Institute, but we discovered that
> most of the relations of interest still require at least some spatial
> characterization of the feature, at least a regional dimensionality. For
> example, New York inside of United States presumes that the U.S. is at
> least a 2-dimensional region. The relation “along” requires that the object
> feature have an elongation in at least one dimension.
>
> I have been thinking that we should add a subclass of SpatialObject,
> RS_Object (Regional Shape) that provides this regionality to support
> qualitative reasoning. Then we could keep Feature out of SpatialObject and
> still do qualitative reasoning.
>
> <image001.png>
>
> Josh
>
>
> On Jun 1, 2016, at 8:43 AM, matthew perry <matthew.perry@oracle.com>
> wrote:
>
> Hi everyone,
> The Feature subClassOf SpatialObject does seem a bit awkward in
> retrospect. The main idea was that for qualitative spatial reasoning, we
> don't need quantitative geometries. It should be possible to express
> topological relations between features directly (e.g., New York inside
> United States), so we defined SpatialObject as the class of things that can
> have topological relations, and Feature and Geometry are disjoint
> subClasses of SpatialObject.
> Thanks,
> Matt
>
> On 6/1/2016 4:58 AM, Clemens Portele wrote:
>
> Hm, yes, good question. I did not remember that we made geo:Feature a
> geo:SpatialObject in the GeoSPARQL development. I agree with you, from the
> definitions this seems wrong. Perhaps that could be rediscussed, if there
> is a GeoSPARQL revision.
>
> Clemens
>
>
> On 1. Juni 2016 at 10:38:24, Andrea Perego (andrea.perego@jrc.ec.europa.eu)
> wrote:
>
> Hi, Clemens.
>
> On 01/06/2016 8:26, Clemens Portele wrote:
> > If we use 19107 as the basis, a TP_Object is a SpatialObject, too.
> >
> > This is the definition of "topological object" (the TP_Object):
> > "spatial object representing spatial characteristics that are invariant
> > under continuous transformations".
> >
> > The definition of "geometric object" (the GM_Object) is: "spatial object
>
> > representing a geometric set" where geometric set is "a set of points".
> >
> > GeoSPARQL is consistent with this, geo:Geometry is a sub-class of
> > geo:SpatialObject. If we would define xyz:Topology it should be a
> > sub-class of geoSpatialObject, too.
>
> What is unclear to me is why, in GeoSPARQL, feature is made a subclass
> of spatial object.
>
> Putting together the relevant ISO definitions:
> - feature: "abstraction of real-world phenomena" (ISO 19101, 19107,
> 19109, 19156)
> - spatial object: "object used for representing a spatial characteristic
> of a feature" (ISO 19107)
> - geometry (geometric object): "spatial object representing a geometric
> set" (ISO 19107)
>
> Based on them, a feature is not a spatial object - or I'm missing
> something?
>
> Andrea
>
>
> > Clemens
> >
> >
> > On 1. Juni 2016 at 03:37:53, Joshua Lieberman
> > (jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>
> <jlieberman@tumblingwalls.com>) wrote:
> >
> >> Yes, a GM_object instance is generally a geometry, but there can be
> >> other spatial objects such as linear references, addresses,
> >> placenames, etc. I’m pondering now whether TP_Object should also be a
> >> subclass of SpatialObject, but I think it too is a form of spatial
> model.
> >>
> >> “Object” is vague, but possibly less confusing than “model” or
> >> “representation”. The confusion may be a fundamental property of the
> >> GFM, because one first models the worlds as features, then models the
> >> features in turn as spatial objects. Making both feature and geometry
> >> disjoint subclasses of spatial object in GeoSPARQL means, I think,
> >> that SpatialObject really can’t mean anything except a step of removal
> >> from owl:Thing.
> >>
> >> Josh
> >>
> >>> On May 31, 2016, at 9:11 PM, Rob Atkinson <rob@metalinkage.com.au
> >>> <mailto:rob@metalinkage.com.au> <rob@metalinkage.com.au>> wrote:
> >>>
> >>> it all depends what you mean :-)
> >>>
> >>> I though a GM_object was specifically a geometry. As such it is
> >>> independent of any real world thing - but it can be used as a
> >>> property of a real world thing to define a spatial characteristic.
> >>>
> >>> as such I would say GM_Object and (real world thing) are disjoint.
> >>>
> >>> What I dont really understand is what a Spatial Object is, except it
> >>> seems to declare that Egenhofer and other spatial operations can be
> >>> supported on either GM_Object or GF_Feature.{geomproperty}. One
> >>> wonders if a more elegant way of declaring this was possible without
> >>> introducing a very strange abstract notion (and the confusion here I
> >>> think is the evidence for the strangeness)
> >>>
> >>> OTOH running with the geoSPARQL as-is makes sense unless its provably
> >>> broken in terms of the inferences it allows, so I'll just get over my
> >>> distaste of incompatible naming vs. intent.
> >>>
> >>> Rob
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, 1 Jun 2016 at 09:58 Joshua Lieberman
> >>> <jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>
> <jlieberman@tumblingwalls.com>>
> >>> wrote:
> >>>
> >>> I’m questioning whether that is a good idea.
> >>>
> >>>
> >>>
> >>>> On May 31, 2016, at 7:43 PM, simon.cox@csiro.au
> >>>> <mailto:simon.cox@csiro.au> <simon.cox@csiro.au> wrote:
> >>>>
> >>>> In GeoSPARQL SpatialObject is superclass of geometry and spatial
> >>>> feature.
> >>>>
> >>>> -----Original Message-----
> >>>> From: Joshua Lieberman [mailto:jlieberman@tumblingwalls.com
> <jlieberman@tumblingwalls.com>]
> >>>> Sent: Wednesday, 1 June 2016 9:39 AM
> >>>> To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au
> >>>> <mailto:Simon.Cox@csiro.au> <Simon.Cox@csiro.au>>
> >>>> Cc: andrea.perego@jrc.ec.europa.eu
> >>>> <mailto:andrea.perego@jrc.ec.europa.eu>
> <andrea.perego@jrc.ec.europa.eu>;
> >>>> l.vandenbrink@geonovum.nl <mailto:l.vandenbrink@geonovum.nl>
> <l.vandenbrink@geonovum.nl>;
> >>>> frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>
> <frans.knibbe@geodan.nl>;
> >>>> public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>
> <public-sdw-wg@w3.org>
> >>>> Subject: Re: Agenda for Best Practice sub-group, 14:00UTC
> >>>> 1-June-2016
> >>>>
> >>>> Can't SpatialObject be disjoint from GF_Feature? Maybe it's
> >>>> really SpatialRepresentation. Unless we want to call it
> >>>> TransfinitePointSet.
> >>>>
> >>>>> On May 31, 2016, at 6:20 PM, simon.cox@csiro.au
> >>>>> <mailto:simon.cox@csiro.au> <simon.cox@csiro.au> wrote:
> >>>>>
> >>>>> That preserves the 'thing is not a subclass of geometry' axiom,
> >>>>> but misses 'geometry is not a subclass of real-world-thing'.
> >>>>> I don't see how to do that without a subclass of owl:Thing
> >>>>> which is disjoint from GM_Object.
> >>>>>
> >>>>> Simon J D Cox
> >>>>> Research Scientist
> >>>>> Land and Water
> >>>>> CSIRO
> >>>>> E simon.cox@csiro.au <mailto:simon.cox@csiro.au>
> <simon.cox@csiro.au> T +61 3 9545
> >>>>> 2365 M +61 403 302 672
> >>>>> Physical: Reception Central, Bayview Avenue, Clayton, Vic 3168
> >>>>> Deliveries: Gate 3, Normanby Road, Clayton, Vic 3168
> >>>>> Postal: Private Bag 10, Clayton South, Vic 3169
> >>>>> people.csiro.au/C/S/Simon-Cox
> >>>>> <http://people.csiro.au/C/S/Simon-Cox>
> <http://people.csiro.au/C/S/Simon-Cox>
> >>>>> orcid.org/0000-0002-3884-3420
> >>>>> <http://orcid.org/0000-0002-3884-3420>
> <http://orcid.org/0000-0002-3884-3420>
> >>>>> researchgate.net/profile/Simon_Cox3
> >>>>> <http://researchgate.net/profile/Simon_Cox3>
> <http://researchgate.net/profile/Simon_Cox3>
> >>>>>
> >>>>> ________________________________________
> >>>>> From: Joshua Lieberman <jlieberman@tumblingwalls.com
> >>>>> <mailto:jlieberman@tumblingwalls.com> <jlieberman@tumblingwalls.com>
> >
> >>>>> Sent: Wednesday, 1 June 2016 7:12 AM
> >>>>> To: Andrea Perego
> >>>>> Cc: Linda van den Brink; Frans Knibbe; SDW WG
> >>>>> (public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>
> <public-sdw-wg@w3.org>)
> >>>>> Subject: Re: Agenda for Best Practice sub-group, 14:00UTC
> >>>>> 1-June-2016
> >>>>>
> >>>>>> On May 31, 2016, at 10:01 AM, Andrea Perego
> >>>>>> <andrea.perego@jrc.ec.europa.eu
> >>>>>> <mailto:andrea.perego@jrc.ec.europa.eu>
> <andrea.perego@jrc.ec.europa.eu>> wrote:
> >>>>>>
> >>>>>> Dear Linda, dear Frans, dear Josh,
> >>>>>>
> >>>>>> About the agenda item on "spatial ontology", I wonder whether
> >>>>>> we can include here a clarification on the notions of spatial
> >>>>>> object, feature and geometry in GeoSPARQL - in relation to
> >>>>>> ISO, and to our discussion on real-world / spatial things.
> >>>>>>
> >>>>>> In particular:
> >>>>>>
> >>>>>> 1. In GeoSPARQL, feature and geometry are explicitly mapped to
> >>>>>> the corresponding notions in the relevant ISO standards.
> >>>>>> However, the definition of spatial object in GeoSPARQL doesn't
> >>>>>> seem to match to the ISO one ("object used for representing a
> >>>>>> spatial characteristic of a feature" - ISO 19107).
> >>>>>
> >>>>> Yes, it's questionable whether GF_Feature should be considered
> >>>>> a "Spatial Object". In ISO 19109, it's a real-world target of
> >>>>> discourse, that can have properties, including one or more
> >>>>> geometric model representations. I'm tending towards making
> >>>>> GF_Feature an owl:Thing, and leaving GM_Object as a SpatialObject.
> >>>>>>
> >>>>>> 2. What in GeoSPARQL corresponds to real-world / spatial things?
> >>>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>>> Andrea
> >>>>>>
> >>>>>>
> >>>>>> On 30/05/2016 10:22, Linda van den Brink wrote:
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> The Best Practice sub-group telecon agenda is at
> >>>>>>> https://www.w3.org/2015/spatial/wiki/Meetings:BP-Telecon20160601.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Main agenda:
> >>>>>>>
> >>>>>>> * Progress of BP Narrative 2
> >>>>>>>
> >>>>>>> * Spatial ontology
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> See you all on Wednesday! (else please advise any regrets).
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Linda
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Andrea Perego, Ph.D.
> >>>>>> Scientific / Technical Project Officer European Commission DG JRC
> >>>>>> Institute for Environment & Sustainability Unit H06 - Digital
> >>>>>> Earth &
> >>>>>> Reference Data Via E. Fermi, 2749 - TP 262
> >>>>>> 21027 Ispra VA, Italy
> >>>>>>
> >>>>>> https://ec.europa.eu/jrc/
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> <SpatialObject.png><SpatialObject.png>
> >>
>
> --
> Andrea Perego, Ph.D.
> Scientific / Technical Project Officer
> European Commission DG JRC
> Institute for Environment & Sustainability
> Unit H06 - Digital Earth & Reference Data
> Via E. Fermi, 2749 - TP 262
> 21027 Ispra VA, Italy
>
> https://ec.europa.eu/jrc/
>
>
>
>
>
>
>