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

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

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Fri, 20 May 2016 06:39:29 +0000
Message-ID: <CACfF9LzK919Q=FRB2=r6C2oYzOS-4XBz=gD0YC_d4WmcVW9Whg@mail.gmail.com>
To: Joshua Lieberman <jlieberman@tumblingwalls.com>, Frans Knibbe <frans.knibbe@geodan.nl>
Cc: Andrea Perego <andrea.perego@jrc.ec.europa.eu>, Rob Atkinson <rob@metalinkage.com.au>, Ed Parsons <eparsons@google.com>, SDW WG Public List <public-sdw-wg@w3.org>
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 Friday, 20 May 2016 06:40:19 UTC

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