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

It seems to me that we should only be concerned about disjointness of sets
of things if those things are both of the same super-class.

geometry and topology are perhaps more akin to interfaces - and not
mutually exclusive. This is suggested by the ISO definition of these as
having operations rather than attributes as properties. I think the UML
convention is throwing us here, even though UML is able to express
interfaces.

So a Feature can support geometry and topology operations - but
implementations need to be able to support a refusal based on inadequate
knowledge without assuming a specific result - not able to compute
intersection is different from not intersecting.  This is kind of the way
people build things - and there is legacy content we need to describe this
way, notwithstanding the purist model we may prefer.

of course there is not one such "GM_Interface" - there are many sub-types
based on the underlying geometry representations appropriate for a
phenomenom being measured.


so a GM_Object  supports a fixed set of "GM_Interface" subclasses  -
whereas a Feature may have one or more geometry representations - and could
inherit the relevant geometry and topology.  My gut feeling here is we need
to support a declarative approach where a Feature Type definition may
specify the interfaces it is intended to support, and using the open world
assumption geometry properties can be attached, and any given feature
instance may be asked, and politely refuse.

This means we need to work through the interactions on Web with a client
interrogating any of  Feature instance, a Feature set and a Feature Type
 (and possibly services? hopefully these are operations on a FeatureSet and
dont need separate descriptions).  What is the minimum common vocabulary
needed for a client to understand what geometry and topology operations are
available (i.e. just canonical names and semantics of links to descriptions
of these - rather than the ontology describing the operations)

I _think_ the ISO geometry model can be used in this way. I would still
break it up into a RDFS, SKOS and OWL views that allow different levels of
expressivity - unless or until someone is able to declare the ISO ontology
versions "safe" against a particular Discription Logic (I defer to the
experts on the details! I think I understand the functional implications
however).  Hence, we perhaps do need to adopt or define a basic "spatial
ontology"

I also _think_ that we can either use relevant GeoSPARQL modules to define
such links - or as a canonical target of such links. Perhaps things like
the way Spatial Object/GM_Feature are related means its not safe to
directly using them - and we need a lighter, safer connecting ontology that
allows us to describe how the properties of an object participate in
geometric and topology operations?

Rob




On Fri, 3 Jun 2016 at 01:59 Joshua Lieberman <jlieberman@tumblingwalls.com>
wrote:

> That would be
>
> SubObjectPropertyOf(
>    ObjectPropertyChain( :hasGeometry :Inside [ owl:inverseOf :hasGeometry]
> )
>    :gfInside
>  )
>
>
> On Jun 2, 2016, at 11:54 AM, Joshua Lieberman <
> jlieberman@tumblingwalls.com> wrote:
>
> 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/
>
>
>
>
>
>
>
>