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

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

From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Tue, 24 May 2016 12:42:50 +0200
Message-ID: <CAFVDz42z1N4jK=1qW_edF06SGdP4Ku1oBM=mYgXNiPqEjwMgkQ@mail.gmail.com>
To: Rob Atkinson <rob@metalinkage.com.au>
Cc: Joshua Lieberman <jlieberman@tumblingwalls.com>, Andrea Perego <andrea.perego@jrc.ec.europa.eu>, Ed Parsons <eparsons@google.com>, SDW WG Public List <public-sdw-wg@w3.org>
2016-05-21 0:47 GMT+02:00 Rob Atkinson <rob@metalinkage.com.au>:

>
> 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
>

Having a wiki page dedicated to how we could the geometry class in
GeoSPARQL seems a good idea to me.

Regards,
Frans

>
>
> On Sat, 21 May 2016 at 08:15 Joshua Lieberman <
> 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> 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> 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>
>>> 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>:
>>>
>>>>
>>>> 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> 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
>>>>> jlieberman@tumblingwalls.com
>>>>>
>>>>> On May 19, 2016, at 08:51, Frans Knibbe <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>:
>>>>>
>>>>>> 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>>:
>>>>>>>
>>>>>>>     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>>
>>>>>>>     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>> 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>>
>>>>>>>> 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
>>>>>>>> <%2B44%20%280%2920%207881%204501>>
>>>>>>>>         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/
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
Received on Tuesday, 24 May 2016 10:43:20 UTC

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