- From: Frans Knibbe <frans.knibbe@geodan.nl>
- Date: Tue, 24 May 2016 12:42:50 +0200
- 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>
- Message-ID: <CAFVDz42z1N4jK=1qW_edF06SGdP4Ku1oBM=mYgXNiPqEjwMgkQ@mail.gmail.com>
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