Real-world phenomenon vs feature document as subject of a property

[jechterhoff]

Description

Most feature attributes and roles represent properties of the real-world phenomenon. According to the General Feature Model, it is common practice to model both

• properties that describe the real-world phenomenon and
• properties that describe the feature ("spatial object" in INSPIRE terminology) document, i.e. which are feature metadata,

as feature properties.

In INSPIRE, most properties are properties that describe the real-world phenomenon. However, there are exceptions:

• Properties that represent life-cycle information (in particular, the beginLifespanVersion and endLifespanVersion attributes) are marked with the stereotype <<lifeCycleInfo>>.
• Properties that have a value type from ISO 19115 are often feature metadata. However, this is not always the case, in particular for CI types. An example is ProtectedSite.legalFoundationDocument with value type CI_Citation.
• There are also some properties that require a closer review to identify them as feature metadata.

Examples are CadastralZoning.estimatedAccuracy with value type Length or CadastralZoning.originalMapScaleDenominator with value type Integer. These properties are not properties of the real-world phenomenon, but of the feature.

From the perspective of RDF vocabularies there is no distinction between the two types of properties. Nevertheless, it has impact on how instances are represented in RDF because it is important in linked data and the semantic web to be clear about the subjects. In this case we would have two subjects – the real-world phenomenon and the feature.

Discussion Item

Should the RDF encoding make a distinction between properties that describe the real-world phenomenon and properties that contain feature metadata? Are there specific advantages / disadvantages of (not) doing so?

If a distinction should be made in the encoding:

• Can you identify one or more approaches how the encoding should look like? For example: maybe one or more stereotypes could be introduced to identify metadata properties.
• Does the ThematicIdentifier need to be represented when considering that it is basically implemented by persistent URIs of the real-world phenomenon?

NOTE1: the Best Practices deliverable of the W3C/OGC working group may provide useful input to this discussion.

NOTE2: the reports from the study on RDF and PIDs for INSPIRE (prepared as part of the ARE3NA activity), especially the documents D.EC.1.1 and D.EC.2.1, provide additional background information for this issue.

[jechterhoff]

In the Spatial Data on the Web Working Group (SDW WG), there does not seem to be too much of a concern about not separating feature metadata from the feature data that actually describes a real-world phenomenon. In fact, such a distinction is considered to often not be helpful [1].

What appears to matter, however, is that a feature (abstraction of a real-world phenomenon) should be able to reference the real-world phenomenon it abstracts - or even multiple such phenomena [2]. This would support identifying that multiple features abstract the same real-world phenomenon. Example: an actual railway station may be modelled by two features (one being a "RailwayStationArea" and one being a "RailwayStationNode").

[1] https://github.com/w3c/sdw/issues/208 [2] https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jun/0116.html

[DieterDePaepe]

I'd say it depends on how exactly a "feature" is defined (see also #31). The definition that INSPIRE uses isn't clear to me at this point.

1) If a feature is "something that has a spatial representation", then every real world object is a feature. 2) If a feature is "something that a GIS user puts in a GIS tool", then this is a different object from the real world object.

I'm assuming we're talking about case 2 here (based on your questions), for which I'd say there needs to be a strict difference. This is also reflected in how properties can be used:

• A lake (as real world object) can have a property ex:depth that captures the depth of the lake.
• A lake GIS-feature can not use that same property, since it a representation that does not have a depth. It could have a ex2:depth property that has a different definition (specifically for use with a GIS-feature).

Should the RDF encoding make a distinction between properties that describe the real-world phenomenon and properties that contain feature metadata? Are there specific advantages / disadvantages of (not) doing so?

Yes, to make a clear distinction between different concepts and prevent confusion. It is also the only correct way to do it imo. The disadvantage is that some people might not immediately see the difference between the two.

Can you identify one or more approaches how the encoding should look like? For example: maybe one or more stereotypes could be introduced to identify metadata properties.

The difference in domain and the description of the properties should make this clear. Maybe even a specialized predicate could make the link between the property for a RWO property and a GIS-feature property: gisfeat:depth :isFeaturePredicateOf rwo:depth

Does the ThematicIdentifier need to be represented when considering that it is basically implemented by persistent URIs of the real-world phenomenon?

The ThematicIdentifier is a specialised adms:Identifier of the real world object that is linked to the GIS-feature. In that way, it still makes sense to make it an explicit attribute.

In the Spatial Data on the Web Working Group (SDW WG), there does not seem to be too much of a concern about not separating feature metadata from the feature data that actually describes a real-world phenomenon. In fact, such a distinction is considered to often not be helpful [1].

I feel that they are arguing about a different topic: the identifier of a RWO versus the document describing it (which is not the same as a feature).

[jechterhoff]

The draft vocabularies do not differentiate between properties that describe the real-world phenomenon and properties that contain feature metadata (see also [1]).

This is in line with the Spatial Data on the Web Best Practice 1 (Use globally unique persistent HTTP URIs for Spatial Things), which says: "However, in most cases using a single URI for both Spatial Thing and the page/document is simpler to implement and meets the expectations of most end-users." Also see chapter 6 "Spatial Things, Features and Geometry" of the SDW Best Practices [3].

[1] http://inspire-eu-rdf.github.io/inspire-rdf-guidelines/#ref_instance_cr_considerations_on_spatial_objects [2] https://www.w3.org/TR/sdw-bp/#bp-identifiers [3] https://www.w3.org/TR/sdw-bp/#spatial-things-features-and-geometry