- From: Rob Atkinson <rob@metalinkage.com.au>
- Date: Fri, 20 May 2016 06:39:29 +0000
- To: Joshua Lieberman <jlieberman@tumblingwalls.com>, Frans Knibbe <frans.knibbe@geodan.nl>
- Cc: Andrea Perego <andrea.perego@jrc.ec.europa.eu>, Rob Atkinson <rob@metalinkage.com.au>, Ed Parsons <eparsons@google.com>, SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CACfF9LzK919Q=FRB2=r6C2oYzOS-4XBz=gD0YC_d4WmcVW9Whg@mail.gmail.com>
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 06:40:19 UTC