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