RE: SpatialThing and feature (again)

Hi, Clemens,

I think the last point should be re-phrased by saying that only some ISO 19109 features (i.e., spatial features) are spatial things, since, according to the BP definition, spatial things include "things" (real-world phaenomena) which are not features.

I.e.:

:SpatialFeature ≡ w3cgeo:SpatialThing ⨅ geosparql:Feature

Andrea

----
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

https://ec.europa.eu/jrc/


----
The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.

-----Original Message-----
From: Clemens Portele [mailto:portele@interactive-instruments.de] 
Sent: Tuesday, April 18, 2017 9:14 AM
To: Josh Lieberman
Cc: Simon Cox; public-sdw-wg@w3.org
Subject: Re: SpatialThing and feature (again)

To summarize:

* Every ISO 19109 feature is a GeoSPARQL geo:Feature (and GeoSPARQL is consistent with ISO 19109)
* E.g., it is correct to state that ex:loan is a geo:Feature
* It is not relevant whether it would be semantically correct to attach a geo:hasGeometry property to the feature or not
* The main role of geo:hasGeometry in GeoSPARQL is RDFS entailment, that is to infer that every subject of such a statement is a feature and every object is a geometry
* Spatial things in our BP are a subset of the ISO 19109 feature - i.e. only those with a "spatial extent"; e.g. ex:loan is not a spatial thing

Should we clarify the last point in chapter 5 of the BP as currently this is not clear?

Clemens

> On 15. Apr 2017, at 15:11, Joshua Lieberman <jlieberman@tumblingwalls.com> wrote:
> 
> In fact we use that in Hy Features to define hy_catchment as an ISO 19109-consistent logical feature that does not typically have a concrete geometry property in order to identify but not necessarily locate hydrologic topics of discourse.
> 
> Josh
> 
> On Apr 15, 2017, at 07:52, <Simon.Cox@csiro.au> <Simon.Cox@csiro.au> wrote:
> 
>>> Or is the definition of geo:hasGeometry in GeoSPARQL a much weaker statement and only has the effect that you describe (it entails that anything that carries a geo:hasGeometry property is a geo:Feature), but does not imply that it must be semantically correct to have a geo:hasGeometry property on something that is a geo:Feature?
>> 
>> Correct. Under the RDFS entailment regime, the implications of rdfs:domain/range axioms only affect the properties, not the classes. So the definition of geo:hasGeometry in GeoSPARQL entails that every thing that has a geo:hasGeometry is a geo:Feature, but it does not follow that every geo:Feature must have a geo:hasGeometry property. 
>> 
>> RDFS is mostly property-centric ...
>> 
>> -----Original Message-----
>> From: Clemens Portele [mailto:portele@interactive-instruments.de] 
>> Sent: Saturday, 15 April, 2017 19:24
>> To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
>> Cc: public-sdw-wg@w3.org
>> Subject: Re: SpatialThing and feature (again)
>> 
>> Thanks, Simon.
>> 
>>> On the other hand, if geo:Feature and BP feature are expected to have a spatial property […] then […]. But I don't think this is the case. 
>> 
>> 
>> My point was slightly different. I agree, I can have a building entity without a geo:hasGeometry property and it is perfectly fine to classify it as a geo:Feature. 
>> 
>> However, is it correct to have a loan entity and classify it explicitly as a geo:Feature? The geo:hasProperty to me states that all geo:Feature can have a geometry, which semantically does not make sense for the loan entity.
>> 
>> The UML equivalent to the geo:hasGeometry property would seem a supertype (like GFI_Feature from O&M) that all feature types are subtypes of and which has a "hasGeometry : GM_Object [0..*]" property. 
>> 
>> Or is the definition of geo:hasGeometry in GeoSPARQL a much weaker statement and only has the effect that you describe (it entails that anything that carries a geo:hasGeometry property is a geo:Feature), but does not imply that it must be semantically correct to have a geo:hasGeometry property on something that is a geo:Feature?
>> 
>> Clemens
>> 
>> 
>>> On 15. Apr 2017, at 10:36, Simon.Cox@csiro.au wrote:
>>> 
>>> Thanks for pointing this out (again) Clemens. 
>>> 
>>> As you note, the key is "the classification of real-world phenomena as features depends on their significance to a particular universe of discourse". And a corollary is that the _application schema_ for the particular universe of discourse defines the _types_ of features, and their properties, that are required for the discourse, and that these types are used to classify the individuals in the application. 
>>> 
>>> But getting onto the specific issue here, in GeoSPARQL there is a global constraint on the hasGeometry property such that  
>>>   geo:hasGeometry rdfs:domain geo:Feature . 
>>> This does *not* require every feature to a have a geometry. 
>>> Rather it entails that anything that carries a geo:hasGeometry property is a Feature, which is OK. 
>>> 
>>> On the other hand, if geo:Feature and BP feature are expected to have a spatial property - for example with a cardinality restriction that there is a minimum of one geo:hasGeometry property , then geo:Feature is clearly a sub-class of ISO 19109 Feature. But I don't think this is the case. 
>>> 
>>> Simon 
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: Clemens Portele [mailto:portele@interactive-instruments.de] 
>>> Sent: Thursday, 13 April, 2017 22:03
>>> To: SDW WG Public List <public-sdw-wg@w3.org>
>>> Subject: SpatialThing and feature (again)
>>> 
>>> Dear all,
>>> 
>>> I was having a discussion with a colleague whether the uses of "feature" in ISO 19109, geo:Feature in GeoSPARQL and "feature" in our BP document are consistent. My current conclusion is that they are not consistent, so I raise this here, also to see, if we need to be more clear in the BP text. If someone can point out the error in my analysis, this would be very welcome :)
>>> 
>>> In the section about "spatial things" and "features" in the BP [1] we basically build on the ISO 19101/19109 feature definition (with the special twist that Spatial Thing covers both "real-world phenomena" and their abstractions like “feature”). Our current definition of Spatial Thing ("anything with spatial extent") seems to imply that these are restricted to real-world phenomena where it semantically makes sense to have a property with a geometry as a value. The use of "Spatial" in the name also implies this.
>>> 
>>> This is consistent with GeoSPARQL in the sense that there is a standard property geo:hasGeometry for all entities that are a geo:Feature that has a geo:Geometry as its value. My interpretation of this is that this implies that it must be semantically correct for every sub-class of geo:Feature to provide a geometry. (Or is that too strict?)
>>> 
>>> But GeoSPARQL also states that it uses "feature" as defined in ISO 19101/19109/19156.
>>> 
>>> However, ISO 19109, which defines the General Feature Model used by ISO/TC 211 and OGC in its standards, does not require that features have a spatial extent or are something where it semantically makes sense to attach a geometry to. Classifying something as a feature is merely a statement of relevance ("the classification of real-world phenomena as features depends on their significance to a particular universe of discourse"), e.g. typically the resources that you would like to access/query in a dataset. One example in ISO 19109 is an application schema where a loan (on a building) is a feature. Many application schemas based on ISO 19109 include similar types of features.
>>> 
>>> A loan does not have a spatial extent and a has-geometry property does not make sense (to me), so a loan is not a Spatial Thing (in the sense of our BP document) and it also seems wrong to declare it as a geo:Feature.
>>> 
>>> If the analysis is correct, should we be more clear about this difference in section 5 of the BP (and perhaps the glossary)? 
>>> 
>>> It would also be good to be more clear about this in the planned revision of GeoSPARQL.
>>> 
>>> This discussion is somewhat philosophical, but has direct consequences when converting data based on the ISO/OGC "SDI" standards to RDF.
>>> 
>>> Best regards,
>>> Clemens
>>> 
>>> [1] http://w3c.github.io/sdw/bp/#spatial-things-features-and-geometry

>> 
>

Received on Tuesday, 18 April 2017 08:08:10 UTC