Closed m-mohr closed 1 year ago
My thoughts right now are:
Create a new field "contacts" which allows two schemas in the array:
links
array?)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?
+1 to rename properties.providers
to properties.contacts
.
@m-mohr yes, that sounds like a reasonable approach to me. I'll add it to the harmonization PR that I am working on.
Update from OARec discussion at the Open Standards and Open Source Software Code Sprint.
Moving the "providers vs contacts" discussion from https://github.com/opengeospatial/ogcapi-records/issues/178 to a separate issue:
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