Feature Identifiers

[cmheazel]

There are two types of Feature Identifier and we need to make sure we distinguish between them.

1. The feature instance identifier identifies a specific instance of a feature resource.
2. The feature object identifier associates an real world object with the feature resource.
   As the Feature is updated over time the instance identifier will change with each update, the object identifier will not. This is important for linked data. An association with a real world object has different semantics from an association with a specific digital representation of that object. In the first case, the Feature can be modified without impacting the association. This is not true in the second case.

[cportele]

In the Spatial Data on the Web working group we had longer discussions about this and agreed that

• most of the time using a single identifier for spatial thing and page/document resource is both simpler to implement and better meets the expectations of end users
• there is no obligation to distinguish between the spatial thing and the page/document unless your application requires this

See w3c/sdw#208 and w3c/sdw#39 including the email threads linked from there.

This resulted in: https://www.w3.org/TR/sdw-bp/#spatial-things-features-and-geometry

I have been working from the assumption that we would take the same view. Maybe we need to clarify this in the definition section and discuss it in more detail in the Guide (if this requires more discussion that what we have in the Best Practices).

[cmheazel]

OGC 17-087r8 distinguishes between Feature Identifiers (unique identifier associated to a real-world phenomenon) and Object Identity (identifier associated to an instance of an object). This is the distinction I am trying to make. Is 17-087 consistent with the SDW recommendations?

[lvdbrink]

@cmheazel can you clarify which document is OGC 17-087? (ideally, provide a link)?

[cportele]

@lvdbrink - 17-087 is the "Feature and Geometries - Part 1" draft. Latest version is 17-087r11 - on OGC pending. This currently is an OGC internal document.

[cmheazel]

Sure Linda,
17-087 is the proposed abstract spec Geographic information - Features and geometry – Part 1: Feature models. You can find it on Pending Documents. The most recent version is at https://portal.opengeospatial.org/files/?artifact_id=77854&version=1. Both Clemens and Peter are listed as submitters so I figure that it is an accurate reflection of their views.

[cportele]

@cmheazel I missed your comment - I guess since it was created during the Hackathon 😉.

The distinction between the identifiers is the same distinction made in the Web Architecture and SDW - although with different terms (I think the terms in 17-087 are not intuitive, but if you read the definitions their semantics is clear).

The discussions referenced in my first comment discuss whether it should be recommended to have different URIs for the real-world phenomenon (feature identifier in 17-087) and a document describing the thing (object identifier in 17-087). The short conclusion: in general, yes. The links above have the longer discussion.

Consistent with this, in most cases in WFS 3.0, the WFS feature URI will be both the 17-087 feature identifier and the 17-087 object identifier.

So, WFS 3.0 is consistent with the SDW recommendations and in my understanding also with 17-087.

---

PS: That said, a WFS could also implement this differently:

• Use the WFS feature URI as the feature identifier and use re-direction to a document URI outside of the WFS API; or
• use the WFS feature URI as the 17-087 object identifier and manage the 17-087 feature identifiers separately from the WFS API; if a 17-087 feature identifier URI is de-referenced, it would re-direct to the WFS feature URI , i.e. the 17-087 object identifier.

In both cases this is costly (an extra http connection for every access, additional management of URIs) and often has no practical benefits.

[PeterParslow]

@cportele, please check / clarify the response above (12 Apr). In the second multi line paragraph, you conclude that in general, "it should be recommended to have different URIs". But then in the next little paragraph, you say "Consistent with this, in most cases ... the WFS feature URI will be both".

So, in general they should be different, but it is consistent with that to use the same URI for both?

[cportele]

Argh - thanks @PeterParslow for pointing this out!

Instead of "The short conclusion: in general, yes" it should be "The short conclusion: in general, no".

Best Practice 1 of the Spatial Data on the Web Best Practices, has the following discussion about this (the bolding is mine; there is also more about URIs in the rest of the BP, including a discussion about the use of sameAs):

When an HTTP URI is dereferenced, the server will respond with a sequence of bytes: by its nature, HTTP can only serve information resources such as Web pages or JSON [RFC7159] documents. Yet a Spatial Thing is actually a real or conceptual phenomenon - a lake is made from water not information! Using a single URI to refer to both the Spatial Thing and the page/document that describes the Spatial Thing introduces a URI collision. This can impose a cost in communication due to the effort required to resolve ambiguities. [URLs-in-data] has more to say on this subject, including recommending URI design patterns that enable differentiation between the Spatial Thing and the page/document that describes it.

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. As stated in [WEBARCH] section 2.2.3 Indirect Identification, identifiers are commonly used in this way. There is no obligation to distinguish between the Spatial Thing and the page/document unless your application requires this.

[PeterParslow]

Glad to be of service :). In general, I'm really impressed by this. I expected to be, but have to admit it's the first time I've made time to actually read it!

[cportele]

13-MAY-2019 conference call: Discussion is settled, close the issue.

[akuckartz]

Architecture of the World Wide Web, Volume One states:

It is important to avoid URI collision.

[cportele]

@akuckartz - No disagreement about the need to avoid URI collisions. The discussion basically discussed the two types of identifiers in the context of the Web architecture and WFS / OGC API Features and found no problem in the current spec. The thread opener, therefore, proposed to close the issue, which we did.