- From: Joshua Lieberman <jlieberman@tumblingwalls.com>
- Date: Fri, 20 May 2016 12:07:57 -0400
- To: Frans Knibbe <frans.knibbe@geodan.nl>
- Cc: Rob Atkinson <rob@metalinkage.com.au>, Andrea Perego <andrea.perego@jrc.ec.europa.eu>, Ed Parsons <eparsons@google.com>, SDW WG Public List <public-sdw-wg@w3.org>
- Message-Id: <F66B4DA9-AAFB-4D6B-826F-0392F131F6F6@tumblingwalls.com>
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 <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 <https://en.wikipedia.org/wiki/Geohash>) >> - The geo: URI scheme (https://en.wikipedia.org/wiki/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 <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 <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 <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 <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 <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 <tel:%2B44%20%280%2920%207881%204501>> >> www.edparsons.com <http://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/ <https://ec.europa.eu/jrc/> >> >
Received on Friday, 20 May 2016 16:09:05 UTC