Closed pvretano closed 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.
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
Closes #103
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.
@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.
@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
@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.
I think we should remove providers and only specify contacts. If STAC aware applications wish to add providers, they can do so without impact.
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... :-(
27-APR-2023: party.yaml will be renamed to contacts.yaml after merge.
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.