search

opengeospatial / ogcapi-records

An open standard for the discovery of geospatial resources on the Web.
https://ogcapi.ogc.org/records
Other
58 stars 27 forks source link

Change "providers" to "contacts" to align better with STAC, ISO19115, etc. #230

Closed pvretano closed 1 year ago

pvretano commented 1 year ago

This change allows STAC to keep it's "providers" array as is and aligns Records with STAC, ISO19115 and other specifications that use the term "contacts" for this information.

Closes #228.

m-mohr commented 1 year ago

Thanks, I'll take a look next week and try to create a STAC extension based on it and give feedback then.

pvretano commented 1 year ago

21-APR-2023: From the party.yaml schema, it originally was a oneOf that allowed either a reference to contact information or this big long object that provided explicit in-line information about the contact. Problem is that for this "big long object" the only required field was name and it also included the ability to link out to information about the contact. So why have a seperate object for references? If someone wants to "reference" contact info, they simply provide the name and the link information (in contacts.contactInfo.url) and it provides exactly the same capability.

Closes #227

pvretano commented 1 year ago

Closes #103

cnreediii commented 1 year ago

OK, I have to ask . . . What is the relation (or not) to vCard (https://datatracker.ietf.org/doc/rfc6350/). And if no relation or possibility of using, why not? A vCard has a .VCF extension and is supported by Microsoft Outlook (98-2019), Mozilla Thunderbird as well as most mobile clients. And governments such as the UK recommend using vCard. Which makes it a surprisingly well supported format for storing contact info - even though some folks consider it obsolete.

pvretano commented 1 year ago

@cnreediii the information about a contact can be encoded in-line in the record OR referenced. If it is referenced, the specification recommends that it reference a vCard. I don't think anyone considered actually encoding the vCard inline in the record. A change like that would need to be discussed in the SWG but it would certainly make the specification shorter since we could just reference the RFC.

cnreediii commented 1 year ago

@pvretano Thanks. Should have been more clear. I was also thinking of vCard by reference and not inline. Same as license discussion. Missed that the draft already suggested vCard. Sigh

pvretano commented 1 year ago

@tomkralidis added it because @m-mohr suggested we might consider adding it for STAC alignment. I believe that STAC is planning to include both providers and contacts (as an extension). It is my understanding that providers are related to the creation, processing or storing of the the resource(s) that the record is describing. Contacts are other related parties but not involved in the creation, processing or storage of the resource directly. The distinction seems a little subtle to me but we can easily remove providers if people think is it superfluous.

tomkralidis commented 1 year ago

I think we should remove providers and only specify contacts. If STAC aware applications wish to add providers, they can do so without impact.

m-mohr commented 1 year ago

Yeah, you can also offer it to your users, but I think on Friday you said you would add it as extension and I think that's reasonable. providers doesn't need to be in the core.

Thanks for all the updates, @pvretano. I'll look into the other reviews and comments in the next days, but now I first need to get rid of COVID... :-(

pvretano commented 1 year ago

27-APR-2023: party.yaml will be renamed to contacts.yaml after merge.