W3C home > Mailing lists > Public > public-sdw-wg@w3.org > May 2016

RE: How to proceed with work on the spatial ontology task?

From: Linda van den Brink <l.vandenbrink@geonovum.nl>
Date: Thu, 26 May 2016 12:42:33 +0000
To: Frans Knibbe <frans.knibbe@geodan.nl>, Joshua Lieberman <jlieberman@tumblingwalls.com>, SDW WG Public List <public-sdw-wg@w3.org>
Message-ID: <13F9BF0BE056DA42BFE5AA6E476CDEFE725D3F4A@GNMSRV01.gnm.local>
Hi all, 

I haven't had the time to really follow this, but we could spend some time on the subject at the next SDW BP subgroup telecon. If Frans/Josh are present to lead the subject? 

Linda

-----Oorspronkelijk bericht-----
Van: Andrea Perego [mailto:andrea.perego@jrc.ec.europa.eu] 
Verzonden: woensdag 25 mei 2016 14:10
Aan: Frans Knibbe
CC: Joshua Lieberman; Rob Atkinson; SDW WG Public List
Onderwerp: Re: How to proceed with work on the spatial ontology task?

On 24/05/2016 11:57, Frans Knibbe wrote:
> [snip]
>
> I am glad you see a way forward that is approaching a satisfactory 
> level of elegance. But I wonder if the approach you suggest leaves 
> room for broader use of the geometry concept, particularly:
>
>  1. Allow geometry descriptors to be used for datasets of geometry
>     collections (e.g. express that all geometries in a dataset are 3D
>     points and have CRS X).
>  2. Allow geometry to use a non-earth CRS (e.g. Mars, a building, a
>     microscope slide, a piece of paper).
>  3. Allow geometry to exist without a spatial thing (e.g. a drawing I
>     make in Inkscape which does not represent any real world spatial thing).
>
> I also wonder if this improves options for compatibility with basic 
> geo and neogeo.
>
> And I would like to note that I expanded the wiki page 
> <https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL

> >
> a bit:
>
>   * I wrote that it makes sense to start with semantic foundations for
>     the concept of geometry
>   * I wrote that although not all relevant ISO standards are freely
>     available, the schemas that they define can be viewed at
>     http://www.isotc211.org/hmmg/HTML. It could be helpful that everyone
>     is able to look up GM_Object from ISO-19117, for instance.
>   * I added the current definition of geometry in GeoSPARQL
>     <https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL#Definition_of_geometry> (it
>     looks expandable enough)

Thanks, Frans.

I've also added to the same section the definitions of spatial object and feature, since they are correlated - geometry and feature are subclasses of spatial object, and they are mutually disjoint.

I think it is good to have the full "picture", also considering our discussions on real-world / spatial thing, spatial object, feature.

Andrea


> Regards,
> Frans
>
>
>
> 2016-05-23 15:57 GMT+02:00 Joshua Lieberman 
> <jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>>:
>
>     I’ve thought about this a bit more and there doesn’t seem to be any
>     significant problem with realizing GM_Object itself from 19107 as a
>     first-class (Web) object. An identified geometric object with
>     additional properties should also be compatible with GML, although
>     GML also puts a lot of attributes on properties such as
>     geometryPropertyType that would need to be class properties instead
>     in rdf or in json. If the necessary properties can be added to
>     GM_Object for discovery / governance / maintenance, this should
>     simplify the pattern for one-to-many or many-to-many feature -
>     geometry Web links.
>
>     The general pattern can also be collapsed further to an alternative
>     simple geometry property equivalent to georss Simple, with strict
>     defaults for cases where the simplest sort of positioning
>     expressiveness is sufficient. Not sure how best to define this
>     equivalence, however, beyond descriptively, as in GeoRSS and GML
>     3.2.1 . Perhaps SPIN would help?.
>
>     Almost elegant.
>
>     Example:
>
>     myFeature a geo:feature ;
>          rdf:about somefeatureURI
>          geo:point  "X,Y”
>          geo:centroid somegeometryURI
>
>
>     myGeometry a  geo:point ;
>                   rdf:about somegeometryURI
>                   geo:geomtype “point"
>                   geo:geomCRS <someCRSURL>
>                   geo:geomresolution “someResolution"
>                   geo:asWKT “POINT…”
>                   geo:asJSON “[…]”
>                   geo:asGML “<..>”
>                   geo:centroidFor somefeatureURI
>
>
>     where
>
>     geo:point  "X,Y” is equivalent to
>
>     geo:geometry [
>                   geo:geomtype “point"
>                   geo:geomCRS CRS84
>                   geo:geomresolution “undefined"
>                   geo:asPos “...”
>     ]
>
>     Josh
>
>>     On May 20, 2016, at 6:47 PM, Rob Atkinson <rob@metalinkage.com.au
>>     <mailto:rob@metalinkage.com.au>> wrote:
>>
>>
>>     anyone have an elegant solution? Do we make a wiki page for this
>>     specific problem?
>>     I think we are at the heart of the issue here - something fairly
>>     obvious with lots of bad ways of "solving", that we need expert
>>     help find a best practice for
>>
>>
>>     On Sat, 21 May 2016 at 08:15 Joshua Lieberman
>>     <jlieberman@tumblingwalls.com
>>     <mailto:jlieberman@tumblingwalls.com>> wrote:
>>
>>         Really don’t want to go down the reified property route with
>>         this and we’d still have geompropmeta1, geompropmeta2,…but I
>>         agree we have not achieved elegance here yet.
>>
>>         Josh
>>
>>
>>>         On May 20, 2016, at 5:52 PM, Rob Atkinson
>>>         <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>> wrote:
>>>
>>>         Hi Josh
>>>
>>>         leaving the meta-meta-meta complexity dimension aside for the
>>>         moment :-)
>>>
>>>         it sounds to me like you are making the case for reified
>>>         geometry properties - with a convention that a simple
>>>         property can have further properties declared against it with
>>>         a reified property
>>>
>>>         something like:
>>>
>>>         myFeature a geo:feature ;
>>>              foo:point  "X,Y"
>>>              foo:geompropmeta [
>>>                  foo:geomprop <foo:point>
>>>                  foo:geomfunction <foovoc:Centroid>
>>>                  foo:geomCRS <someCRSURL>
>>>             ]
>>>
>>>         this is limited to one value of a property per feature.
>>>         Or maybe there is a more elegant way of doing this?
>>>
>>>         R
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>         On Sat, 21 May 2016 at 02:07 Joshua Lieberman
>>>         <jlieberman@tumblingwalls.com
>>>         <mailto:jlieberman@tumblingwalls.com>> wrote:
>>>
>>>             We actually need to go up a level potential complexity
>>>             here and then figure out how to make it as simple as
>>>             possible. ISO 19107 was concerned with mathematically
>>>             valid geometries. 19109 is concerned with making the
>>>             separation between features and geometries by defining
>>>             geometric properties of features. All good so far, but
>>>             the step of creating a first-class geometric
>>>             representation object (identifiable and linkable with its
>>>             own properties) was not really considered either in the
>>>             ISO specs or in the GML realization. We’ve had linked
>>>             data schemes where data properties can be appended to
>>>             reference features with their characteristic geometry,
>>>             but not interchangeability of geometries for a given
>>>             feature (or distributed recognition of features by
>>>             linking data properties with independent geometric
>>>             representations.
>>>
>>>             This means going from feature <- geometry to feature <->
>>>             gm_representation <- geometry where gm_representation
>>>             carries searchable properties such as geometry type,
>>>             scale, crs, etc. and geometry can include alternate
>>>             serializations such as SVG that require being combined
>>>             with those properties.
>>>
>>>             Once such a feature realization is developed, one can
>>>             certainly collapse it to convenience formulations for
>>>             simpler cases, even point(lon, lat) as long as the
>>>             equivalence is well defined. Not sure what ontology
>>>             “dimension” this represents, or perhaps it’s a projection
>>>             along the complexity dimension.
>>>
>>>             Josh
>>>
>>>
>>>
>>>
>>>>             On May 20, 2016, at 5:04 AM, Frans Knibbe
>>>>             <frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>>
>>>>             wrote:
>>>>
>>>>             Hi Rob,
>>>>
>>>>             Have I understood correctly that you would like to see a
>>>>             prioritization of options for improvement? My thought
>>>>             was to first collect all possible ideas for improvement,
>>>>             and then refine or prioritize them. But we could add a
>>>>             section about priority of suggested changes now. I agree
>>>>             that the semantic foundations have high priority.
>>>>             Especially the definition of geometry, which is the core
>>>>             concept. When geometry is defined, geometry descriptors
>>>>             would follow from that more or less automatically. In
>>>>             other words - when building something, it makes perfect
>>>>             sense to start with the foundations.
>>>>
>>>>             It will be interesting to see if it possible to have a
>>>>             definition of geometry that is not exclusively
>>>>             geographic, that allows geometry to exist without a
>>>>             related spatial thing, and that does not clash with
>>>>             existing definitions.
>>>>
>>>>             Regards,
>>>>             Frans
>>>>
>>>>
>>>>
>>>>             2016-05-20 8:39 GMT+02:00 Rob Atkinson
>>>>             <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>>:
>>>>
>>>>
>>>>                 Hi - I looked at the page and I see the "first step"
>>>>                 I was wondering about in the middle : under Semantic
>>>>                 foundations.
>>>>
>>>>                 I'm not sure where to put my input as a result.
>>>>
>>>>                 The thread has highlighted that one issue is how
>>>>                 geometries are bound to a feature - what are they
>>>>                 are named (what property to use) and how those
>>>>                 properties themselves are modelled.
>>>>
>>>>                 We also have many possible encodings, levels of
>>>>                 detail, crs for each geometry - where is that
>>>>                 information present in the binding - in the property
>>>>                 definition, the datatype of the subject - e.g.
>>>>                 skos:notation
>>>>                 "GBP"^^a-uri-representing-the-set-of-currency-codes"
>>>>                 or by reification of the property.
>>>>
>>>>                 I suspect the "flat" model where we put an
>>>>                 out-of-band set of assertions about the equivalence
>>>>                 of property names is going to be the easiest way to
>>>>                 justify something as an actual "Practice" - but its
>>>>                 still an open question IMHO about the best way to
>>>>                 make it simple for clients. Finding and interpreting
>>>>                 OWL to understand a random property name is quite a
>>>>                 burden for the user - but easy for the publisher -
>>>>                 even easier if they neglect to publish the
>>>>                 definitions :-) This provider-centric pattern is I
>>>>                 suspect a major reason Linked Data has had low
>>>>                 levels of perceived value and adoption.
>>>>
>>>>                 To me establishing a well known binding of geometry
>>>>                 to features is more important than standardisation
>>>>                 amongst the many competing encodings - and has the
>>>>                 beneift that we dont need to resolve the best way to
>>>>                 encode now - even though we could make recommendations.
>>>>
>>>>                 So perhaps it comes down to testing whether
>>>>                 geosparql geo:feature allows us to implement all we
>>>>                 need, without introducing things we dont need - or
>>>>                 if we need to define something else and somehow
>>>>                 define an alignment with geosparql.
>>>>
>>>>                 thats the architect's viewpoint - how to make this
>>>>                 work for users. We need the semantacists input in
>>>>                 how best to achieve it.
>>>>
>>>>                 Left to my own devices - on the wiki page i'd put
>>>>                 this the semantic foundations at the top of the list
>>>>                 and push all the geometry-centric details into a set
>>>>                 of options for implementation choices. I felt i
>>>>                 should get feedback before going that far.
>>>>
>>>>                 Cheers
>>>>                 Rob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                 On Thu, 19 May 2016 at 23:08 Joshua Lieberman
>>>>                 <jlieberman@tumblingwalls.com
>>>>                 <mailto:jlieberman@tumblingwalls.com>> wrote:
>>>>
>>>>                     One of the rabbit holes we will need to skirt is
>>>>                     that everyone is an expert. While we may have
>>>>                     good reason in theory and practice to separate
>>>>                     feature - geometry - crs -serialization, many
>>>>                     Semantic Web representers of space have seen no
>>>>                     need for it for the application at hand and just
>>>>                     collapse everything into one concept. This is
>>>>                     one of the reasons that GeoRSS set up multiple
>>>>                     formulations with assertions of equivalence -
>>>>                     geo, simple, and GML. Then one could use a
>>>>                     simple form and someone else could unpack it to
>>>>                     do more with.
>>>>
>>>>                     Btw, using crs to enforce a serialization format
>>>>                     has always been a terrible idea. Better to let
>>>>                     geodesists and computer scientists each do what
>>>>                     they do best and document it.
>>>>
>>>>                     Joshua Lieberman, Ph.D.
>>>>                     Principal, Tumbling Walls Consultancy
>>>>                     Tel/Direct: +1 617-431-6431
>>>>                     <tel:%2B1%20617-431-6431>
>>>>                     jlieberman@tumblingwalls.com
>>>>                     <mailto:jlieberman@tumblingwalls.com>
>>>>
>>>>                     On May 19, 2016, at 08:51, Frans Knibbe
>>>>                     <frans.knibbe@geodan.nl
>>>>                     <mailto:frans.knibbe@geodan.nl>> wrote:
>>>>
>>>>>                     Thanks Andrea, I will add those ideas (I did
>>>>>                     already add GeoShape). If you come up with more
>>>>>                     ideas, please feel free to edit the wiki page.
>>>>>                     Everyone can use it as a scratch pad.
>>>>>
>>>>>                     Regards,
>>>>>                     Frans
>>>>>
>>>>>
>>>>>                     2016-05-19 14:39 GMT+02:00 Andrea Perego
>>>>>                     <andrea.perego@jrc.ec.europa.eu
>>>>>                     <mailto:andrea.perego@jrc.ec.europa.eu>>:
>>>>>
>>>>>                         Thanks, Frans.
>>>>>
>>>>>                         My two cents:
>>>>>
>>>>>
>>>>>                         1. Geometry serialisations / datatypes
>>>>>
>>>>>                         Other examples to be taken into account
>>>>>                         include:
>>>>>                         - Geohash
>>>>>                         (https://en.wikipedia.org/wiki/Geohash)
>>>>>                         - The geo: URI scheme
>>>>>                         (https://en.wikipedia.org/wiki/Geo_URI_scheme)
>>>>>                         - The serialisation used in Schema.org
>>>>>                         <http://schema.org/> - see, e.g.,
>>>>>                         http://schema.org/GeoShape

>>>>>
>>>>>                         On the other hand, I'm not sure the way
>>>>>                         NeoGeo models geometries can be considered
>>>>>                         a serialisation:
>>>>>
>>>>>                         
>>>>> http://geovocab.org/doc/neogeo.html#vocabulary

>>>>>
>>>>>
>>>>>                         2. Geometry descriptors
>>>>>
>>>>>                         I think we should include also the axis
>>>>>                         order. This should be implicitly specified
>>>>>                         by the CRS, but needs to be made explicit.
>>>>>                         Also, some platforms may use a default axis
>>>>>                         order irrespective of the CRS - if I'm not
>>>>>                         mistaken this is the case in PostGIS, where
>>>>>                         the default axis order is lon / lat.
>>>>>
>>>>>
>>>>>                         Cheers,
>>>>>
>>>>>                         Andrea
>>>>>
>>>>>
>>>>>                         On 19/05/2016 13:12, Frans Knibbe wrote:
>>>>>
>>>>>                             OK, I have just made a new wiki page
>>>>>                             <https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL>
>>>>>                             that links from the existing wiki page
>>>>>                             about the agreed spatial ontology
>>>>>                             <https://www.w3.org/2015/spatial/wiki/An_agreed_spatial_ontology>.
>>>>>                             The
>>>>>                             page is about a specfic approach to how
>>>>>                             to achieve the spatial ontology
>>>>>                             - we start with GeoSPARQL 1.0. That
>>>>>                             choice marks a significant narrowing
>>>>>                             of scope, and I hope the scope can be
>>>>>                             narrowed even further. The new
>>>>>                             wiki page is for collecting ideas on
>>>>>                             how we could further develop
>>>>>                             GeoSPARQL. Hopefully some people with
>>>>>                             good ideas can contribute and
>>>>>                             hopefully we can eventually align all
>>>>>                             ideas. Josh and Rob: Do you think
>>>>>                             the new wiki page can be a good way
>>>>>                             forward, and if so, can you manage
>>>>>                             to incorporate your ideas and
>>>>>                             information? If you agree this is a step
>>>>>                             in the right direction we could the
>>>>>                             take some action to involve more
>>>>>                             people in thinking along.
>>>>>
>>>>>                             Regards,
>>>>>                             Frans
>>>>>
>>>>>
>>>>>                             2016-05-19 2:56 GMT+02:00 Rob Atkinson
>>>>>                             <rob@metalinkage.com.au
>>>>>                             <mailto:rob@metalinkage.com.au>
>>>>>                             <mailto:rob@metalinkage.com.au
>>>>>                             <mailto:rob@metalinkage.com.au>>>:
>>>>>
>>>>>                                 Having a very lightweight ontology
>>>>>                             that defines a "feature" would be
>>>>>                                 a great start.  As a test case, I'd
>>>>>                             like to explore defining an
>>>>>                                 RDF-Datacube dimension using such
>>>>>                             an ontology - the
>>>>>                                 observation:featureOfInterest
>>>>>                             ontology. Personally, I dont think
>>>>>                                 importing the full ISO 19150
>>>>>                             ontology is a workable strategy - but
>>>>>                                 one could have annotation
>>>>>                             properties (or an additional module) that
>>>>>                                 handles the alignment to 19150.  At
>>>>>                             the moment I see many attempts -
>>>>>                                 but nothing accepted by the
>>>>>                             community at large.
>>>>>
>>>>>                                 simply, one ought to be able to
>>>>>                             look at a dimension defined against
>>>>>                                 a datatype, and/or set of objects,
>>>>>                             and discover that such objects a
>>>>>                                 spatial features and thus the
>>>>>                             dimension supports operations relevant
>>>>>                                 to spatial features - such as find
>>>>>                             the properties of such features
>>>>>                                 and running a filter on them.
>>>>>
>>>>>                                 I'm happy to help shepherd this Use
>>>>>                             Case through the emerging plan -
>>>>>                                 and verify the solution is
>>>>>                             implementable. I need this in the context
>>>>>                                 of other BP work OGC is involved in.
>>>>>
>>>>>                                 Rob
>>>>>
>>>>>                                 On Thu, 19 May 2016 at 02:03 Joshua
>>>>>                             Lieberman
>>>>>                                 <jlieberman@tumblingwalls.com
>>>>>                             <mailto:jlieberman@tumblingwalls.com>
>>>>>                             <mailto:jlieberman@tumblingwalls.com
>>>>>                             <mailto:jlieberman@tumblingwalls.com>>>
>>>>>                                 wrote:
>>>>>
>>>>>                                     This is probably a type
>>>>>                             locality for W3C - OGC collaboration, as
>>>>>                                     we should develop a GeoSPARQL
>>>>>                             change request and SWG charter
>>>>>                                     that contains a proposed update
>>>>>                             to the feature data ontology
>>>>>                                     part at least, that the SDWWG
>>>>>                             can then reference in BP. The
>>>>>                                     charter could be considered at
>>>>>                             the OGC June meeting. The
>>>>>                                     technical challenge (besides
>>>>>                             the usual simplicity vs capability)
>>>>>                                       is that there is pretty good
>>>>>                             consensus on the concepts and
>>>>>                                     principles, but we’re divided
>>>>>                             by the way those materialize in
>>>>>                                     different encodings.
>>>>>
>>>>>                                     Josh
>>>>>
>>>>>
>>>>>                                         On May 18, 2016, at 11:54
>>>>>                                 AM, Ed Parsons <eparsons@google.com
>>>>>                                 <mailto:eparsons@google.com>
>>>>>                                         <mailto:eparsons@google.com
>>>>>                                 <mailto:eparsons@google.com>>> wrote:
>>>>>
>>>>>                                         Frans I think it is up to
>>>>>                                 you and Josh to suggest a way
>>>>>                                         forward, I would suggest
>>>>>                                 you focus on a very strict scope of
>>>>>                                         documenting an ontology
>>>>>                                 based on that used by GeoSPARQL,
>>>>>                                         perhaps just start with a
>>>>>                                 shared document/wiki for comment ?
>>>>>
>>>>>                                         Ed
>>>>>
>>>>>                                         On Wed, 18 May 2016 at
>>>>>                                 10:42 Frans Knibbe
>>>>>                                         <frans.knibbe@geodan.nl
>>>>>                                 <mailto:frans.knibbe@geodan.nl>
>>>>>                                 <mailto:frans.knibbe@geodan.nl
>>>>>                                 <mailto:frans.knibbe@geodan.nl>>>
>>>>>                                 wrote:
>>>>>
>>>>>                                             Dear chairpeople, 
>>>>> Josh,
>>>>>
>>>>>                                             In the teleconference
>>>>>                                 of 2016-04-27
>>>>>
>>>>>                                 <https://www.w3.org/2016/04/27-sdw-minutes>
>>>>>                                 we discussed
>>>>>                                             the spatial ontology
>>>>>                                 mentioned in the charter as a part of
>>>>>                                             the BP deliverable.
>>>>>                                 Although no official actions or
>>>>>                                             resolutions were
>>>>>                                 recorded, we did agree that working on
>>>>>                                             this topic was needed,
>>>>>                                 that the work would be separate
>>>>>                                             from work on the BP
>>>>>                                 document, that Josh and I would try to
>>>>>                                             take point and that we
>>>>>                                 would take the current GeoSPARQL
>>>>>                                             standard as a starting
>>>>>                                 point.
>>>>>
>>>>>                                             How can we take this
>>>>>                                 forward? Should we first try to form
>>>>>                                             a group of interested
>>>>>                                 people? Or should we just start
>>>>>                                             somewhere, for example
>>>>>                                 by making a wish list for a next
>>>>>                                             version of GeoSPARQL,
>>>>>                                 and making that interesting enough
>>>>>                                             for many people to get
>>>>>                                 involved?
>>>>>
>>>>>                                             Regards,
>>>>>                                             Frans
>>>>>
>>>>>                                         --
>>>>>
>>>>>                                         *Ed Parsons *FRGS
>>>>>                                         Geospatial Technologist, 
>>>>> Google
>>>>>
>>>>>                                         Google Voice +44 (0)20 7881
>>>>>                                 4501
>>>>>                                 
>>>>> <tel:%2B44%20%280%2920%207881%204501>
>>>>>
>>>>>                                 <tel:%2B44%20%280%2920%207881%204501>
>>>>>                                         www.edparsons.com
>>>>>                                 <http://www.edparsons.com/>
>>>>>                                 <http://www.edparsons.com/> 
>>>>> @edparsons
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                         --
>>>>>                         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 Thursday, 26 May 2016 12:43:02 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:21 UTC