GMEOW Email Module

• IRI: https://blackcatinformatics.ca/gmeow/slices/email
• Tier: extension
• Group: extensions

What This Slice Covers

This slice owns 168 terms and contributes 41 mapping or projection rows. Use it when its terms match the native fact you want to preserve; use the linkage tables to see how those facts leave GMEOW for consumer vocabularies.

Dependencies

• gmeow:slices/accounts
• gmeow:slices/contacts
• gmeow:slices/documents
• gmeow:slices/entities
• gmeow:slices/events
• gmeow:slices/kernel
• gmeow:slices/temporal
• gmeow:slices/trust

Consumers

• The mail corpus: the dogfooded message model over core contacts/accounts.

Local Map

Examples

Message Thread

• Source: slices/extensions/email/examples/message-thread.ttl
• GMEOW terms: gmeow:EmailAddress, gmeow:EmailMessage, gmeow:addressValue, gmeow:cc, gmeow:from, gmeow:inReplyTo, gmeow:subject, gmeow:to

# SPDX-FileCopyrightText: 2026 Blackcat Informatics® Inc. <paudley@blackcatinformatics.ca>
# SPDX-License-Identifier: CC-BY-4.0
#
# Worked example: an email message and its reply . A gmeow:EmailMessage
# carries the RFC 5322 envelope as first-class edges to gmeow:EmailAddresses —
# gmeow:from, gmeow:to, gmeow:cc — plus a gmeow:subject. Threading is a relation
# between messages, not a flat field: a reply points at what it answers with
# gmeow:inReplyTo, so the conversation graph is reconstructable from the messages
# themselves. The EmailAddresses are the reified gmeow:ContactPoints of the
# contacts slice — the same objects a person reaches mail through.
@prefix gmeow: <https://blackcatinformatics.ca/gmeow/> .
@prefix ex:    <https://blackcatinformatics.ca/gmeow/examples/email/> .

ex:aliceAddr a gmeow:EmailAddress ; gmeow:addressValue "alice@example.org" .
ex:bobAddr   a gmeow:EmailAddress ; gmeow:addressValue "bob@example.org" .
ex:carolAddr a gmeow:EmailAddress ; gmeow:addressValue "carol@example.org" .

# --- The original message: Alice → Bob, cc Carol.
ex:msg1 a gmeow:EmailMessage ;
    gmeow:from    ex:aliceAddr ;
    gmeow:to      ex:bobAddr ;
    gmeow:cc      ex:carolAddr ;
    gmeow:subject "Ontology review draft" .

# --- Bob's reply: points at msg1 via inReplyTo (the thread is in the graph).
ex:msg2 a gmeow:EmailMessage ;
    gmeow:from      ex:bobAddr ;
    gmeow:to        ex:aliceAddr ;
    gmeow:subject   "Re: Ontology review draft" ;
    gmeow:inReplyTo ex:msg1 .

Terms

Classes

Properties

Individuals

Linkages

• Rows: 41
• Projection profiles: sioc
• External vocabularies: ical, nmo, rdf, schema, sioc, wd

Guide

Gmeow mail_message → GMEOW mapping

How the gmeow mail store's mail_message facet (and its compound parts) maps to GMEOW email terms, so the importer can emit GMEOW RDF. Each email becomes a gmeow:EmailMessage; participants are reached through gmeow:EmailAddress (the seam to people and accounts); residence and address tenure are time-scoped.

Facet metadata fields

¹ Gmail system labels split: INBOX/SENT/DRAFT/SPAM/TRASH → a gmeow:Mailbox with gmeow:mailboxRole (inbox/sent/drafts/junk/trash) reached by gmeow:residesIn (time-scoped via gmeow:MailboxResidence); UNREAD/STARRED → gmeow:hasKeyword (keywordSeen absent / keywordFlagged); CATEGORY_* → keywords.

Compound parts

Derived artifacts (text extraction, AI summary, embedding) are separate gmeow:InformationObjects linked to the attachment/body by gmeow:wasDerivedFrom, carrying gmeow:confidence and gmeow:wasGeneratedBy (a gmeow:SoftwareAgent).

Raw message provenance

The complete RFC 5322 byte stream — the "envelope" from which headers, body, and attachments are parsed — is itself a first-class artifact. It is not a property of the parsed EmailMessage; it is a gmeow:Manifestation (or more generally a gmeow:InformationObject) that the message was derived from (Principle 4: one canonical source, never duplicate).

Raw artifact

The raw message artifact is content-addressed: two identical byte streams share the same gmeow:contentDigest regardless of where they were found. The carrier mtime (sourceModifiedAt) is a terminus-ante-quem on the recording of the claims the bytes carry — it is NOT the message's sent time, received time, or import time (Principle 9: four distinct clocks, never collapsed).

Derivation and import activity

The parsed EmailMessage is linked to its raw envelope via the cross-cutting provenance spine:

This mirrors the pattern used for vCard, GEDCOM, and every other import envelope in GMEOW: the envelope is a Manifestation with contentDigest; the import is an ImportActivity with ingestedAt; the parsed entity is derived from the envelope and generated by the activity.

The four-clock model

Email involves four separate times that must not be conflated (Principle 9):

The Date header may be forged or absent; sentAt records the header value as a claim, not as ground truth. The provider receive time (receivedAt) is observationally distinct and typically more reliable. The carrier mtime and import time are system bookkeeping — they never override the message's own temporal claims.

Provider external IDs and versions

Provider-specific identifiers (Gmail message ID, archive path, maildir filename) are not the message's canonical identity — the RFC 5322 Message-ID (gmeow:rfcMessageId) and content digest (gmeow:contentDigest) are. Provider IDs are provenance metadata and are recorded with the existing cross-cutting identifier property:

MIME body part metadata

GMEOW models the MIME body-part tree using the existing BodyPart / Attachment / hasBodyPart spine, with the universal hasPart / partOf relation for internal multipart structure (Principle 12: decoding and reconstruction are computations, not OWL entailments).

Multipart structure. A gmeow:MultipartBodyPart is a BodyPart that contains other body parts via hasPart / partOf. The multipart subtype is recorded with hasMultipartType. Child parts may be BodyPart, InlinePart, or Attachment instances.

Inline parts. A gmeow:InlinePart is a BodyPart displayed inline within the message body. It is reached from the message via hasInlinePart (a subproperty of hasBodyPart). An inline image in an HTML message is an InlinePart with contentDispositionInline and a contentId referenced by a cid: URL.

Disposition. InlinePart and Attachment are not declared disjoint (Principle 9). The explicit disposition is recorded with hasContentDisposition; the kind is a separate facet that may or may not align with the disposition value.

Decoded content. Decoded plain-text or HTML body content is not stored as a literal property on the part. Instead, it is modeled as a derived gmeow:InformationObject (typically gmeow:TextExtraction) linked to the source BodyPart by gmeow:wasDerivedFrom, carrying provenance and confidence (Principle 12).

JMAP structural identifiers

JMAP (RFC 8620 / RFC 8621) exposes blobId, partId, and bodyStructure as message-addressing identifiers. GMEOW maps them without letting the JMAP projection become a competing canonical model:

Opaque identifiers. blobId is treated as opaque even when gmeow happens to back it with a content digest. When byte-exact content identity matters, also assert gmeow:contentDigest on the relevant BodyPart or raw artifact.

Message-scoped partId. A partId such as 1.2 identifies a part only within its containing EmailMessage / BodyStructure. The same raw content can carry different partIds in different messages.

bodyStructure is a projection. The serialized JMAP BodyStructure is preserved for importer round-tripping, but the canonical semantic MIME tree remains the hasBodyPart / hasPart / partOf spine from the design. Do not model the same structure twice.

Decoded content as object. A gmeow:BodyValue is a decoded content object linked to its source BodyPart by the existing wasDerivedFrom provenance property. It is not a literal on the part, and it is not a separate competing tree.

Threading

References / In-Reply-To headers → gmeow:references / gmeow:inReplyTo (→ gmeow:EmailMessage); thread_id → gmeow:partOfThread.

Thread subject normalization

The raw gmeow:subject is the canonical RFC 5322 Subject header (Principle 4). Threading systems (JMAP, IMAP, Gmail) strip reply/forward prefixes (Re:, Fwd:, AW:, SV:, etc.) to group messages into conversations. GMEOW models the result of this normalization explicitly:

• gmeow:threadSubject — the base subject, attached to the gmeow:Thread. This is a derived display value, not an identity key.
• gmeow:subjectPrefix — the prefix(es) removed from an individual message's subject. Non-functional; nested prefixes produce multiple values.

Prefix stripping and base-subject computation are importer/projection behavior (Principle 12). The algorithm follows RFC 5256 § 2.1 base-subject rules where applicable, but GMEOW does not mandate a specific implementation; the importer asserts the result.

Trust indicators (forward-looking)

These headers are preserved in rfc822_headers but not yet parsed by gmeow. When parsed, map per the wire-authentication terms (DKIM, Authentication-Results, relay hops — now in the email slice, atop trust's generic signatures):

Participant model: three layers

GMEOW distinguishes three layers for email addresses:

1. EmailAddress — the stable, normalized contact point. Carries structural facts (gmeow:addressValue, gmeow:localPart, gmeow:domainPart) and links to agents (AddressTenure) and accounts (deliversToAccount).
2. MessageParticipant — the contextual occurrence of an address in a message header or envelope. Carries displayName, rawAddressValue, participantRole, participantHeader, and participantOrdinal. Scoped to the occurrence, never a global claim about the EmailAddress. gmeow:displayName is bridged to schema:name by skos:closeMatch (Principle 5), with a scoping comment because GMEOW ties the display name to the occurrence while schema:name is broader.
3. AddressTenure — the time-scoped fact that an agent held an address.

Flat shortcuts vs. reified relator

The existing flat properties (gmeow:from, gmeow:to, gmeow:cc, gmeow:bcc, gmeow:sender, gmeow:replyTo) remain the 80% shortcut. Promote to MessageParticipant when any of the following matters:

• Raw syntax, comments, or quoting must be preserved
• Envelope vs. header distinction (e.g. envelope-from vs. From)
• Resent-* roles
• Display-name variance across messages
• Ordering within a recipient list
• Provenance, confidence, or validation status
• Malformed or spoofed values that must not contaminate contact identity

Normalization rules (importer-side, Principle 12)

• addressValue is the normalized addr-spec (SMTP-lower-case local part, Punycode A-label for IDN domains).
• localPart is the mailbox portion; case-folding and dot-removal are computation-layer concerns.
• domainPart is the Punycode A-label for IDN domains; the Unicode U-label is a projection-downcast concern.
• Malformed or missing addr-specs: participantAddress is omitted from the MessageParticipant; the rawAddressValue retains the malformed text for audit.

Identity & temporal grounding

• An EmailAddress is held by an Agent over time → gmeow:AddressTenure (a gmeow:TimeScopedRelation); the same address gmeow:deliversToAccount an gmeow:OnlineAccount. This is the seam joining message ↔ person ↔ account.
• A message's residence in a mailbox/label is time-varying → gmeow:MailboxResidence (a gmeow:TimeScopedRelation with gmeow:duringInterval); the convenience gmeow:residesIn may carry gmeow:validFrom/gmeow:validUntil as RDF-star annotations for the current/simple case.

Behavioral metadata — MessageKind and raw-header facets

Gmeow ingests complete mail archives including delivery status notifications, abuse reports, read receipts, and auto-generated responses. These categories are overlapping (a bounce is also auto-generated) and are modelled as an open value vocabulary rather than subclasses, so no single category is forced to win (Principle 9).

MessageKind vocabulary

The property gmeow:hasMessageKind relates a gmeow:Message to one or more gmeow:MessageKind values. It is non-functional: a single message may carry multiple kinds.

Raw-header-backed datatype properties

The canonical source for these values is the rfc822_headers part (gmeow:hasHeader → gmeow:MessageHeader). The datatype properties below are convenience projections (Principle 4):

Software agent identification

When the importer parses User-Agent or X-Mailer and identifies the sending software, it may assert:

The raw header value always remains on gmeow:userAgent (Principle 4).

Read receipt / disposition notification

The boolean gmeow:readReceiptRequested is a convenience projection derived from the presence of Disposition-Notification-To. It is intentionally non-functional: different sources or parsers may disagree or strip the header (Principle 9). The canonical underlying fact is the gmeow:dispositionNotificationTo address (or addresses). The raw header is also preserved in rfc822_headers.

Resent header facets

RFC 5322 allows a message to be resent by an intermediary, producing a Resent-* trace block. Address roles (Resent-From, Resent-To, Resent-Cc) are modelled through gmeow:MessageParticipant with the messageRoleResentFrom, messageRoleResentTo, and messageRoleResentCc role values. The non-address trace fields are convenience projections:

The raw Resent-Date and Resent-Message-ID values also remain on gmeow:MessageHeader (Principle 4).

Mailbox hierarchy

Mailboxes form a tree within an account. The canonical hierarchy spine is gmeow:parentMailbox / gmeow:childMailbox, which specialize the universal gmeow:partOf / gmeow:hasPart relations. All other hierarchy-derived values are projection-layer conveniences (Principle 12).

Hierarchy spine

Provider-derived UI state

These are not asserted as canonical facts in the ontology; they are computed by the importer/projection layer and may carry provenance or standpoint annotations when needed (Principles 2–3).

Lifecycle and destruction

A destroyed mailbox is retained, not erased (Principle 10). Use the lifecycle module rather than a boolean flag:

System vs user classification

JMAP isSystem is a provider classification, not an ontic identity distinction. GMEOW does not model this as subclasses (SystemMailbox / UserMailbox) because there is no identity difference — a user-created folder may later be promoted to a special-use role, and a provider may auto-create folders with no standard role (Principle 9).

System/user origin is a projection concern; the canonical signal is gmeow:mailboxRole for JMAP special-use roles (inbox, archive, drafts, sent, trash, junk, templates). A mailbox without a role is treated as user-created by convention.

Mailing-list headers

RFC 2369 and RFC 2919 define a family of mailing-list headers that carry metadata about subscription, posting, help, archiving, and list identity. GMEOW models the list itself as a first-class gmeow:MailingList individual and links messages to it; the header values are convenience projections over the canonical rfc822_headers part (Principle 4).

List identity and message linkage

RFC 2369 command headers

listPost is intentionally a datatype property while the other URI-valued headers are object properties. RFC 2369 §3.4 allows the sentinel value NO for announcement-only lists, which cannot be represented as an object property value. The raw header value remains on gmeow:MessageHeader in all cases.

Example pattern

ex:myList a gmeow:MailingList ;
    gmeow:identifier "<discuss@example.org>" .

ex:msg a gmeow:EmailMessage ;
    gmeow:hasMailingList ex:myList ;
    gmeow:listId "<discuss@example.org>" ;
    gmeow:listSubscribe <mailto:discuss-subscribe@example.org> ;
    gmeow:listUnsubscribe <mailto:discuss-unsubscribe@example.org> ;
    gmeow:listPost "<mailto:discuss@example.org>" ;
    gmeow:listHelp <mailto:discuss-help@example.org> ;
    gmeow:listArchive <https://example.org/archive/discuss/> ;
    gmeow:listOwner ex:listOwnerAddress .

ex:listOwnerAddress a gmeow:EmailAddress .

Calendar invitations and event descriptions (mail-corpus invitation consumer)

When gmeow ingests an email with a text/calendar MIME part or a .ics attachment, the message and the event it describes are structurally linked in GMEOW without duplicating the event model.

Event description bridge

The social act of invitation — organizer, invitee, acceptance/decline status, RSVP — is modeled via gmeow:EventInvitation from the calendar module (calendar.ttl). The email is the carrier; the EventInvitation is the social act. An email may carry zero, one, or many EventInvitation relators (a group invitation parsed into multiple per-invitee relators, or a single message carrying both an invitation and a cancellation).

iCalendar alignment

Cancelled invitations

A cancelled invitation is retained, not erased (Principle 10). The email remains in the store with its hasCalendarMethod gmeow:calendarMethodCancel and the original describesEvent link intact. Suppression (hiding from UI) is handled through the projection layer, never by deletion.

Versioning, variants, and patch diffs

Gmeow's mail store tracks Message-ID collisions, body variants, and patch diffs between a variant message and its canonical counterpart. The cross-cutting version-set layer in ontology/modules/versions.ttl provides the generic lineage machinery; the email module adds only the email-specific identity keys, collision flags, fingerprints, and patch-diff artifact type.

Design principles

• Canonical/variant is a role, not a subclass. A message is canonical or variant only according to an authority/importer. The role is asserted with a gmeow:VersionMembership relator carrying versionRole (roleCanonical / roleVariant) and membershipAuthority (Principle 9).
• Version scale is a value vocabulary. Use gmeow:versionScale (scaleTrivial, scaleMinor, scaleMajor) on the VersionMembership, not a free literal or datatype property.
• Superseded variants remain first-class. A variant that is later judged non-canonical is retained and linked forward; it is suppressed from display via gmeow:displayable false, never erased (Principle 10).
• Counts and fuzzy matching are projection concerns. version_count and the selection of "latest" or "canonical" according to a fingerprint policy are computed by the importer / solver layer (Principle 12), not asserted as canonical datatype properties.

query_mail_identities mapping

mail_message facet metadata mapping

Compound parts: patch_diff

A patch_diff compound part is modeled as a gmeow:EmailPatchDiff, which is a gmeow:BodyPart subclass. It is linked from the variant message via gmeow:hasPatchDiff (a subproperty of gmeow:hasBodyPart). The patch carries gmeow:mediaType "text/und", a gmeow:contentDigest for reliable identity, and gmeow:wasDerivedFrom pointing to the canonical body part(s) it was computed from.

Example pattern

ex:msgVersionSet a gmeow:VersionSet .

ex:msgCanonical a gmeow:EmailMessage ;
    gmeow:rfcMessageId "<collision@example.org>" ;
    gmeow:messageIdCollision true ;
    gmeow:canonicalFingerprint "blake3:canonical-body-hash" ;
    gmeow:hasBodyPart ex:msgCanonicalBody .

ex:msgCanonicalBody a gmeow:BodyPart ;
    gmeow:partId "1" ;
    gmeow:mediaType "text/plain" ;
    gmeow:contentDigest "blake3:canonical-body-bytes" .

ex:canonicalMembership a gmeow:VersionMembership ;
    gmeow:versionSet ex:msgVersionSet ;
    gmeow:versionMember ex:msgCanonical ;
    gmeow:versionRole gmeow:roleCanonical ;
    gmeow:membershipAuthority ex:gmeowImporter .

ex:msgVariant a gmeow:EmailMessage ;
    gmeow:rfcMessageId "<collision@example.org>" ;
    gmeow:messageIdCollision true ;
    gmeow:bodyLineFingerprint "blake3:variant-body-line-hash" ;
    gmeow:analysisScope "body-only" ;
    gmeow:analysisInputBodyLine "Please review the attached Q2 report." ;
    gmeow:hasPatchDiff ex:variantPatch .

ex:variantMembership a gmeow:VersionMembership ;
    gmeow:versionSet ex:msgVersionSet ;
    gmeow:versionMember ex:msgVariant ;
    gmeow:versionRole gmeow:roleVariant ;
    gmeow:versionScale gmeow:scaleMinor ;
    gmeow:membershipAuthority ex:gmeowImporter .

ex:variantPatch a gmeow:EmailPatchDiff ;
    gmeow:mediaType "text/und" ;
    gmeow:contentDigest "blake3:patch-bytes" ;
    gmeow:wasDerivedFrom ex:msgCanonicalBody .

Terms

The declared vocabulary of the email slice, grouped by area. Each term carries its own skos:definition in module.ttl; the groupings below bind the prose above to those declarations.

gmeow:Message · gmeow:EmailMessage · gmeow:Thread

Message is the parent InformationObject for any communication sent from one agent to others; EmailMessage is the RFC 5322 specialization carrying headers, participants, body parts and mailbox residence. A Thread is a conversation — a set of messages related by reply/reference chains.

gmeow:partOfThread · gmeow:inReplyTo · gmeow:rfcMessageId

The threading spine: partOfThread (a partOf specialization) places a message in its conversation; inReplyTo links a message to the one it directly answers (RFC 5322 In-Reply-To); rfcMessageId is the functional RFC 5322 Message-ID, the message's canonical identity key.

gmeow:from · gmeow:sender · gmeow:replyTo · gmeow:to · gmeow:cc · gmeow:bcc

The flat 80%-case participant shortcuts, each EmailMessage → EmailAddress: author (From), transmitting agent (Sender), reply target (Reply-To), and the primary, carbon-copy and blind-carbon-copy recipients. Promote to MessageParticipant when raw syntax, ordering, or provenance must be preserved.

gmeow:MessageParticipant · gmeow:MessageParticipantRole

The reified contextual occurrence of an address in a particular header or envelope slot — the relator carrying display name, ordinal, and raw value, scoped to the occurrence and never a global claim about the address. MessageParticipantRole is its open value vocabulary of header/envelope roles.

gmeow:hasMessageParticipant · gmeow:participantMessage · gmeow:participantAddress · gmeow:participantRole · gmeow:participantHeader · gmeow:participantOrdinal · gmeow:participantGroup · gmeow:rawAddressValue · gmeow:displayName

The relator's posts: the message it belongs to (participantMessage, with inverse hasMessageParticipant), the normalized address (participantAddress), the header/envelope role (participantRole), the source header (participantHeader), the zero-based position (participantOrdinal), the RFC 5322 group name (participantGroup), the raw unparsed segment (rawAddressValue), and the display name as rendered in this occurrence (displayName).

gmeow:messageRoleFrom · gmeow:messageRoleSender · gmeow:messageRoleReplyTo · gmeow:messageRoleTo · gmeow:messageRoleCc · gmeow:messageRoleBcc

The header-address role values mirroring the flat shortcuts — the role a MessageParticipant plays as parsed from the From, Sender, Reply-To, To, Cc, or Bcc header field.

gmeow:messageRoleReturnPath · gmeow:messageRoleErrorsTo · gmeow:messageRoleEnvelopeFrom · gmeow:messageRoleEnvelopeTo · gmeow:messageRoleDeliveredTo · gmeow:messageRoleOriginalTo

The envelope and bounce-routing role values, distinguishing the SMTP envelope (messageRoleEnvelopeFrom/messageRoleEnvelopeTo) and delivery trace (messageRoleDeliveredTo/messageRoleOriginalTo) from the header addresses, plus return-path and errors-to for bounce handling.

gmeow:messageRoleResentFrom · gmeow:messageRoleResentTo · gmeow:messageRoleResentCc

The resent-trace role values: a message resent by an intermediary produces a Resent-* block whose address roles are modelled through MessageParticipant with these values.

gmeow:hasHeader · gmeow:MessageHeader · gmeow:headerName · gmeow:headerValue

Raw header preservation: hasHeader relates a message to each MessageHeader, a single RFC 5322 field carrying its functional headerName and headerValue — the canonical source over which the convenience datatype properties project (Principle 4).

gmeow:sentAt · gmeow:receivedAt · gmeow:subject · gmeow:preview · gmeow:sizeEstimate

Core message metadata: the claimed send time (RFC 5322 Date), the provider receive time (JMAP receivedAt / Gmail internalDate — observationally distinct), the Subject literal, a short plain-text body preview, and the estimated size in octets.

gmeow:threadSubject · gmeow:subjectPrefix

Thread-subject normalization: threadSubject is the base subject of a conversation with reply/forward prefixes stripped, attached to the Thread for display and grouping; subjectPrefix records the prefix(es) removed from an individual message, non-functional because prefixes nest.

gmeow:MessageKeyword · gmeow:hasKeyword · gmeow:keywordSeen · gmeow:keywordFlagged · gmeow:keywordAnswered · gmeow:keywordDraft · gmeow:keywordForwarded · gmeow:keywordJunk

The IMAP-flag / JMAP-keyword facet: hasKeyword relates a message to a MessageKeyword value drawn from the seeded set — seen, flagged, answered, draft, forwarded, junk — an open value vocabulary rather than subclasses.

gmeow:Mailbox · gmeow:residesIn · gmeow:mailboxOfAccount · gmeow:mailboxRole · gmeow:mailboxName

A Mailbox is a named container of messages within an account — folder, JMAP mailbox, or Gmail label. residesIn places a message in it (time-scoped via MailboxResidence); mailboxOfAccount links the mailbox to its OnlineAccount; mailboxRole carries the JMAP special-use role and mailboxName the display name.

gmeow:MailboxResidence · gmeow:residentMessage · gmeow:residenceMailbox

The reified, time-scoped fact that a message resided in a mailbox/label over an interval — membership is time-varying as messages move between folders and labels. residentMessage and residenceMailbox are its functional posts.

gmeow:parentMailbox · gmeow:childMailbox

The canonical folder-hierarchy spine, specializing partOf/hasPart: parentMailbox names the direct parent and its inverse childMailbox the children of a mailbox in a folder tree.

gmeow:mailboxSortOrder · gmeow:mailboxPath · gmeow:mailboxTotalMessages · gmeow:mailboxUnreadMessages

Provider-derived, projection-layer mailbox state (Principle 12), not asserted as canonical facts: the sibling display ordering, the derived path string, and the total / unread message rollups over residence and keyword state.

gmeow:BodyPart · gmeow:hasBodyPart · gmeow:Attachment · gmeow:hasAttachment · gmeow:filename

BodyPart is a MIME part with a media type and content, reached by hasBodyPart (a hasPart specialization). Attachment is a non-inline body part presented as a file (also possibly a Document or MediaObject — not disjoint), reached by hasAttachment and carrying a filename.

gmeow:MultipartBodyPart · gmeow:hasMultipartType · gmeow:MultipartType

A MultipartBodyPart is the structural container node that holds other parts via the universal hasPart/partOf spine; hasMultipartType records its subtype as a MultipartType value.

gmeow:multipartTypeAlternative · gmeow:multipartTypeMixed · gmeow:multipartTypeRelated · gmeow:multipartTypeSigned · gmeow:multipartTypeEncrypted · gmeow:multipartTypeReport · gmeow:multipartTypeDigest · gmeow:multipartTypeParallel

The seeded MIME multipart subtypes — alternative, mixed, related, signed, encrypted, report, digest, parallel — an open value vocabulary; unforeseen subtypes are added as fresh individuals.

gmeow:InlinePart · gmeow:hasInlinePart

An InlinePart is a body part displayed inline within the message body (an embedded image, a rendered text/html part), reached by hasInlinePart (a hasBodyPart specialization). Not declared disjoint from Attachment — disposition is an attributed fact, not a rigid boundary (Principle 9).

gmeow:ContentDisposition · gmeow:hasContentDisposition · gmeow:contentDispositionInline · gmeow:contentDispositionAttachment

The presentation-disposition facet (RFC 2183): hasContentDisposition relates a body part to its ContentDisposition value — inline (rendered in the body) or attachment (presented as a separate file).

gmeow:ContentTransferEncoding · gmeow:hasContentTransferEncoding · gmeow:transferEncodingBase64 · gmeow:transferEncodingQuotedPrintable · gmeow:transferEncoding7bit · gmeow:transferEncoding8bit · gmeow:transferEncodingBinary

The MIME content-transfer-encoding facet (RFC 2045): hasContentTransferEncoding relates a body part to its encoding value — base64, quoted-printable, 7bit, 8bit, or binary.

gmeow:partId · gmeow:contentId · gmeow:charset

Per-part MIME metadata: the structural partId (scoped to the message, e.g. 1.2), the contentId used for cid: references, and the charset of the part's content.

gmeow:BodyValue · gmeow:blobId · gmeow:bodyStructure

JMAP structural identifiers and decoded content (RFC 8620/8621): BodyValue is a decoded body-content object derived from a BodyPart by wasDerivedFrom; blobId is an opaque provider-scoped byte identifier; bodyStructure preserves the serialized JMAP EmailBodyStructure for round-tripping — neither competes with the canonical hasBodyPart/hasPart MIME tree.

gmeow:MailingList · gmeow:hasMailingList · gmeow:listId

A MailingList is a first-class distribution list identified by a List-Id; hasMailingList links a message to the list it travelled through (non-functional — cross-posting), and listId carries the RFC 2919 identifier literal on the message.

gmeow:listSubscribe · gmeow:listUnsubscribe · gmeow:listPost · gmeow:listHelp · gmeow:listArchive · gmeow:listOwner

The RFC 2369 command headers: subscription, unsubscription, posting, help, archive, and owner targets. All non-functional; listPost is a datatype property because RFC 2369 permits the NO sentinel for announcement-only lists.

gmeow:priority · gmeow:importance · gmeow:userAgent · gmeow:autoSubmitted · gmeow:precedence

Raw-header-backed behavioral datatype facets, convenience projections over MessageHeader (Principle 4): the X-Priority, Importance, User-Agent/X-Mailer, Auto-Submitted (RFC 3834), and Precedence header values, stored as literals because their vocabularies are client-extensible.

gmeow:sentBySoftware · gmeow:readReceiptRequested · gmeow:dispositionNotificationTo

sentBySoftware is the parsed SoftwareAgent identified from User-Agent/X-Mailer (the raw value staying on userAgent). dispositionNotificationTo is the canonical read-receipt address (RFC 3798); readReceiptRequested is the non-functional boolean projection of that header's presence.

gmeow:resentDate · gmeow:resentMessageId

The non-address Resent-* trace fields: the Resent-Date and Resent-Message-ID values, both non-functional because a message may carry multiple resent blocks; the raw headers remain on MessageHeader (Principle 4).

gmeow:MessageKind · gmeow:hasMessageKind

The behavioral / report kind of a message as an open value vocabulary — overlapping categories (a bounce is also auto-generated), so hasMessageKind is non-functional and no single category is forced to win (Principle 9).

gmeow:messageKindDeliveryStatusNotification · gmeow:messageKindBounce · gmeow:messageKindFeedbackReport · gmeow:messageKindReadReceipt · gmeow:messageKindAutoGenerated

The seeded message kinds: a DSN (RFC 3464), a bounce (a specialized DSN), an ARF feedback report (RFC 5965), a read-receipt MDN (RFC 3798), and an auto-submitted response (RFC 3834).

gmeow:describesEvent · gmeow:eventDescribedBy · gmeow:calendarAttachment

The email→event seam: describesEvent links a message to an Event parsed from a calendar attachment (with inverse eventDescribedBy); calendarAttachment (a hasAttachment specialization) keeps the iCalendar-carrying attachment first-class. The event spine is reused, never duplicated.

gmeow:calendarUid · gmeow:CalendarMethod · gmeow:hasCalendarMethod · gmeow:messageKindCalendarInvitation

calendarUid records the iCalendar UID of the described event (non-functional); hasCalendarMethod relates a message to its CalendarMethod value; messageKindCalendarInvitation flags invitation-carrying messages as a MessageKind.

gmeow:calendarMethodRequest · gmeow:calendarMethodReply · gmeow:calendarMethodCancel · gmeow:calendarMethodPublish · gmeow:calendarMethodCounter · gmeow:calendarMethodDeclineCounter · gmeow:calendarMethodAdd · gmeow:calendarMethodRefresh

The iTIP METHOD values (RFC 5546): request, reply, cancel, publish, counter, decline-counter, add, and refresh — the seeded CalendarMethod vocabulary.

gmeow:EmailPatchDiff · gmeow:hasPatchDiff

EmailPatchDiff is a BodyPart subclass carrying a patch/diff between a variant message and its canonical counterpart, with mediaType, contentDigest, and wasDerivedFrom links; hasPatchDiff (a hasBodyPart specialization) attaches it to the variant message.

gmeow:messageIdGenerated · gmeow:messageIdCollision · gmeow:canonicalFingerprint · gmeow:bodyLineFingerprint · gmeow:analysisScope · gmeow:analysisInputBodyLine

The variant-tracking identity keys: booleans for a gmeow-generated Message-ID and for a Message-ID collision; the canonical-body and line-normalized content fingerprints used for variant grouping and fuzzy matching; and the analysis scope and input body line recording how those fingerprints were produced.

gmeow:DKIMSignature · gmeow:AuthenticationResult · gmeow:hasAuthenticationResult

DKIMSignature is a DKIM signature (RFC 6376) specializing the trust core's CryptographicSignature. AuthenticationResult is the outcome of an email authentication check (RFC 8601), related to a message by hasAuthenticationResult.

gmeow:authMethod · gmeow:authResult · gmeow:authServer

The authentication-result fields: the method checked (dkim, spf, dmarc, arc, …), the verdict (pass, fail, softfail, …), and the authserv-id that performed the check.

gmeow:RelayHop · gmeow:hasRelayHop · gmeow:hopOrdinal · gmeow:relayFrom · gmeow:relayBy · gmeow:relayAt · gmeow:relayProtocol

A RelayHop is one hop in a message's delivery path recorded by a Received header, attached by hasRelayHop. Its fields: the ordinal position (hopOrdinal, 1 nearest the origin), the host received from (relayFrom), the relaying server (relayBy), the server timestamp (relayAt), and the protocol (relayProtocol).