- From: Rob Atkinson <rob@metalinkage.com.au>
- Date: Fri, 20 May 2016 22:47:02 +0000
- To: Joshua Lieberman <jlieberman@tumblingwalls.com>, Rob Atkinson <rob@metalinkage.com.au>
- Cc: Frans Knibbe <frans.knibbe@geodan.nl>, Andrea Perego <andrea.perego@jrc.ec.europa.eu>, Ed Parsons <eparsons@google.com>, SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CACfF9LxXPbZYMd2XDgG8abjqy1xL7DTFyWHB-fkC7uenXRCm8A@mail.gmail.com>
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 Friday, 20 May 2016 22:47:46 UTC