- From: Joshua Lieberman <jlieberman@tumblingwalls.com>
- Date: Fri, 27 May 2016 09:47:36 -0400
- To: Linda van den Brink <l.vandenbrink@geonovum.nl>
- Cc: Frans Knibbe <frans.knibbe@geodan.nl>, SDW WG Public List <public-sdw-wg@w3.org>
I should be able to attend and discuss this. WRT Frans’ points below, requiring a CRS for any but the simplest version of geometry (the simplegeomproperty, e.g. point(“x y”), makes extension to non-Earth or non-geospatial geometries generally straightforward, although some applications may require support for additional interpolation methods between positions. It certainly is easier to incorporate a geometry into other spatial objects if it can be represented independently, but it is important to recognize when the intent is to subclass geospatial feature by adding a geometry property to an entity. While there are real drawbacks in lack of access to the ISO standards, documents like the 19107 specification are not that useful for implementation. The diagrams in hmmg referenced below represent the conceptual schemas and actual implementations differ. GML and WKT, for example, specifies a sequence of coordinate sets to position a curve, not individual curve segments. Creation of Web-accessible explanations of realized RDF/OWL vocabulary entities like GM_Point will be much more useful, and I believe can be provided openly just as GML / GeoSPARQL specifications are. What standards such as 19107 provide are the mathematical foundations of geometric entities and operations. I’m not sure what it means to provide semantic foundations, however, a spatial ontology consistent with 19107 will need to reflect those mathematical properties in the statements that define it. It will be useful also to provide a narrative description of what a DirectPosition is, but that is at best a sort of informative semantics. The exception at present seems to be in setting up some of the transformations that will allow backwards compatibility with such vocabularies as basic geo. Not sure we can do more than state that a basic geo point is the same as a set of statements in our proposed ontology. I have a suspicion that we may be able to be a little more formal using SPARQL, but haven’t really explored this yet. I will look over and contribute to the wiki page before the call next week. Josh > On May 26, 2016, at 8:42 AM, Linda van den Brink <l.vandenbrink@geonovum.nl> wrote: > > 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? > > 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 13:48:15 UTC