- From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Date: Thu, 09 Jun 2016 01:00:23 +0200
- To: Simon.Cox@csiro.au, jlieberman@tumblingwalls.com
- Cc: rob@metalinkage.com.au, frans.knibbe@geodan.nl, bill@swirrl.com, l.vandenbrink@geonovum.nl, public-sdw-wg@w3.org, matthew.perry@oracle.com
On 08/06/2016 14:07, Simon.Cox@csiro.au wrote:
> 2) Separate Thing and Model:
>
> owl:Thing <- SpatialThing (== Feature)
>
> <- SpatialModel <- Geometry + other spatial models such as LOCN
>
> …
>
> I’m inclined toward 2), also thinking that it’s important to define
> SpatialThing as having at least 1 SpatialModel property, so it’s clear
> as in GeoRSS that adding a hasSpatialModel property to a resource makes
> that resource a SpatialThing.
>
> I’m comfortable with that.
I'm also happy with option #2. Only, it's unclear to me what we actually
mean with SpatialThing / Feature - my apologies in case I missed the
relevant point in this discussion.
If we use "feature" as in ISO & GeoSPARQL, then real-world phaenomena /
things with spatial characteristics are not supposed to be SpatialThing's.
If this the case, probably option #2 could be revised as follows:
owl:Thing <- SpatialThing <- Feature
<- SpatialModel <- Geometry + other models
where SpatialThing means "anything having spatial characteristics" -
real-world things, abstractions of real-world things (features), spatial
models, geometries. Which is basically the sense of geo:SpatialThing
(Basic Geo).
Andrea
>
> *From:*Joshua Lieberman [mailto:jlieberman@tumblingwalls.com]
> *Sent:* Saturday, 4 June 2016 5:59 AM
> *To:* Rob Atkinson <rob@metalinkage.com.au>
> *Cc:* Frans Knibbe <frans.knibbe@geodan.nl>; Bill Roberts
> <bill@swirrl.com>; Linda van den Brink <l.vandenbrink@geonovum.nl>; SDW
> WG Public List <public-sdw-wg@w3.org>; Cox, Simon (L&W, Clayton)
> <Simon.Cox@csiro.au>; matthew perry <matthew.perry@oracle.com>
> *Subject:* Re: Agenda for Best Practice sub-group, 14:00UTC 1-June-2016
>
> There are a couple of issues with GeoSPARQL and other existing “spatial”
> ontologies.
>
> Critical to the general feature model and ISO 19109 is a distinction
> between something one discerns and discourses about in the world,
> and a spatial model (particularly a geometry) for that something. We
> need to preserve that disjunction, however both the distinction and
> the term “feature” we use for the “something” is a puzzlement to
> most non-geospatialists in the world.
>
> Having identified two “something"'s in the world, the next step that
> most people want to take is describe how they are related. Many of
> those relations are directly or indirectly spatial — “touching”,
> “not disjoint”, “near”, etc.. Mathematically, spatial relations are
> only computable between spatial models such as geometries, but
> intuitively those relations should be transitive to the “somethings”
> themselves.
>
> As Matt noted, in geoSPARQL both Feature and Geometry were subclassed
> from SpatialObject in order to apply spatial relations to either of
> them, despite some misgivings as to whether a Feature should be
> considered as innately spatial. That explains the three concepts.
> Reducing to just Spatial Object (or even owl:Thing) as representing our
> concept of Feature and subclassing Geometry from it would remove the
> disjunction between Feature and Geometry. SpatialObject and Geometry
> could be separate disjunctive owl:Thing’s, but that would make it more
> difficult to restrict spatial relations to either SpatialObject or
> Geometry, and leave no place for other spatial models such as addresses.
>
> Are features inherently spatial? In the GFM, they only have to have
> identity (which by the way disqualifies owl:Thing since they can be
> blank nodes).r However, in GFM, feature refers to both type and
> instance. A type itself is not spatial, but each instance can be
> presumed to recognize phenomena in the real world whether their position
> and extent is known / knowable or not. In OWL, a feature is either an
> individual or a collection of individuals, so it can be argued that an
> OWL Feature is in fact spatial. Quite apart from this theory, most
> people would conclude that a geographic feature is something spatial for
> all but rather un-interesting edge cases.
>
> So we still have two disjunctive concepts, but if both of them can be
> considered spatial so that spatial relations could be applied, although
> we would want to be able to state that a spatial relation involving a
> “feature” implies a possible relation involving geometry. The present
> GeoSPARQL model make sense, then, except perhaps for the name “Feature”.
> We could even include both SpatialThing and Feature in SpatialObject
> with owl:SameAs, for those who can’t get their heads around the “F-word”.
>
> An alternative with some pluses and minuses, would be separate classes
> for SpatialThing a owl:Thing and SpatialModel a owl:Thing, restricting
> spatial relations to one or the other and placing Geometry in
> SpatialModel along with Addresses, Placenames, and other
> not-directly-geometric locators. This adds SpatialModel to the mix, but
> makes it easier to set every type of spatial model disjoint from spatial
> things (that are pretty much distinguished from owl:Thing only by a
> required identity).
>
> [I would probably leave topological elements out of SpatialModel or
> SpatialObject, since spatial relations will generally not be applicable
> and I continue to think that topo elements need not be disjoint from
> features — they really just add “to, from” object properties to a
> feature and are generally unique e.g. a feature representing a topo edge
> will not also represent a node or a face.]
>
> So, three proposals:
>
> 1) Leave GeoSPARQL as it is and add an equivalent SpatialThing:
>
> owl:Thing <- SpatialObject <- Feature == SpatialThing
>
> <- Geometry
>
> <- other spatial models such as LOCN
>
> 2) Separate Thing and Model:
>
> owl:Thing <- SpatialThing (== Feature)
>
> <- SpatialModel <- Geometry + other spatial models such as LOCN
>
> 3) All together:
>
> owl:Thing <- SpatialObject <- SpatialThing (== Feature)
>
> <- SpatialModel <- Geometry + other spatial models such as LOCN
>
> I’m inclined toward 2), also thinking that it’s important to define
> SpatialThing as having at least 1 SpatialModel property, so it’s clear
> as in GeoRSS that adding a hasSpatialModel property to a resource makes
> that resource a SpatialThing.
>
> Let me know what you think, but I’ll put a version of 2) into WebProtege
> over the weekend so we can poke it around.
>
> Josh
>
> Joshua Lieberman, Ph.D.
>
> Principal
>
> Tumbling Walls
>
> jlieberman*tumblingwalls.com <http://tumblingwalls.com>
>
> +1 617 431 6431
>
> On Jun 3, 2016, at 9:46 AM, Rob Atkinson <rob@metalinkage.com.au
> <mailto:rob@metalinkage.com.au>> wrote:
>
> lets get the model right - and support the behaviours we need - then
> argue about the best names.
>
> If we have an issue with the current GeoSPARQL model - then we have
> a decision point around whether it compromises its usefulness, and
> hence if and how we use it.
>
> Is anyone able to summarise the concerns with the current GeoSparql
> model? What is it missing and what does it do strangely or incorrectly?
>
> On Fri, 3 Jun 2016 at 23:09 Frans Knibbe <frans.knibbe@geodan.nl
> <mailto:frans.knibbe@geodan.nl>> wrote:
>
> To me the names or labels of the concepts are less important
> than their usefulness. If we can manage with just two concepts
> (classes) for geometry and spatial things, then that would be a
> victory for simplicity and clarity. That said, I think for the
> world at large a label like 'spatial thing' is better at
> conveying the meaning of the term than 'feature'.
>
> Regards,
>
> Frans
>
> 2016-06-03 14:56 GMT+02:00 Bill Roberts <bill@swirrl.com
> <mailto:bill@swirrl.com>>:
>
> So are we saying that a Feature is the same as a Spatial Object?
>
> It probably depends on your background which of those names
> is most evocative - obviously both are, in themselves, open
> to interpretation.
>
> To me 'feature' makes me think of maps, whereas 'spatial
> object' (while not necessarily the best name ever - 'spatial
> thing' while also very vague is perhaps slightly better
> because of all the software and information modelling uses
> of 'object') makes me think of something I could see or walk
> round or hit with a hammer.
>
> Whatever we call it, I think we should be talking about
> things you can see and walk round.
>
> On 3 June 2016 at 13:18, Rob Atkinson
> <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>> wrote:
>
> "(something like: things that have some kind of spatial
> presence" ... well - thats what a feature is, and it is
> at least defined somewhere - so surely we drop the more
> ambiguous term "spatial object" whose existence is a
> modelling artefact, not a real world need. To me
> "spatial object" is too easily confused with either a
> feature or a geometry
>
> Feature and geometry both have real-world analogues - if
> we really need something like "spatial object" to
> support some logic then perhaps we can start off by
> defining why we need, and then debate a suitable name.
>
> rob
>
> On Fri, 3 Jun 2016 at 19:59 Linda van den Brink
> <l.vandenbrink@geonovum.nl
> <mailto:l.vandenbrink@geonovum.nl>> wrote:
>
> Hi all,
>
> +1 That’s exactly what I was thinking this morning
> when I read this thread. Without being able to put
> into words why I’m thinking this, as of yet…
>
> Linda
>
> *Van:*Frans Knibbe [mailto:frans.knibbe@geodan.nl
> <mailto:frans.knibbe@geodan.nl>]
> *Verzonden:* vrijdag 3 juni 2016 11:39
> *Aan:* Joshua Lieberman; SDW WG Public List; Simon
> Cox; matthew perry
> *Onderwerp:* 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
> <mailto: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
> <mailto: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]
> *Sent:* Wednesday, 1 June 2016 11:23 PM
> *To:* matthew perry <matthew.perry@oracle.com
> <mailto:matthew.perry@oracle.com>>
> *Cc:* public-sdw-wg@w3.org
> <mailto: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
> <mailto: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
> <mailto: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> <mailto: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>
> >>><mailto: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> <mailto: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>
> >>>><mailto: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>
> >>>><mailto:Simon.Cox@csiro.au>
> <mailto:Simon.Cox@csiro.au>>
> >>>> Cc:andrea.perego@jrc.ec.europa.eu
> <mailto:andrea.perego@jrc.ec.europa.eu>
> >>>><mailto:andrea.perego@jrc.ec.europa.eu>
> <mailto:andrea.perego@jrc.ec.europa.eu>;
>
> >>>>l.vandenbrink@geonovum.nl
> <mailto:l.vandenbrink@geonovum.nl>
> <mailto:l.vandenbrink@geonovum.nl>
> <mailto:l.vandenbrink@geonovum.nl>;
> >>>>frans.knibbe@geodan.nl
> <mailto:frans.knibbe@geodan.nl>
> <mailto:frans.knibbe@geodan.nl>
> <mailto:frans.knibbe@geodan.nl>;
> >>>>public-sdw-wg@w3.org
> <mailto:public-sdw-wg@w3.org>
> <mailto: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>
> >>>>><mailto: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
> >>>>> Esimon.cox@csiro.au
> <mailto:simon.cox@csiro.au>
> <mailto:simon.cox@csiro.au>
> <mailto:simon.cox@csiro.au> T +61 3
> 9545
> >>>>> 2365 M+61 403 302 672
> <tel:%2B61%20403%20302%20672>
> >>>>> 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>
> <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>
> <http://orcid.org/0000-0002-3884-3420>
> >>>>>researchgate.net/profile/Simon_Cox3
> <http://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>
> >>>>><mailto: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>
> <mailto: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>
> >>>>>><mailto: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/
Received on Wednesday, 8 June 2016 23:01:10 UTC