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

I still struggle with the concept of operations on a feature independent of
its spatial properties (geo or topo).  in the ISO model there is a
distinction between an operation and an attribute - and I cant help feeling
this is what we need here.

I have tried to unpack this from a pragmatic implementers perspective,
where the implementer is being gently introduced to the increased
expressivity that semantic models offer, in the context of terms they are
familiar with (from Web or Spatial rather than Semantic background). That's
a perspective I can best relate to :-). When I do I see there are few steps
to join the threads - and its just complex enough that we can feel we are
on the same page but keep struggling to join the dots in just a couple of
steps.

So - its a spatial feature if it support one or more spatial operations. If
it has one or more spatial properties (geo or topo) then it supports one or
more operations.  If we had a shallow hierarchy (+1) of operations with an
abstract root element that covered both spatial and topo relations, then
cant we just declare its a spatial feature if one of its properties
supports some subclass of that root relation?

This seems a lot more intuitive to me than trying to get the lay person to
understand the difference between a feature and a geometry, and a feature
implemented using a geometry data model in practice. Is a geometry a data
type, and when implemented as an instance of that with an identifier thats
just an implementation detail peculiar to platforms that support re-use of
data values?

If you want to declare that two features share the same geometry element -
one way would be to declare that the two feature instances are owl:sameAs -
and hence share properties (if they are just two features with different
spatial representations of the same thing this is true. If they are
different features, then a relationship between the two features that
specifies that one feature defines the geometry of the related feature as a
result may be more meaningful that the two "just happening to have the same
geometry"  The final case I can imagine is if we generalise the coordinates
so much that we can assume that two features with different geometry
concepts share the same coordinate set instances - then we should not say
they are the same geometry (as they may have different metadata about how
they came to be generalised) - but share the same coordinate data - again I
think thats an implementation compactness detail - not a model.

So - concrete proposal:

declare a spatialProperty, whose range is a geom or topo type - lets say
SpatialModel - including geom, topo relationships, geom relationships,
linear refs
define subproperties of spatialProperty for concepts in common use
(centroid, bounding box, displaypoint etc) and allow these to be extended
define equivalence between canonical spatialProperty sub-types and terms in
other vocabularies (in an ancillary module)
declare a spatialOperation property whose range is an element of a shallow
hierarchy of spatial and topo operations (with lay-person understable
labels)
declare what spatialOperations each geom or topo type supports
define a SpatialRelationship as a subclass of SpatialModel that allows
metadata about a spatial relationship to be attached - i.e. is it asserted,
inferred, calculated etc
declare that a Thing with one or more spatialProperties is a SpatialThing
give SpatialThing a label "Feature" ( using skos:altLabel ?)
give SpatialThing a rdfs:description referencing the ISO Feature model and
that SpatialThing is intended to implement it and why its not called Feature
declare that SpatialThing has equivalentClasses to feature definitions in
other vocabs (but not in the core module)
if required use entailment from the set of spatialProperty values of a
feature to define the set of spatialOperation properties a Feature has
if required use entailment from the set of spatialProperty values of a
feature to define the set of spatialProperties of type SpatialRelationship
properties a Feature has

thus - if the spatialOperation is not present it doesnt imply anything
(open world) - but the model allows a client to find out exactly what it
does support (client does the entailment using the ontology)

spatialOperation can also be used in semantic descriptions of services that
perform such operations.

This meets a set of requirements that we seem skirt around but do not
define:
1) Formally define relationship to Feature terminology without forcing it
on casual users who find machine readable artefacts in the wild - i.e.
developers looking at data
2) Have a simplifying generalisation for different types of spatial
property, instead of having to repeat a treatment for geometries across all
of a potentially hard to enumerate set of spatial concepts.
3) bind the behaviour (affordances) of a feature to its spatialProperties
4) allow multiple representations of a feature to co-exist (if you push
details of a single geometry into the feature as properties, then what
happens if you have more than one geometry - you need to have maps of
property values to geometry properties, or a way of defining which one get
priority, and metadata about which one was used etc etc)
5) support asserted, inferred and calculated relationships
6) provide a baseline terminology of the most common spatial concepts
7) provide an extensible means to map to other vocabularies without
importing them and inheriting axioms we dont want to.
8) provide a simple model that deals with the reality of multiple
simpiflied features implemented as "decorated geometries" as well as
complex objects with extensive metadata
9) allow for open world and non-unique naming behaviours in a way that
allows multiple resources to be provided and combined  to support different
operations on a feature

I know this is expressed in an ugly half-way house between spatial and
semantics language and could be better formalised in either - but its an
attempt to draw the threads together.  I dont think this is actually too
complex for the lay person - who would see this through the prism of a few
use cases:
1) i have a thing with some spatial properties - find out the canonical
names of those property types and match them to the functionality my
environment supports
2) i want to express a spatial property of my thing - what terms are used
and which is the canonical form. (i will then decide it to use the
canonical form or a specific domain vocab secure in the knowledge it can be
mapped to an interoperable canonical form)
3) i have a set of things i care about - where is a service that can
implement a function I need

Rob





On Thu, 9 Jun 2016 at 08:35 Andrea Perego <andrea.perego@jrc.ec.europa.eu>
wrote:

> Many thanks for clarifying this point, Matt!
>
> Andrea
>
> On 08/06/2016 19:21, matthew perry wrote:
> > Hi Andrea,
> >
> > In GeoSPARQL, :SpatialObject was more of an abstract class that served
> > as the domain and range for topological relations. I don't think we
> > considered :SpatialObjects that were neither :Features nor :Geometries.
> >
> > Thanks,
> > Matt
> >
> >
> > On 6/8/2016 5:56 AM, Andrea Perego wrote:
> >> On 01/06/2016 14:43, matthew perry 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.
> >>
> >> Coming back to the comparison with ISO, does this mean then that, in
> >> GeoSPARQL, :SpatialObject subsumes also the notion of "real-world
> >> phaenomena", and not only features (GFI_Feature) and geometries
> >> (GM_Object)?
> >>
> >> Andrea
> >>
> >>
> >>> 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
> >>>> (<mailto:andrea.perego@jrc.ec.europa.eu>
> 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>) 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>> 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>>
> >>>>> >>> 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> wrote:
> >>>>> >>>>
> >>>>> >>>> In GeoSPARQL SpatialObject is superclass of geometry and spatial
> >>>>> >>>> feature.
> >>>>> >>>>
> >>>>> >>>> -----Original Message-----
> >>>>> >>>> From: Joshua Lieberman [mailto: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>>
> >>>>> >>>> Cc: andrea.perego@jrc.ec.europa.eu
> >>>>> >>>> <mailto:andrea.perego@jrc.ec.europa.eu>;
> >>>>> >>>> l.vandenbrink@geonovum.nl <mailto:l.vandenbrink@geonovum.nl>;
> >>>>> >>>> frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>;
> >>>>> >>>> public-sdw-wg@w3.org <mailto: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> 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> 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>
> >>>>> >>>>> orcid.org/0000-0002-3884-3420
> >>>>> >>>>> <http://orcid.org/0000-0002-3884-3420>
> >>>>> >>>>> researchgate.net/profile/Simon_Cox3
> >>>>> >>>>> <http://researchgate.net/profile/Simon_Cox3>
> >>>>> >>>>>
> >>>>> >>>>> ________________________________________
> >>>>> >>>>> From: Joshua Lieberman <jlieberman@tumblingwalls.com
> >>>>> >>>>> <mailto: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>)
> >>>>> >>>>> 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>> 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/
> >>>
> >>
> >
> >
>
> --
> 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/
>
>