I have use cases to do the same for email now. For example, I have data sets where email is stored at the location, which is not supported today. Using either email.location_id or email.link_id && email.link_entity=’location’ would solve that issue and cover many other use cases to boot.
A proposal for this seems very straight forward, and would follow the same basic patterns as the URL table.
@mrshll@MikeThacker@devin@bloom@sasha I formally propose we write up a proposal and discuss where this falls on our roadmap. Do I have a second? Can we add this to the agenda for our next call?
Adding an email schema in the same vein as we did the url schema is very straightforward at a technical level. We’ll need to determine which relationships we want it to have, and what properties we think an email schema should have (probably not many).
Considering other objects as well, the following schemas contain explicit email properties which we can’t remove without a MAJOR upgrade:
organization.email (there also exists organization.contacts, which will each have an email property)
service.email (there also exists service.contacts, which will each have an email property)
contact.email
Intersestingly, the location schema has the location.contacts property which is an array of contact objects (source), meaning that we can transmit emails attached to locations via location.contacts.email. Would this address your use-cases? It might require some business logic to go about transforming how it’s stored in the database to the HSDS, but I’d like to rule this out before we add another schema.
I’m also keen to hear more about these other use-cases, so that we can build a solid case for the need for this. Once we’ve done that, I’d be very happy to second it. Definitely happy to have this discussed at the next technical committee call as well (we should make sure to copy the notes from that into this thread so they’re visible, too).
To be clear, I believe that there likely is a need for this but I think we should go about articulating it first to rule out the features we already have, and then work that into the proposal.
Further reflecting/musing, I think this feeds into my belief that the next MAJOR upgrade of HSDS (which we haven’t even begun discussing yet), should explore the possibility of modelling service as a “top-level object”. Everything hanging off of service would drastically simplify both the data model and the API, and would mean that we can totally decouple the transmission medium (HSDS) from the storage implementation (normalized databases).
I think the use cases for this are weaker than they were for, say, phones, so I’ll just put that out there. Email is used much less frequently as a primary means of contact for services (at least for most of my clients). However, to the extent that it’s started coming up more frequently, it prompted me to wonder why our contact methods aren’t handled in a standardized way. Email would seem to be the last one that’s not normalized at the tabular level.
I really love having the phone and URL tables broken out separately, because it provides the opportunity to include descriptions, types, and other useful meta info that can be used to improve the experience in user facing solutions like our Resource Directory.
Is that an adequate use-case?
I wouldn’t say that adding an email object is a major impetus for speeding up our next major release, but I definitely think we should include it in our next major release when that’s ready.
