Identifying different record types

[ilkkarinne]

This is probably just me being fresh in the API Records spec, but how should one define and advertise different record types in API Records?

I'm working on an idea of defining extensions of the core queryables set of the properties for the records schema, such as properties from the (Geo)DCAT and implementations of the Observations, Measurements and Samples (OMS) concepts. That would probably mean using more than one record schema within a single API Records implementation (ObservationCollection record, ObservableProperty record etc.). I guess it would be clearest to allow only one record type (itemType?) per collection, but which properties should I use for describing the record schema used inside a particular record instance?

For the GeoJSON / JSON-FG format records the mandatory properties.type seems to be reserved for a natural language description of the resource type, not the record type. Should I use the top level featureType of the record GeoJSON feature like the following?

{
   "type": "Feature",
   "id": "obscollrec-1",
   "featureType": "oms:ObservationCollectionRecord",
   "time": {
      "interval": [
         "2014-04-24T10:50:18Z",
         ".."
      ]
   },
...

If yes, how would I best declare the record type allowed for a particular collection in the collection metadata (the itemType is fixed to "record")?

[pvretano]

@ilkkarinne in Records there is only one record type per se (i.e. the record). It is a set of properties that descibe some resource that is intended to be discoverable. There is the core set of properties that are described in the specification and then users/communities of interest/etc. of the specification can extend that core set with additional properties as needed. There is no way to distiguish one set of core+extension properties from another set of core+extension properties. It is heterogeneous ... just like features in the Features specification are heterogenous. This is why itemType is fixed to record ... everything in the catalogues is just a record.

However, I can see the utility in being able to make such a distinction so I propose that we add a properties.recordType property to the core set of properties to allow such distinctions to be made. If you are in agreement, I'll raise the issue at the next SWG meeting.

[ilkkarinne]

Thanks @pvretano, I think having an optional the properties.recordType to the core queryables would indeed be useful.

However, as knowledgeable client I would also like being able to determine the record type of records in a collection from the Collection schema. This way I could be prepared to parse the resultins of an ìtems query without testing the existence of properties.recordType value of each record separately. I do see the benefit of keeping the itemType="record" as a simple distinction from other collections (such as features), so could there be a recordType property also in the Collection schema?

[pvretano]

@ilkkarinne I'll raise the recordType-in-the-collection-object in the SWG too...

[pvretano]

06-MAR-2023: SWG likes the idea of being able to indicate in a record which "extensions" are being used. However, the SWG is not so keen on the propertie.recordType proposal. Instead they would prefer we use an extensions mechanism similar to STAC. So if, for example, a record is extended with GeoDCAT elements, the extensions section can list that the GeoDCAT extension was used. (Have to run off to another meeting but will update this issue later today with additional details).

[m-mohr]

Isn't this basically just a conformance class list but in the childs? If you just allow conformsTo in every entity Record (similar to how STAC API also already includes conformsTo in the landing page) you just re-use what's already out there with minimal overhead.

[ilkkarinne]

I like @m-mohr 's idea of using the existing conformsTo top level property of a record. This seems to be supported already in the Record schema of Requirement 46 of 20-004 (9.18.2. Response).

However, the conformsTo does not seem to be supported in the Collection schema. I would guess that in most cases all the records within a single collection would support the same record type(s).