- From: Joshua Lieberman <jlieberman@tumblingwalls.com>
- Date: Mon, 6 Jun 2016 08:48:20 -0700
- To: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Cc: Frans Knibbe <frans.knibbe@geodan.nl>, SDW WG Public List <public-sdw-wg@w3.org>, Linda van den Brink <l.vandenbrink@geonovum.nl>
Andrea,
Having both simple, property-based and more complex ISO/OGC-based forms of geometry is very useful, which is why GeoRSS did this with Simple and GML. The challenge has been how to equate them in some way other than just stating it.
Josh
> On Jun 6, 2016, at 8:36 AM, Andrea Perego <andrea.perego@jrc.ec.europa.eu> wrote:
>
> Hi, Josh.
>
> On 02/06/2016 14:04, Joshua Lieberman wrote:
>> Frans,
>>
>> I'll put GeoSPARQL and my emerging update (isogeo) on WebProtege and
>> share for next week.
>>
>> The LOCN vocabulary is a good reference. It basically concurs that
>> Location (a geographic name), Geometry, and Address are three principal
>> spatial objects with corresponding properties that have them as their
>> respective range. It doesn't have an explicit feature concept, so what
>> is accomplished by adding these properties to a resource is rather
>> vague. It is also very liberal in what it includes as geometry, from a
>> test literal to a full GML geometric object, so equivalence and
>> interoperability is an issue as the vocabulary definition acknowledges.
>> Nevertheless, our effort can be fairly compatible with LOCN.
>
> I think it is worth explaining the design choices behind LOCN, since they may be of interest for the "core" component of the spatial ontology. My apologies in advance for the long mail.
>
>
> LOCN was originally developped in the framework of the EU Programme "Interoperability Solutions for European Public Administrations" (ISA) - the same of DCAT-AP / GeoDCAT-AP, and of other core vocabularies (as the Registered Organization [1] and Person [2] vocabularies, now in W3C space). So, the scope of the work was about enabling cross-sector interoperability of location information.
>
> As such, LOCN was meant to define a minimal set of properties and classes, modelling the notion of "location" as it is used across sectors of public administrations, that can then be used as a basis for defining (sector-)specific extensions.
>
> The reference data models used in LOCN where those defined in the relevant INSPIRE data specifications - in particular, those concerning themes "geographical names" [3] and "addresses" [4]. However, the INSPIRE data models were considered too complex for being used in a cross-sector scenario, so LOCN either simplifies them or includes just a subset. E.g., geographical names are expressed just as plain literals, whereas locn:Address is modelled based on the "address representation" data type only [4].
>
> The notion of "feature" was one of the points discussed during the development of LOCN. The final decision was to leave it out from the "core", and to avoid any distinction between real-world things, real-world things with spatial characteristics and "abstractions" of real-world things (as features are defined in ISO). The reason was that such distinction was seen as not applicable (and difficult to understand and use) in a cross-domain context. The use of rdfs:Resource in the LOCN diagram (https://www.w3.org/ns/locn#glance) was a way to say that properties locn:location, locn:geometry and locn:address have no global domain restriction.
>
>
> Although the original scope of LOCN is public section information, IMO what said above applies also to the Web, and it is in line with the idea of making the "spatial ontology" modular.
>
> Based on this, I'd be in favour of including, in the core component of the spatial ontology, just the notions of "spatial thing" and geometry (as proposed by Frans [5] and Linda [6]), and to further elaborate it, if need be, in more specific modules. Moreover, I'm supportive to the idea of limiting the use of OWL to specific modules, and to use just RDF(S) for the core.
>
>
> About LOCN & geometries, the issues were mainly two:
>
> 1. Allowing the specification of geometries as simple literals, without preventing the use of a more sophisticated modelling with classes and properties (as done in W3C Basic Geo, GeoSPARQL, Schema.org, etc.).
>
> 2. Identifying recommended way(s) of specifying geometries.
>
> Point #1 is the reason why locn:geometry can be used either as a datatype or an object property, depending on the use case. E.g., when I just have to specify the point coordinates of a place, or the spatial coverage of a dataset, I'm likely to prefer a literal than a more complex representation.
>
> About point #2, LOCN didn't come up with a solution. Since there was not (and there is not) a recommended way of specifying geometries in RDF, the decision was to be as much inclusive as possible.
>
> Recently, point #2 was partially addressed by GeoDCAT-AP, by recommending the use of WKT or GML literals, as per GeoSPARQL, but without excluding other (and multiple) encodings / representations (e.g., GeoJSON). For more details, see:
>
> https://lists.w3.org/Archives/Public/public-sdw-wg/2015Jun/0167.html
>
>
> As far as geometries are concerned, I think the following requirements are still valid:
>
> (a) Providing a standardised way of supplying geometries in multiple encodings, in addition to the recommended one(s) - and we actually have a thread on this [7]
>
> (b) Giving people the ability to specify geometries either as simple literals or with specific classes & properties
>
>
> Cheers,
>
> Andrea
>
> ----
> [1]https://www.w3.org/TR/vocab-regorg/
> [2]https://www.w3.org/ns/person
> [3]http://inspire.ec.europa.eu/data-model/approved/r4618/html/index.htm?goto=2:1:6:2:7220
> [4]http://inspire.ec.europa.eu/data-model/approved/r4618/html/index.htm?goto=2:1:1:1:7042
> [5]https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jun/0018.html
> [6]https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jun/0019.html
> [7]https://lists.w3.org/Archives/Public/public-sdw-wg/2016May/0044.html
>
>
>>
>> Josh
>>
>> Joshua Lieberman, Ph.D.
>> Principal, Tumbling Walls Consultancy
>> Tel/Direct: +1 617-431-6431
>> jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>
>>
>> AsOn Jun 2, 2016, at 05:30, Frans Knibbe <frans.knibbe@geodan.nl
>> <mailto:frans.knibbe@geodan.nl>> wrote:
>>
>>> Hello all,
>>>
>>> It is good to see so many great minds puzzling over how to harmonize
>>> the core concepts of spatialness in OGC standards and how to involve
>>> other web standards too (by the way, in the latter respect I think it
>>> is good to look at the Location Core Vocabulary (LOCN)
>>> <https://www.w3.org/ns/locn> too: it has elected dcterms:Location as
>>> a central notion of a spatial thing that can have a geometry).
>>>
>>> In yesterday's meeting Josh agreed that it would be a good idea to
>>> take the discussion a step further and to start developing the spatial
>>> ontology for real. In fact, he has already started doing that, or so I
>>> understood.
>>>
>>> I had a brief look at what is happening in the SSN camp, it
>>> seems WebProtégé is used to have a shared view of the ontology in
>>> development. Would it be a good idea to load the current GeoSPARQL
>>> ontology in WebProtégé and to share options for further development of
>>> GeoSPARQL in WebProtégé?
>>>
>>> Regards,
>>> Frans
>>>
>>>
>>>
>>> 2016-06-02 3:49 GMT+02:00 <Simon.Cox@csiro.au
>>> <mailto:Simon.Cox@csiro.au>>:
>>>
>>> “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
>>> <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 Monday, 6 June 2016 15:49:04 UTC