itemType default

[cportele]

This issue has been created as part of the public review and is based on document 19-072. See in particular section 9.2.2.

If the default of "itemType" is "unknown", Features can not extend Common Collections as the default is "feature" in Features (for compatibility reasons).

[joanma747]

IMHO, OGC API common should not define "items"; it should define only "collections" (see #110). If there is no "items" it makes no sense to define a property itemType that applies to a thing that does not exist. itemType should be removed from "commons"

[cportele]

I see this a bit differently. The Collection and Item(s) resource types are strongly connected. If you have a collection, there are items (by definition).

Whether the items are made available via the API is another topic. I.e., I agree that the Items resource type defined in 9.2.3 (if it is not removed) does not belong into the same requirements class as the Collection(s) resource types, at least in Common.

[dblodgett-usgs]

I think we've determined that a collection doesn't have to have an items distribution but I also see an argument to keep items in common (so records can use it directly for example) unless items will always be an extension of features core?

[cmheazel]

I suggest that:

1. We remove the default value for itemType
2. We keep the itemType property since it conveys the nature of the items in the collection
3. We keep the /items resource path (section 8.1.3) but define it as a stub to be further defined by implementing standards. That is, GET /items will return a 200 but we don't define what the payload will be.

[cmheazel]

On the working branch -
itemType no longer has a default.
/items has been retained as an integration point. The requirements are minimal and designed to be extended.

[cportele]

If itemType is defined in Part 2, it should have the default "feature". Otherwise, if there is no itemType member, but there is an items link, how do clients know, what type of resource they will get back when following the link? Or is the idea that every API must define the default and clients have to inspect the API definition to retrieve the default? If yes, this should be made explicit.

[cmheazel]

@cportele Your original point was valid. By defining the default for itemType we place an unnecessary constraint on the API standards which build on Common. We have fixed that.

The broader question is how does Common and the extending standards fit together? I think that is the topic of another issue which I will create shortly. We can address itemType defaults there.

Also, I will attempt to identify and link into that issue all previous issues that contain relevant discussions. Don't want to loose those perspectives.

[pvretano]

See opengeospatial/ogcapi-features#539
Probably covers a lot of the discussion here but this is the way I thought about so it might be helpful ... or not! ;) ...I'm playing catch up...

[joanma747]

Please change:
"A Collection Description describes a collection of items. The itemType property identifies the type of item which has been collected."
to:
"A collection can be accessed by enumerating items. In this case, the itemType property in Collection Description identifies the type of item."

[cmheazel]

@joanma747 Change applied.

[cmheazel]

Recommendation 2 still refers to the /items path. Make sure that all necessary changes have been made.

[cmheazel]

Performed general scrub for consistent use of item and items.
Note: the scope statement may still need some work. Comments?

[cmheazel]

June 26, 2021 - close - NOTUC