- From: Frans Knibbe <frans.knibbe@geodan.nl>
- Date: Tue, 24 May 2016 12:00:59 +0200
- To: Joshua Lieberman <jlieberman@tumblingwalls.com>
- Cc: Rob Atkinson <rob@metalinkage.com.au>, Andrea Perego <andrea.perego@jrc.ec.europa.eu>, SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CAFVDz42tsPAEQWtD_GhdUQu0ZcaztBjcjKqQkXsfP0mrR3=RQA@mail.gmail.com>
Sorry, my message contained two confusing mistakes. I meant to write "Allow geometry descriptors to be used for datasets *or* geometry collections" and "..look up GM_Object from *ISO-19107*" Frans 2016-05-24 11:57 GMT+02:00 Frans Knibbe <frans.knibbe@geodan.nl>: > Hello Josh, > > I am glad you see a way forward that is approaching a satisfactory level > of elegance. But I wonder if the approach you suggest leaves room for > broader use of the geometry concept, particularly: > > 1. Allow geometry descriptors to be used for datasets of geometry > collections (e.g. express that all geometries in a dataset are 3D points > and have CRS X). > 2. Allow geometry to use a non-earth CRS (e.g. Mars, a building, a > microscope slide, a piece of paper). > 3. Allow geometry to exist without a spatial thing (e.g. a drawing I > make in Inkscape which does not represent any real world spatial thing). > > I also wonder if this improves options for compatibility with basic geo > and neogeo. > > And I would like to note that I expanded the wiki page > <https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL> a > bit: > > - I wrote that it makes sense to start with semantic foundations for > the concept of geometry > - I wrote that although not all relevant ISO standards are freely > available, the schemas that they define can be viewed at > http://www.isotc211.org/hmmg/HTML. It could be helpful that everyone > is able to look up GM_Object from ISO-19117, for instance. > - I added the current definition of geometry in GeoSPARQL > <https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL#Definition_of_geometry> (it > looks expandable enough) > > Regards, > Frans > > > > 2016-05-23 15:57 GMT+02:00 Joshua Lieberman <jlieberman@tumblingwalls.com> > : > >> I’ve thought about this a bit more and there doesn’t seem to be any >> significant problem with realizing GM_Object itself from 19107 as a >> first-class (Web) object. An identified geometric object with additional >> properties should also be compatible with GML, although GML also puts a lot >> of attributes on properties such as geometryPropertyType that would need to >> be class properties instead in rdf or in json. If the necessary properties >> can be added to GM_Object for discovery / governance / maintenance, this >> should simplify the pattern for one-to-many or many-to-many feature - >> geometry Web links. >> >> The general pattern can also be collapsed further to an alternative >> simple geometry property equivalent to georss Simple, with strict defaults >> for cases where the simplest sort of positioning expressiveness is >> sufficient. Not sure how best to define this equivalence, however, beyond >> descriptively, as in GeoRSS and GML 3.2.1 . Perhaps SPIN would help?. >> >> Almost elegant. >> >> Example: >> >> myFeature a geo:feature ; >> rdf:about somefeatureURI >> geo:point "X,Y” >> geo:centroid somegeometryURI >> >> >> myGeometry a geo:point ; >> rdf:about somegeometryURI >> geo:geomtype “point" >> geo:geomCRS <someCRSURL> >> geo:geomresolution “someResolution" >> geo:asWKT “POINT…” >> geo:asJSON “[…]” >> geo:asGML “<..>” >> geo:centroidFor somefeatureURI >> >> >> where >> >> geo:point "X,Y” is equivalent to >> >> geo:geometry [ >> geo:geomtype “point" >> geo:geomCRS CRS84 >> geo:geomresolution “undefined" >> geo:asPos “...” >> ] >> >> Josh >> >> On May 20, 2016, at 6:47 PM, Rob Atkinson <rob@metalinkage.com.au> wrote: >> >> >> 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 >> >> >> 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:01:30 UTC