- From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Date: Wed, 25 May 2016 14:10:26 +0200
- To: Frans Knibbe <frans.knibbe@geodan.nl>
- Cc: Joshua Lieberman <jlieberman@tumblingwalls.com>, Rob Atkinson <rob@metalinkage.com.au>, SDW WG Public List <public-sdw-wg@w3.org>
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 Wednesday, 25 May 2016 12:11:13 UTC