Difference between revisions of "WebSchemas/EmailMessageSchema"
Revision as of 22:11, 11 May 2013
This page tracks a proposal to extend schema.org's vocabulary, adding a simple EmailMessage type alongside the existing WebPage type.
The original proposer is Yaar Schnitman (email@example.com). Discussion on this proposal is encouraged on firstname.lastname@example.org, here in the WebSchemas Wiki, or by direct email.
Next step (alongside public-vocabs discussion) is to generate a machine-readable schema definition.
- add new type EmailMessage, a subtype of CreativeWork
- description: "An EmailMessage".
Note that the current definition of WebPage says "A web page. Every web page is implicitly assumed to be declared to be of type WebPage, so the various properties about that webpage, such as breadcrumb may be used. We recommend explicit declaration if these properties are specified, but if they are found outside of an itemscope, they will be assumed to be about the page.".
Therefore we might say:
Every email message is implicitly assumed to be declared to be of type EmailMessage, so the various properties about that email message, such as author or action, may be used. We recommend explicit declaration if these properties are specified, but if they are found outside of an itemscope, they will be assumed to be about the email message.
Alternatively the idea of defaulting could be reformulated to avoid dependency on Microdata syntax details. For example:
- "Many instances of this type might be identifiable as such without explicit markup. Systems that know a document is an EmailMessage can use this type to record that conclusion explicitly."
- ...and similar for WebPage, to keep consistency. However with WebPage we also want to say "The presence of properties defined on WebPage can in many contexts be taken to indicate that the entity they describe is the current document, and that it is of type WebPage". For EmailMessage this is less necessary as no properties are currently defined.
- More metadata about emails will be useful for various applications. For example, CreativeWork.author could provide more details about the email's sender: phone number, company, address and url. CreativeWork.description could be used for better email snippets.
- If we are to embed schemas in emails (e.g. such as Event schemas) there needs to be a corresponding top level element, just like we have WebPage for web pages.
- No other properties beyond what's inherited from CreativeWork are introduced at this point. New properties, such as to, cc, and bcc may be introduced in the future, purposed to enhance the already existing mime header fields with more metadata. Suggestions welcomed here.
Related work: there have been many prior attempts at representing email structures in RDF. The early Mozilla RDF work, for example. See EmailVocabulary entry for earlier work. This current effort does not attempt a complete representation of email, but rather creates a basic representation within schema.org that might be extended later.