Is every Feature required to have an id?

[jampukka]

Inspired by #121 and #122

Is there a requirement that every feature must have an id? Requirement 30 states that every feature in a feature collection must be available at path "/collections/{name}/items/{id}" so I'd argue yes. However, atleast in the GeoJSON schema for a Feature (featureGeoJSON.yaml) we don't specify the 'id' property as required. Thoughts?

[cmheazel]

In a RESTful world, every resource (Feature) has a unique and resolvable URL. This means that there needs to be a property that is mandatory for every Feature and has a value unique to that Feature. Thus the Feature id is mandatory.
I would go one step further. Data has a long lifetime. The Feature you create today may still be in use 30 years from now. The system it resides on probably won't. Therefore, the Feature id must be globally unique, temporally unique, and independent of hosting system. That is to say, that there is no other Feature in existence with this id and there never will be. The X.667 UUID meets this requirement (or at least comes as close as we are going to get) and I advocate its use as the Feature id.

[nmtoken]

In a RESTful world there's a requirement for uniform ways of addressing resources, but not for there to be unique identifiers. The identifiers may change on every request, as determined by the server that sends out the requested hypermedia. In a RESTful world the client has no knowledge of the structure of the URLs, just the location in the hypermedia of where to find the links.

…

-----Original Message----- From: Chuck Heazel <notifications@github.com> Sent: 25 May 2018 04:31 To: opengeospatial/WFS_FES <WFS_FES@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [opengeospatial/WFS_FES] Is every Feature required to have an id? (#139) In a RESTful world, every resource (Feature) has a unique and resolvable URL. This means that there needs to be a property that is mandatory for every Feature and has a value unique to that Feature. Thus the Feature id is mandatory. I would go one step further. Data has a long lifetime. The Feature you create today may still be in use 30 years from now. The system it resides on probably won't. Therefore, the Feature id must be globally unique, temporally unique, and independent of hosting system. That is to say, that there is no other Feature in existence with this id and there never will be. The X.667 UUID meets this requirement (or at least comes as close as we are going to get) and I advocate its use as the Feature id. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#139 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/ABnU23GlrYvE4HTEcpd8rdqEeGfDGKebks5t13r3gaJpZM4UNHE9> . <https://github.com/notifications/beacon/ABnU23Cba-_RMNRC_HADr1rovQ-PgBwtks5t13r3gaJpZM4UNHE9.gif>

________________________________ This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

________________________________

[jvanulde]

@nmtoken agree that identifiers need not be unique but they should be persistent.

[ilkkarinne]

I completely agree, that in most cases the persistent references to created Features are really useful, and thus it makes sense to mandate having them.

However, sometimes the Features are only used as intermediate, transient entities between the data streams / databases of big or rapidly changing data stores, like environmental observations, where the ID of the particular provided Feature is not very important: the Feature instances may be aggregated from the underlying data and created on-the-fly for each user request, and it may not be feasible to require that the exactly same Feature instances can be retrieved again later. In these cases one could of course argue that a transient Feature like this is no longer an abstraction of a real-world spatial object.

In the meteo WFS cases I have been involved in, the feature IDs are often aggregated from the underlying data objects (observation time, numerical weather model run time) and the requested quantities and locations. When a user makes a new request some time later using the same feature ID, the data may or may not be available anymore, and even if It's still there, the properties may have changed (due to corrected data etc.). In a typical case the users discard the IDs and just create a new request with the same request parameters to get the best available data for the area and time in interest.

[cportele]

@ilkkarinne - I see the point. Maybe this could be addressed by stating in the collection metadata an expectation how stable the features are? This could inform clients, if it makes sense to use links to individual features or if it is better to use filters to select the relevant features are a given location/time.

[pvretano]

@ilkkarinne @cportele What I am about to propose is not part of the specification but it could be an extensions. I would approach this as a stored, dynamic feature (i.e. a view). It is assigned a feature id like any other feature but when that id is accessed, a stored query is run that re-materializes the feature based on the latest underlying data. Sort of a stored query from WFS 2.X. I don't know ... does this make sense in this case?

[jvanulde]

https://www.w3.org/TR/2017/REC-dwbp-20170131/#dataPreservation

[rcoup]

@pvretano

I would approach this as a stored, dynamic feature (i.e. a view). It is assigned a feature id like any other feature but when that id is accessed, a stored query is run that re-materializes the feature based on the latest underlying data.

Couldn't you just have this as a regular feature collection? WFS & clients don't need to know whether features are static, dynamic, materialised on the fly, or something else?

[pvretano]

@rcoup Yes, that is exactly my point ...

[cmheazel]

@jvanulde This is a very good start. But it doesn't go quite far enough.
Digital Equipment Corporation (DEC) had an active research arm which produced a library of very good technical reports (TR). These reports were available from their Website. DEC is long gone, as well as their domain name and web servers. Yet the technical reports are still cached throughout the web. How to find them? The W3C recommendation doesn't help us here.

Fortunately, each TR has a unique identifier. So no matter where or when they reside, you can still reference and find them.

I realize that this level of persistence is not required of all Web resources, but it is more common than you would think.

[ilkkarinne]

Core requirements the mandatory feature ID and the "get-feature-by-ID" operation in the WFS3 core cannot be easily laxed in backwards-compliant extensions (generic WFS3 clients will probably rely on them being available).

Based on this discussion, I would like to draw two conclusions:

1. Requiring an ID property alone is not enough fulfil the persistence, resolvability and uniqueness aspects for (RESTful) features.
2. Persistent, resolvable and unique feature IDs are not very useful in some WFS3 use cases.

What if we extract the ID property and the "get-feature-by-ID" operation in an extension released simultaneously with the core? Services implementing this extension could then be automatically assumed to provide the RESTful feature persistence and resolvability semantics. The extension would also be a great place to document these REStful semantics in enough detail.

Services not implementing this extension could be made simpler in this aspect and be used also for non-persistent, non-referenceable feature data (like current GeoJSON Features without IDs).

[cportele]

13-MAY-2019 Conference call: We need to have a stable URI for each feature. But the Core has no requirement that the feature encoding must include an id property, for example, there is no requirement in the Core that the GeoJSON encoding includes an id member (even if it is good practice to include id members).

Regarding the other discussion in the thread ("persistent, resolvable and unique feature IDs are not very useful in some WFS3 use cases"): you should always be able to define a feature id mechanism for the virtual features that are created on the fly. It is up to the server to enumerate the virtual features.

[jampukka]

So the resolution for req/geojson is that the id member is not required for each feature but is a good practice? My understanding was that the client could determine the stable URI for each feature by just appending the id of the feature to the /collections/{collectionId}/items/ path but that's problematic if the id isn't there.

[cportele]

To use the id member for this purpose would require out-of-band knowledge and would be a GeoJSON-specific and not very "webby" approach. That said, I think using the id in that way works in most deployments that I have seen.

Instead, /req/core/f-links requires that each feature response (/collections/{collectionId}/items/{featureId}) has to include a self link in the response.

However, the self link is not required in the features in the feature collection response (/collections/{collectionId}/items). I guess we should require or at least recommend self links for each feature in the feature response, too. @pvretano, @cmheazel?

[cportele]

20-MAY-2019 Conference call: If we add too many requirements, make too many aspects mandatory, are we getting away from keeping it simple? Maybe yes. Adding self links is straightforward as is providing an id member in GeoJSON, if servers see a use. Maybe leave it for now as it is.

[cportele]

Conference call, 3 June 2019: Closing this issue as there was no further discussion. If new aspects are to be considered, the issue can be reopened.