- From: Frans Knibbe <frans.knibbe@geodan.nl>
- Date: Fri, 27 May 2016 10:54:44 +0200
- To: Linda van den Brink <l.vandenbrink@geonovum.nl>
- Cc: Joshua Lieberman <jlieberman@tumblingwalls.com>, SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CAFVDz40SXJU=psaUW5NHJZu46zDEYJq2X=9bWsoV3n8ofDvoPQ@mail.gmail.com>
2016-05-26 14:42 GMT+02:00 Linda van den Brink <l.vandenbrink@geonovum.nl>: > Hi all, > > I haven't had the time to really follow this, but we could spend some time > on the subject at the next SDW BP subgroup telecon. If Frans/Josh are > present to lead the subject? > Sure, this is a subject worhty of broad attention. Regards, Frans > > Linda > > -----Oorspronkelijk bericht----- > Van: Andrea Perego [mailto:andrea.perego@jrc.ec.europa.eu] > Verzonden: woensdag 25 mei 2016 14:10 > Aan: Frans Knibbe > CC: Joshua Lieberman; Rob Atkinson; SDW WG Public List > Onderwerp: Re: How to proceed with work on the spatial ontology task? > > On 24/05/2016 11:57, Frans Knibbe wrote: > > [snip] > > > > 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) > > Thanks, Frans. > > I've also added to the same section the definitions of spatial object and > feature, since they are correlated - geometry and feature are subclasses of > spatial object, and they are mutually disjoint. > > I think it is good to have the full "picture", also considering our > discussions on real-world / spatial thing, spatial object, feature. > > Andrea > > > > Regards, > > Frans > > > > > > > > 2016-05-23 15:57 GMT+02:00 Joshua Lieberman > > <jlieberman@tumblingwalls.com <mailto: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 > >> <mailto: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 > >> <mailto: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 <mailto: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 > >>> <mailto: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 <mailto: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) > >>>>> - 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> > >>>>> <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> > >>>>> 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> > >>>>> 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/ > >>>>> > >>>>> > >>>> > >>> > >> > > > > > > -- > 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, 27 May 2016 08:55:16 UTC