Add a way to distinguish to: cc: and bcc: in EmailMessage

[vickitardif]

http://schema.org/EmailMessage currently has the http://schema.org/recipient property for specifying who received the message. Sometimes it is useful to be able to break out whether the recipient was cc'ed or bcc'ed on the message.

I propose adding the following subproperties to http://schema.org/recipient:

• to_recipient: The Person or Organization the message was directly sent to.
• cc_recipient: The Person or Organization copied on a message.
• bcc_recipient: The Person or Organization blind copied on a message.

[rvguha]

About time :) guha

[danbri]

+1 for something like this change.

Actual email messages record more than this, you get a formatted string with an email address plus supporting label; you also know what the order was. Currently we only indicate the receiving person but not as far as I can see, even which of their email addresses were used.

We don't have an email address/account type (http://schema.org/email just expects Text).

Feels like we had this discussion already once before around http://schema.org/DigitalDocumentPermission and we settled on some use of Audience and ContactPoint, where the latter serves as a kind of supertype for a non-existence EmailAccount type.

@vholland does the usecase you have in mind care only about which person/org got the message, or also about which email account(s) it was addressed to?

[vickitardif]

I was thinking the range would be Person, ContactPoint, or text. Text would serve the role where the email address is the only thing known. It seems a waste of an author's time to create a ContactPoint simply to provide an email address.

[danbri]

Ok, we'll tweak the above then to adapt to that. I agree re ContactPoint (unless you wanted to record both naming string and the actual email, in which case using two fields of a ContactPoint seems slightly nicer).

Another detail, you've suggested to_xyz but we're camelcase everywhere else as far as I remember.

@nicolastorzec @chaals @tmarshbing @scor are you ok with this? Seems straightforward enough to me, with these clarifications.

[tmarshbing]

+1 The proposal seems straightforward and useful. I agree with using camel case.

[vickitardif]

+1 on the camel case. The underscores were due to spending time in a different ontology recently.

[danbri]

Ok, since this seems pretty much "no brainer" and a tweak to established vocabulary I suggest we make the change directly in schema.org core. For other areas where a proposal is relatively new / distinct I'm putting things into pending first, but in this case I think that would be melodramatically unnecessary.

[thadguidry]

@danbri very mello :)

[vickitardif]

See pr #1615

[danbri]

Merged (into evolving next-release candidate). Thanks @vholland, all!

[vickitardif]

Done in schema.org 3.3.