Skip to content
Quaker Cloud

Memorial Minute Specification

Overview

Section titled “Overview”

A memorial minute is a written tribute prepared by a Quaker meeting to honor a Friend who has died. It is read in meeting for worship with attention to business, entered into the minutes, and often shared with other meetings and publications such as yearly meeting journals. This specification defines a standard data model, serialization formats, and URL conventions for memorial minutes published by Quaker meetings and worship groups.

The goal is interoperability: a meeting should be able to publish memorial minutes in a structured format that other Quaker platforms, directories, and publications can consume without requiring manual re-entry.

This specification draws on schema.org vocabulary wherever possible to avoid reinventing structures that the broader web already understands, and to enable memorial minutes to be indexed and understood by general-purpose tools.

This specification has a normative dependency on the Quaker Cloud Core Vocabulary, which defines the quaker: namespace terms used here (quaker:documentType, quaker:meetingType, quaker:quakerBranch).

Scope

Section titled “Scope”

This specification covers:

  • The data model for a memorial minute record
  • Handling of partial or uncertain dates
  • Place of birth, death, and meeting membership
  • Name representation across cultural conventions
  • Date and place entry user interface requirements
  • Serialization formats: JSON-LD, XML, and Atom
  • URL structure and namespace conventions
  • A minimal reference listing format

It does not cover the internal meeting process for drafting or approving memorial minutes, nor does it specify the spiritual or theological content of the minute body itself.

Data Model

Section titled “Data Model”

Top-Level Fields

Section titled “Top-Level Fields”
FieldSchema.org TermRequiredNotes
identifierschema:identifierYesUnique ID within the meeting’s namespace
dateCreatedschema:dateCreatedYesISO 8601 date the record was created
dateModifiedschema:dateModifiedNoISO 8601 date last modified
publisherschema:publisherYesThe meeting or worship group that approved this minute
aboutschema:aboutYesThe Friend being remembered; value is a schema:Person object
articleBodyschema:articleBodyYesFree-form text of the minute
inLanguageschema:inLanguageNoBCP 47 language tag (e.g. en, fi, de)
isPartOfschema:isPartOfNoPublication or minute book this appears in

Person Fields

Section titled “Person Fields”

The person block uses schema:Person vocabulary. Name fields follow schema.org conventions, which are deliberately culture-neutral: they do not assume a specific word order or that any particular component is present.

FieldSchema.org TermRequiredNotes
givenNameschema:givenNameConditional †First/personal name(s)
familyNameschema:familyNameConditional †Family, clan, or surname
additionalNameschema:additionalNameNoMiddle name(s) or additional given names; does not satisfy the † requirement
honorificPrefixschema:honorificPrefixNoe.g. Dr., Rev., Elder
honorificSuffixschema:honorificSuffixNoe.g. Jr., Sr., III
birthDateschema:birthDateNoISO 8601 partial date: 1923-04-17, 1923-04, or 1923 — see Date Precision
deathDateschema:deathDateNoISO 8601 partial date — see Date Precision
birthPlaceschema:birthPlaceNoPlace object or free text — see Place Fields
deathPlaceschema:deathPlaceNoPlace object or free text — see Place Fields
memberOfschema:memberOfNoMeeting(s) the Friend held membership in — see Place Fields

† At least one of givenName or familyName must be present. See Conformance.

Note on name ordering: Schema.org does not prescribe display order. Implementations should not assume givenName familyName order. Display name construction should follow the cultural conventions of the meeting or the Friend’s own preference where known. The name field from schema:Person may be used to store a canonical display name when word order is culturally significant.

Date Precision

Section titled “Date Precision”

Dates of birth and death are often uncertain for historical figures, or known only partially for contemporary ones. This specification uses ISO 8601 partial date strings to represent whatever is known, without requiring any additional metadata field to signal precision. The specificity of the string itself is the signal.

ISO 8601 partial dates:

ISO 8601 permits reduced-precision representations. All three forms are valid values for birthDate and deathDate:

FormExampleUse when
Full date1923-04-17Day, month, and year are known
Year-month1923-04Month and year are known; day is not
Year only1923Only the year is known

If the date is entirely unknown, the field should be omitted rather than set to an empty string or a placeholder value. Omission means unknown; a partial string means partially known.

Examples:

Day, month, and year known:

"birthDate": "1923-04-17"

Year and month known, day not recorded:

"birthDate": "1923-04"

Year only known:

"birthDate": "1923"

Death date recorded, birth date not known (omit birthDate entirely):

"deathDate": "2024-09-14"

This convention is consistent with how schema.org documents birthDate and deathDate, and how established genealogical data formats handle partial knowledge. A consuming system — whether a search engine, a language model, or another Quaker platform — can determine precision directly from the string format without any additional vocabulary.

Note on accuracy vs. precision: This model handles precision (how much of the date is known) but not accuracy (whether what is recorded is correct). A date recorded as 1923 may be an estimate that could be off by several years. This specification does not provide a field for accuracy qualifiers in v0.1; that is noted as an open question for archival and historical use cases.

Place Fields

Section titled “Place Fields”

Place data serves two purposes in this specification: disambiguation (distinguishing two Friends with similar names and overlapping dates) and historical record (documenting where a Friend was born, died, or worshipped). Both are legitimate, and both are served by the same structure.

Schema.org’s Place object is used as the basis. Its full vocabulary includes street addresses, geo-coordinates, containedInPlace hierarchies, and more — none of which are needed here. This specification defines a constrained subset.

Place object

Section titled “Place object”

A Place object in this specification has the following fields:

FieldSchema.org TermRequiredNotes
nameschema:nameNoFree-text name of the specific place (city, town, village, neighbourhood)
addressRegionschema:addressRegionNoState, province, county, or equivalent subdivision
addressCountryschema:addressCountryNoISO 3166-1 alpha-2 country code (e.g. FI, GB, US) or plain text for historical places

All three fields are optional. A Place object may have any combination — including just a country, just a city name, or all three. The intent is to capture whatever is known without requiring what is not.

Why not a full address? Street-level address data is inappropriate for birth and death records in a published memorial minute. It is not necessary for disambiguation and may implicate the privacy of surviving family members.

Historical place names: Country borders and place names change over time. A Friend born in 1880 in what is now Finland may have been recorded as born in the Russian Empire or in Grand Duchy of Finland. addressCountry accepts plain text for historical places where an ISO country code would be anachronistic or misleading. If using a plain text country name, use the name as it would have been used at the time of the event rather than the contemporary name.

Examples:

City and country known:

"birthPlace": {
  "@type": "Place",
  "name": "Turku",
  "addressCountry": "FI"
}

Region and country known, city not recorded:

"birthPlace": {
  "@type": "Place",
  "addressRegion": "Yorkshire",
  "addressCountry": "GB"
}

Historical place name:

"birthPlace": {
  "@type": "Place",
  "name": "Vyborg",
  "addressCountry": "Grand Duchy of Finland"
}

Country only:

"birthPlace": {
  "@type": "Place",
  "addressCountry": "US"
}

Free text fallback (when structured entry is not possible or the place is ambiguous):

"birthPlace": {
  "@type": "Place",
  "name": "near Philadelphia"
}

Meeting membership

Section titled “Meeting membership”

The memberOf field records which meeting or meetings the Friend held membership in during their life. This is genealogically significant: meeting membership records are often the most complete documentary source for Quaker individuals, and knowing a Friend’s meeting can resolve ambiguity that names and dates alone cannot.

memberOf accepts either a single Organization object or an array of them:

"memberOf": [
  {
    "@type": "Organization",
    "name": "Helsinki Monthly Meeting",
    "quaker:meetingType": "monthly"
  },
  {
    "@type": "Organization",
    "name": "Finland Yearly Meeting",
    "quaker:meetingType": "yearly"
  }
]

Place entry user interface

Section titled “Place entry user interface”

The same principle applies to place entry as to date entry: users must not be forced to enter more than they know.

The recommended pattern is three independent optional fields presented in order — city/town, region, country — each of which can be filled, partially filled, or left blank. None of the three should be required for the record to save.

Country entry should offer an autocomplete list backed by ISO 3166-1 country names, but allow free text for historical place names not in the standard list. Region entry is a free text field — the variety of subdivision types across countries (states, provinces, counties, cantons, oblasts, prefectures) makes a controlled vocabulary impractical at this scope.

This section is part of the specification because the data model and the entry interface must be designed together. An off-the-shelf calendar widget will corrupt data: it requires a complete date selection, which forces a user to either falsify the day and month, or abandon the field. Neither outcome is acceptable for a record where data integrity matters and partial knowledge is routine.

Implementations must not require users to enter more date components than they know.

The reference pattern for date entry is a stepwise progressive input:

  1. The user enters a four-digit year. This alone is sufficient to save the record. The stored value is 1923.
  2. Optionally, the user adds a month. A simple 1–12 numeric field or short-name dropdown is appropriate. The month input is only shown or enabled once a year has been entered. The stored value becomes 1923-04.
  3. Optionally, the user adds a day. The day input is only shown or enabled once a month has been entered. The stored value becomes 1923-04-17.

At each step the user may stop. The form does not require progression to the next level before it can be saved or submitted.

This is not a calendar. There is no month-grid view, no “today” shortcut, and no requirement to navigate through months to select a date. The input is structured text with progressive optional fields. Implementations may offer a calendar as an optional convenience for full-date entry, but must not make it the only path.

Resulting stored values by input level:

User entersStored value
Year only1923
Year + month1923-04
Year + month + day1923-04-17
Nothing / unknownField omitted

This pattern is established in genealogical software (FamilySearch, Gramps, GEDCOM) and archival systems (EAD). It is not novel; implementations can look to those systems for reference UI patterns.

Publisher

Section titled “Publisher”

The publisher object identifies the meeting responsible for the minute.

FieldNotes
nameFull name of the meeting
quaker:meetingTypeControlled vocabulary value — see quaker:meetingType
urlCanonical URL of the meeting’s website
quaker:yearlyMeetingName of affiliated yearly meeting; omit when the publishing meeting is itself a yearly meeting
quaker:quakerBranchControlled vocabulary value — see quaker:quakerBranch

Serialization Formats

Section titled “Serialization Formats”

JSON-LD

Section titled “JSON-LD”

The canonical serialization is JSON-LD using schema.org vocabulary. This format is recommended for REST APIs and for embedding in HTML pages as structured data.

File extension: .json Media type: application/ld+json

quaker:yearlyMeeting — Include this field inside the publisher object when the publishing meeting is a monthly or quarterly meeting, e.g. "quaker:yearlyMeeting": "Finland Yearly Meeting". It is omitted in the example below because the publisher is itself a yearly meeting.

{
  "@context": {
    "@vocab": "https://schema.org/",
    "quaker": "https://quaker.cloud/spec/ns/"
  },
  "@type": "Article",
  "quaker:documentType": "MemorialMinute",
  "identifier": "memorial/lindqvist-anna-maria-2024",
  "dateCreated": "2024-11-01",
  "inLanguage": "fi",
  "publisher": {
    "@type": "Organization",
    "name": "Finland Yearly Meeting",
    "url": "https://kvakari.fi",
    "quaker:meetingType": "yearly",
    "quaker:quakerBranch": "unprogrammed"
  },
  "about": {
    "@type": "Person",
    "givenName": "Anna Maria",
    "familyName": "Lindqvist",
    "birthDate": "1923",
    "birthPlace": {
      "@type": "Place",
      "name": "Turku",
      "addressCountry": "FI"
    },
    "deathDate": "2024-09-14"
  },
  "articleBody": "Full text of the memorial minute goes here..."
}

XML

Section titled “XML”

The XML format is intended for archival use and exchange with systems that prefer XML. It uses a quaker.cloud namespace alongside schema.org property names for field identification.

File extension: .xml Media type: application/xml Namespace: https://quaker.cloud/spec/ns/memorial/

Prefix mapping rule: The root element <memorialMinute> and any elements defined exclusively by this specification use the unprefixed default memorial namespace. All schema.org properties use the schema: prefix. Quaker-specific extension fields use the quaker: prefix. RDF type declarations use the rdf:type attribute with a CURIE value (e.g. rdf:type="schema:Person"); schema:type is not used because https://schema.org/type does not exist in the schema.org vocabulary. Implementers must follow this rule to produce consistent, interoperable XML.

<?xml version="1.0" encoding="UTF-8"?>
<memorialMinute
  xmlns="https://quaker.cloud/spec/ns/memorial/"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:schema="https://schema.org/"
  xmlns:quaker="https://quaker.cloud/spec/ns/"
  version="0.1">


  <schema:identifier>memorial/lindqvist-anna-maria-2024</schema:identifier>
  <schema:dateCreated>2024-11-01</schema:dateCreated>
  <schema:inLanguage>fi</schema:inLanguage>


  <schema:publisher>
    <schema:name>Finland Yearly Meeting</schema:name>
    <schema:url>https://kvakari.fi</schema:url>
    <quaker:meetingType>yearly</quaker:meetingType>
    <quaker:quakerBranch>unprogrammed</quaker:quakerBranch>
    <!-- quaker:yearlyMeeting omitted: publisher is itself a yearly meeting.
         For monthly/quarterly publishers include e.g.:
         <quaker:yearlyMeeting>Finland Yearly Meeting</quaker:yearlyMeeting> -->
  </schema:publisher>


  <schema:about rdf:type="schema:Person">
    <schema:givenName>Anna Maria</schema:givenName>
    <schema:familyName>Lindqvist</schema:familyName>
    <schema:birthDate>1923</schema:birthDate>
    <schema:birthPlace rdf:type="schema:Place">
      <schema:name>Turku</schema:name>
      <schema:addressCountry>FI</schema:addressCountry>
    </schema:birthPlace>
    <schema:deathDate>2024-09-14</schema:deathDate>
  </schema:about>


  <schema:articleBody><![CDATA[
    Full text of the memorial minute goes here...
  ]]></schema:articleBody>


</memorialMinute>

RSS / Atom Feed

Section titled “RSS / Atom Feed”

Meetings may publish a feed of memorial minutes for syndication. Atom is preferred over RSS 2.0 for its cleaner namespace handling and better internationalization support.

File extension: .atom or .xml Media type: application/atom+xml Recommended feed URL path: /memorial-minutes/feed.atom

Each <entry> in the feed should include:

  • <title>: Display name of the Friend
  • <id>: Canonical URI of the memorial minute record
  • <updated>: Date of last modification
  • <published>: Date the minute was approved or first published
  • <summary>: Optional brief excerpt
  • <content>: Full minute text or link via <link rel="alternate">
  • Custom extension elements in the memorial: namespace for structured person data
<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:memorial="https://quaker.cloud/spec/ns/memorial/">


  <!-- ... other feed-level elements (title, id, updated, link) ... -->


  <entry>
    <title>In memory of Anna Maria Lindqvist (c. 1923–2024)</title>
    <id>https://kvakari.fi/memorial-minutes/lindqvist-anna-maria-2024</id>
    <updated>2024-11-01T00:00:00Z</updated>
    <published>2024-11-01T00:00:00Z</published>
    <memorial:person
      givenName="Anna Maria"
      familyName="Lindqvist"
      birthDate="1923"
      birthPlaceName="Turku"
      birthPlaceCountry="FI"
      deathDate="2024-09-14" />
    <content type="html"><![CDATA[ ... ]]></content>
  </entry>


</feed>

URL Structure

Section titled “URL Structure”

Implementations should follow a consistent URL pattern. The recommended structure is:

/{base-path}/{slug}

Where {base-path} defaults to memorial-minutes and {slug} is a URL-safe identifier derived from the Friend’s name and death year.

Slug construction:

Slugs should be constructed from familyName + givenName + death year, lowercased and hyphenated, with Latin-script diacritics transliterated for URL safety (e.g. ä → a, ö → o). Where family name conventions differ (e.g. patronymics, matronymics, single names), the meeting should document its own slug convention and apply it consistently.

For names in non-Latin scripts (Arabic, Chinese, Japanese, Korean, Cyrillic, and others), transliteration is ambiguous and lossy. Implementations expecting non-Latin names should use either a manually specified slug field that the editor fills in, or a numeric identifier as the URL slug. The numeric fallback is always acceptable:

/memorial-minutes/42

Name-derived slug generation is recommended for Latin-script names but must not be the only option.

Examples:

/memorial-minutes/lindqvist-anna-maria-2024
/memorial-minutes/garcia-lopez-jose-maria-2019
/memorial-minutes/krishnamurthy-2001
/memorial-minutes/42

Namespace listing page:

A listing of all memorial minutes for a meeting should be available at the {base-path} URL:

/memorial-minutes/

The listing should support at minimum:

  • Chronological order by death date (most recent first by default)
  • Alphabetical order by family name
  • Where family naming conventions vary, alphabetical sorting should follow the convention established in the meeting’s own metadata

Serialization endpoints:

Individual records should be available in all supported formats via content negotiation or explicit URL suffixes:

/memorial-minutes/lindqvist-anna-maria-2024          (HTML, default)
/memorial-minutes/lindqvist-anna-maria-2024.json     (JSON-LD)
/memorial-minutes/lindqvist-anna-maria-2024.xml      (XML)
/memorial-minutes/feed.atom                           (Atom feed, all records)

Open Questions

Section titled “Open Questions”

The following questions are noted for future revision:

  1. Multilingual minutes (high priority): A meeting may publish the same minute in more than one language — this is an immediate practical concern for meetings operating in bilingual contexts (e.g. Finnish/Swedish in Finland, Welsh/English in Wales). Should multilingual versions be separate records linked by a sameAs relationship, or variants within a single record? The current inLanguage field assumes one language per record, which may be too restrictive.

  2. Date accuracy qualifiers: The current model handles precision (how much of the date is known) via partial ISO strings, but not accuracy (whether what is recorded is correct). For historical records where a year like 1923 may itself be an estimate, a future version may need a qualifier field. This should be addressed in v0.2 with reference to established archival vocabularies.

  3. Name disambiguation: When two Friends share a family name and the same death year, the current slug convention creates a collision. A numeric suffix (-2) is a practical workaround, but a more principled approach may be needed.

  4. Historical minutes: Some meetings hold minutes going back centuries. The question of digitization standards and archival metadata (provenance, transcription notes) is out of scope for version 0.1.

  5. Privacy: For Friends who died recently, some family members may have privacy concerns about publishing detailed biographical information. Implementations should consider whether birth dates and biographical details should be withheld even when known, and whether the specification should define a mechanism for redacting or omitting fields on request.

  6. Relationship to FGC’s memorial resources: Friends General Conference and yearly meetings often also hold or republish memorial minutes. A relatedLink or sameAs field could support cross-referencing between platforms.

Conformance

Section titled “Conformance”

An implementation is considered conformant with this specification if it:

  • Provides JSON-LD serialization as the baseline format (required)
  • Provides an Atom feed at a stable, documented URL (strongly recommended)
  • Includes the required fields: identifier, dateCreated, publisher, about (with at least familyName or givenName on the schema:Person object), and articleBody
  • Uses ISO 8601 partial date strings for any date values, omitting fields that are entirely unknown
  • Follows the date entry UI requirements: does not force users to enter more date components than they know
  • Makes a listing of all published memorial minutes available at a stable URL

XML serialization is optional. Implementations that provide only XML without JSON-LD are not conformant, as JSON-LD is the format most widely consumed by search engines, language models, and federated Quaker platforms.

Implementations are encouraged to support all three serialization formats.

References

Section titled “References”