New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
vholland opened this Issue Apr 14, 2017 · 10 comments

Comments

Projects
None yet
5 participants
@vholland
Contributor

vholland commented Apr 14, 2017

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.

@vholland vholland self-assigned this Apr 14, 2017

@rvguha

This comment has been minimized.

Show comment
Hide comment
@rvguha

rvguha Apr 14, 2017

Contributor
Contributor

rvguha commented Apr 14, 2017

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 4, 2017

Contributor

+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?

Contributor

danbri commented May 4, 2017

+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?

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland May 4, 2017

Contributor

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.

Contributor

vholland commented May 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 4, 2017

Contributor

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.

Contributor

danbri commented May 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tmarshbing

tmarshbing May 5, 2017

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

tmarshbing commented May 5, 2017

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

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland May 5, 2017

Contributor

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

Contributor

vholland commented May 5, 2017

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

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 9, 2017

Contributor

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.

Contributor

danbri commented May 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry commented May 9, 2017

@danbri very mello :)

vholland added a commit to vholland/schemaorg that referenced this issue May 9, 2017

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland May 9, 2017

Contributor

See pr #1615

Contributor

vholland commented May 9, 2017

See pr #1615

danbri added a commit that referenced this issue May 9, 2017

Merge pull request #1615 from vholland/email
Issue #1590: Added bccRecipient, ccRecipient, and toRecipient
@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 9, 2017

Contributor

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

Contributor

danbri commented May 9, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment