- From: Joshua Lieberman <jlieberman@tumblingwalls.com>
- Date: Thu, 19 May 2016 09:08:33 -0400
- To: 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>
- Message-Id: <FB3858D5-2E4A-42EE-9A90-C94B6FE13A11@tumblingwalls.com>
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 - 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> >>>> 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 Thursday, 19 May 2016 13:09:30 UTC