- From: matthew perry <matthew.perry@oracle.com>
- Date: Wed, 8 Jun 2016 13:31:41 -0400
- To: public-sdw-wg@w3.org
- Message-ID: <6f3072ff-2aca-f50a-2995-51c1f4e7ab71@oracle.com>
+1 from me too. This makes sense.
However, would we allow SpatialThings/Features to participate in
topological relations or would topological relations only exist between
instances of SpatialModel? For example, can someone assert that the city
of Atlanta (Feature) is inside the state of Georgia (Feature)?
Cheers,
Matt
On 6/8/2016 8:46 AM, Clemens Portele wrote:
> +1
>
> with the following comments:
> * Linear referencing would also fall under SpatialModel, correct?
> * There is a subtle difference that probably does not matter for most
> between Feature (as defined in ISO 19109) and SpatialThing. ISO 19109
> states that "the classification of real-world phenomena as features
> depends on their significance to a particular universe of discourse".
> I.e. a feature does not have to have a "spatial model" property,
> although for the vast majority of features this will be the case. I do
> not see this as an issue, in particular, if we use a different term
> (SpatialThing).
>
> Clemens
>
> On 8 June 2016 at 14:07:48, simon.cox@csiro.au (simon.cox@csiro.au
> <mailto: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.
>>
>> *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/
>>
Received on Wednesday, 8 June 2016 17:32:27 UTC