- 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