RE: SpatialThing and feature (again)

Hi, Josh.

Just to be sure I get your point:

Do you mean that

:SpatialFeature ≡ w3cgeo:SpatialThing ⨅ geosparql:Feature

should rather be

geosparql:Feature ≡ w3cgeo:SpatialThing ⨅ geosparql:Feature

or that geosparql:Feature and w3cgeo:SpatialThing are disjoint?

Thanks

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.

From: Joshua Lieberman [mailto:jlieberman@tumblingwalls.com]
Sent: Tuesday, April 18, 2017 8:10 PM
To: PEREGO Andrea (JRC-ISPRA)
Cc: Clemens Portele; Simon.Cox@csiro.au; public-sdw-wg@w3.org
Subject: Re: SpatialThing and feature (again)

>>:SpatialFeature ≡ w3cgeo:SpatialThing ⨅ geosparql:Feature

This should not be correct, as the w3cgeo “SpatialThings” lumped in explicit models such as geometry which are disjoint from any concept of feature. We have also not, so far as I know, defined such a concept as SpatialFeature.

Some other clarifications, I hope:

ISO1909 Feature =  "abstraction of real world phenomena”.  As a concept and basis for information, it is clearly not the real world itself. It also clearly has a strong connection to the real world, and for BP purposes we agreed that making the connection formal and explicit is not necessary for Web purposes. Same with SpatialThing, which is defined everywhere else but in W3C Basic Geo as an ISO19109 Feature. Maybe the BP wording needs to be improved...

My understanding is that we are using “Things” as concepts and topics of discourse in the information world pointing to real world phenomena. Otherwise the Internet of Things couldn’t exist, since the real world phenomena themselves are not networked. We’ll leave aside for the moment whether Thing refers to Sensors, Samples, or Features of Interest (my preference is the latter).

There is only one universe of discourse in the ISO19109 General Feature Model, simply recognizing that if no one can refer to a real world phenomenon in discourse, we have no way to conceptualize it. The applications come in with development of feature types and instances after the feature conceptualization.

The point that Clemens brings up is a subtle one. Does every ISO19109 feature have a spatial extent? We have used "spatial extent”,  I think, as a shorthand for "real world phenomena". The confusion is not whether a feature is in the real world and hence spatial, but whether it must be possible to model specific spatial extent / position properties for the feature. This is not necessary for 19109 features and I don’t believe it should have to be necessary for either SpatialThings or gsp:Feature. It should also be not necessary to provide an extent, e.g. geometry property for a defined, instantiated feature even if it is possible. It is,however, quite valuable to entail that an entity is a Feature by providing it with a hasGeometry property.

I could quibble about ex:Loan being a feature in and of itself, since it is not per se an abstraction of a real world phenomenon, but a concept that relates to exchange of funds, signing of contracts, existence of jurisdictions, and other real world phenomena that occur at specific times and places. It’s a quibble, because as long as loans are recognized by someone as a single or collection of real world phenomena, ex:Loan can be a feature even if too diffuse for a specific spatial extent.

—Josh


On Apr 18, 2017, at 4:07 AM, andrea.perego@ec.europa.eu<mailto:andrea.perego@ec.europa.eu> wrote:

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<mailto: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<mailto: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<mailto:Simon.Cox@csiro.au>> <Simon.Cox@csiro.au<mailto: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<mailto:Simon.Cox@csiro.au>>
Cc: public-sdw-wg@w3.org<mailto: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<mailto: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<mailto: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