Providers: Change to more generic contacts?

[m-mohr]

Moving the "providers vs contacts" discussion from https://github.com/opengeospatial/ogcapi-records/issues/178 to a separate issue:

Question: what would the distinction between "providers" and "contacts" be in STAC? Maybe if I understand that I can propose changes to bring STAC and records closer together on this point.

So providers in STAC is really in the sense of "provided something" (reflected in the roles: licensor, processor, producer, host). And in this case really just the basics (url with additional details, name, role, description).

Contacts I'd see more as a general construct to provide contact details of related organizations or persons, which can include a lot more information. Could be a administrator, public relations manager, project officer, other contributors or maintainers, ... So this is far more advanced and less restricted than providers. And it will not be core, but an extension.

Having that said I'd like to get to an alignment with between OAR and STAC that doesn't lead to problems in implementation due to differences. STAC clients would expect a name, could we require this in both schemas OAR allows? On the other hand, OAR would expect a url and that might not be present in STAC so OAR clients could also error. Not sure how to fix that. I assume a roles array with free-form roles is not ideal, but also shouldn't lead to too many issues downstream.

So I'm wondering whether we should try to align this so that it doesn't lead to issues or split the definitions (which would mean OAR would need a different field name). I could see adopting the OAR definition for the contacts extension, but that would mean that OAR would need to switch to a "contacts" field name, which I feel is the better term anyway for OAR...

Related issue: #227

[m-mohr]

My thoughts right now are:

Create a new field "contacts" which allows two schemas in the array:

• A Link object (or don't allow it here and add it to the links array?)
• A Contacts object (that's the second schema of party.yaml with all the detailed fields)

This means it doesn't need to be compliant with STAC and is free to follow an established standard for this without taking over e.g. a too strict "roles" array. STAC would adopt this field as an extension 1:1 as defined in OAR.

STAC can keep a "strict" providers array, which OAR can or can not adopt 1:1.

What do y'all think?

[tomkralidis]

+1 to rename properties.providers to properties.contacts.

[pvretano]

@m-mohr yes, that sounds like a reasonable approach to me. I'll add it to the harmonization PR that I am working on.

[tomkralidis]

Update from OARec discussion at the Open Standards and Open Source Software Code Sprint.

• add an annex for contact role code examples (similar to the annex on resource types). This can provide suggestions for communities looking for guidance, while not constraining those who already have these in place.