Relation network

This document sets out how to write down the lines between records, and between records and people, places and events. When a person in an old diary and the grandfather in my own recording point to the same person, this is how that link is kept, together with its evidence.

Name: arkive asked for this to be called “06 Connection” (연결), but section 5 of HGP-0006 in the September Hahoe Genesis Protocol (HGP) specification already uses “connection” for something else (living people introducing each other). So this document uses arkive’s own term, “relation network” (관계망) (05 Glossary, decision 0007).

---

1. Five commitments

1. The ledger is the original; the graph is an index. Relations are also written one line at a time in an append-only ledger (claims.jsonl). A graph database is only an index that can be rebuilt from the ledger at any time. Every rebuild must produce the same graph. (decision 0002, “one inside”)
2. The smallest unit is the “claim”. One line: “what (the source) says what about what (the target)”. Nodes such as people, places and events carry only an identifier. Names, dates of birth and death, and relations are all claims.
3. No claim without evidence. Every claim points to a position in a source record (face, line, region, time span). If no source can be given, the claim is not made. When a person states something they know, it is first kept as a record (a note, a recording), and that record is attached as the source. (arkive absolute rule 5, made a layer 0 rule)
4. Keep them superposed; the view does the choosing. There can be two birth years, two readings of the same character, or “this is the same person” alongside “this is not”. They are not merged or overwritten into one. What comes first is decided by the “view” the viewer has chosen (section 7). Wrong claims are not deleted either; they are kept as “retracted”.
5. Scope filters first. A claim can never be open more widely than its source record. Every query runs only over the part the viewer is allowed to see. A line that comes from a sealed record does not reveal even that it exists (section 9).

2. Three kinds of ledger line

claims.jsonl follows the same rules as 03 Manifest: JSON Lines, append only, never edited or deleted, and the last line with a given identifier is the current state. Each line has a type that is one of three.

type	What	Section
node	Sets up one node (target). Identifier and kind only	Section 3
claim	Makes, confirms or retracts a claim	Sections 4, 8
view	Records a view (a rule for which claims to put first)	Section 7

This ledger belongs to the interpretive layer. The store (layer 1) that holds the source records writes it and keeps it together with those records.

3. Nodes (targets)

Kind kind	Meaning	Examples
person	A person	Seoae Ryu Seong-ryong, No Gyeong-im, my grandfather
group	A group	the Pungsan Ryu clan (munjung), the Yecheon county office, a cooperative
place	A place	Okyeon, Hahoe, Yecheon
event	An event. Something several people take part in, or that has a time and place	one visit, one letter, one meeting
work	A text. An outside book or piece of writing	the “Yeonbo” (Chronological Biography) in Seoaejip (Collected Works of Seoae)
thing	An object	paper given and received, ink sticks, pine mushrooms

• A node line records only the identifier, kind, maker and time of making. Names are attached as claims. Even if a node has several names, or its name changes, the identifier stays the same.
• Records, faces, lines and regions do not get their own nodes. They already have identifiers (the id in 03 Manifest, the IIIF canvas, the line key). Claims point to them as “positions” (section 4.2).

{"hgp":"2026.10","type":"node","id":"0192a3f0-5b1c-7d2e-8f40-1a2b3c4d5e01","kind":"person","handle":"arkive:p-kimtae","made_by":{"type":"machine","name":"claude-opus-5-5"},"at":"2026-10-12T15:00:00+09:00"}

4. Claims

4.1 Fields

Field	Meaning	Example	When	Standard equivalent
hgp	Specification version followed	"2026.10"	Required
type	"claim"		Required
id	Claim identifier (section 11)	UUID	Required	nanopublication URI
at	Time of record. When this line was written	"2026-10-12T15:02:00+09:00"	Required	Graphiti created_at, PROV generatedAtTime
event	The action of this line (section 8)	"claimed"	Required	Palantir action
about	What the claim is about. A node, another claim, or a position	Identifier	Required	the person in a factoid, Wikidata subject
prop	What it says. Name of a property or relation (section 5)	"courtesy_name"	Required	Wikidata property
value	Property value (text, number)	"士悅"	One of value or to	Wikidata value
to	The other end of a relation. A node or claim identifier	Identifier	One of value or to
role	The role taken in an event (fixed values), or a kinship term (as written in the source)	"visitor"	Required for participant, kin	CIDOC-CRM P14.1 in the role of
when	Time of fact. The time the source speaks of (section 6)	{"edtf":"1600-08-12"}	Optional	EDTF, Graphiti valid_at
basis	Whether the source states it directly (stated) or it is inferred from the source (inferred)	"stated"	Required	arkive protocol article 11, “where inference begins”
source	List of source positions (section 4.2). At least one		Required	factoid source, PROV wasDerivedFrom
made_by	Who made it. A person or a machine, with model name (03 Manifest)	{"type":"human","who":"transcription scholar"}	Required	PROV wasAttributedTo
status	candidate, confirmed, retracted	"candidate"	Required	Differs from Wikidata ranks (section 7)
confirmed_by	Confirmation stamp (01 Permissions, decision 0006)	{"who":"u_5d2k8r","as":"admin","at":"…"}	When confirmed
scope	Scope (section 9). Cannot be wider than the source	"private"	Required	ODRL
depositor	The depositors of the source records	["u_9c4w1n"]	Required
replaces	The older claim this claim revises	Identifier	Optional	PROV wasRevisionOf
reason	Why it was confirmed or retracted		Optional	Wikidata P2241
note	Note		Optional

• The content of a claim is never edited. To change the content, make a new claim, point to the old claim with replaces, and then retract the old claim.
• A value of “unknown” is also a claim. In value, use {"unknown":true} (there is a value but it is not known) or {"none":true} (recorded as having none). (Wikidata “unknown value”, “no value”)
• A machine’s score goes in made_by.score. From 0 to 1. Human certainty is expressed through status and basis. A score never stands in for confirmation.

4.2 Positions (how sources and targets are pointed to)

Field	Meaning	Example
record	Record number (id in 03 Manifest)	UUID
book, face	Volume and face (until arkive has assigned record numbers to everything)	"book-0001", "c-010a"
line	Line key	"d-02-01"
xywh	Region within an image. In original scan pixels	[461,235,40,980]
t	Time span within a recording or video (seconds)	[312.4,330.0]
quote	Source text (short)	"盧弘仲 自醴泉來"
external	Outside resource (section 11.3)	{"scheme":"itkc","id":"ITKC_MO_…","url":"…","retrieved":"2026-10-12"}

• One of record, or book+face, or external must be present.
• When exported, a position is converted to a W3C Web Annotation SpecificResource + FragmentSelector (xywh=, t=).
• arkive regions are currently in web copy coordinates (1600 pixels) (of in regions.json). When writing to the ledger, either convert them to original scan coordinates, or also write of to state which size they are based on.

5. Vocabulary (first version)

Field names are short English; equivalents are Wikidata properties and CIDOC-CRM. New vocabulary is added both to 05 Glossary and to this table.

prop	Meaning	Takes	Wikidata	CIDOC-CRM
refers_to	This position points to that node (the person appears in the text)	about=position, to=node	(Web Annotation identifying)	P67 refers to
name	Name	Text	P1559	P1 is identified by
courtesy_name	Courtesy name (ja, 字)	Text	P1782
art_name	Art name (ho, 號)	Text	P1787
alias	Other names used (called by office title, by place name, and so on)	Text	(alias)
born, died	Birth, death (time in when)	Nothing, or a place node	P569, P570, P19, P20	E67 Birth, E69 Death
father, mother, spouse, child, sibling	Family	Person	P22, P25, P26, P40, P3373
kin	Other relatives. The kinship term exactly as written in the source goes in role (nephew (joka), clan nephew (jokjil), maternal uncle (oesuk))	Person	P1038
student_of	Disciple of	Person	P1066
held_office	Office held (office in value, time in when)	Text or group	P39
lived_at	Place of residence	Place	P551
located_in	What it lies within	Place	P131	P89 falls within
coords	Coordinates (WGS84)	[latitude, longitude]	P625
event_kind	Kind of event: visit, letter, gift (exchange of gifts), stay (staying together), meeting (gathering). Product provenance (decision 0016): harvest, milling, intake, soaking, mash (first mash), second_mash (second mash), ferment_check (fermentation check), press (pressing), aging, discard, bottling, seal (sealing), label (labelling), open (opening), blend, custody_transfer (change of custody). Product provenance values are set by the industry profile; those listed here are examples from the traditional liquor profile (decision 0017). They are not in rule table v1, so they show up as review	Text	P31	P2 has type
participant	Took part in an event. Role in role: visitor the one who came, host the one who received, sender the one who sent or gave, recipient the one who received, companion the one who was present	Person or group	P710	P11 had participant
took_place_at	Where the event took place	Place	P276	P7 took place at
object	Object exchanged in the event	Thing		P16 used specific object
author	Author of a text	Person	P50
same_as	Is the same target (section 11.2)	Node of the same kind	(merge, owl:sameAs)
different_from	Is not the same target	Node of the same kind	P1889
external_id	Outside identifier (section 11.3)	{"scheme","id"}	(each ID property)	P1 is identified by

6. Two times

Name	Field	Meaning
Time of fact	when	The time the source speaks of. “They met on the 4th day of the 7th month of 1600”, “He held that office from 1592 to 1598”
Time of record	at	When the claim was written to the ledger. “A machine extracted it on 2026-10-12”. The time of retraction is the at of the retraction line

Form of when:

{"edtf":"1600-08-12","original":"七月 初四日 乙巳","calendar":"korean-lunar","converted_by":"Korea Astronomy and Space Science Institute lunar-solar conversion table"}

The value above is an example to show the form. It is not an actual converted date.

• edtf: the value converted to the Gregorian calendar. Follows EDTF (ISO 8601-2). Uncertain 1600?, approximate 1600~, interval 1592/1598, open end 1592/.., one of a set [1600,1601].
• original: exactly as written in the source (era name, sexagenary cycle, lunar date).
• calendar: gregorian solar calendar, korean-lunar lunar calendar, unknown unknown. EDTF and Wikidata cannot handle the lunar calendar. Keeping the original and the converted value side by side follows the approach of TEI att.datable.custom (referenced).
• converted_by: which table or tool did the conversion. A converted value is also an interpretation.

7. Superposition and views

When there are several claims on the same target with the same prop, all of them stay. All three may even be “confirmed”. The ledger does not decide which is right.

A view is a rule for “which claims to put first, and what to show alongside”. Views are also kept as lines in the ledger.

{"hgp":"2026.10","type":"view","id":"0192a3f0-5b1c-7d2e-8f40-1a2b3c4d5e90","name":"Transcription scholar's notes first","include":["confirmed","candidate"],"prefer":[{"status":"confirmed"},{"made_by.who":"transcription scholar"},{"made_by.type":"human"}],"ties":"all","made_by":{"type":"human","who":"u_5d2k8r"},"at":"2026-10-12T15:10:00+09:00"}

• include: which statuses to show. Retracted claims are always left out by default, and can be viewed separately if chosen.
• prefer: the order of precedence. Whatever matches from the top down comes first.
• ties: when precedence is equal, all (show all side by side) or newest (the latest one).
• To change a view, write a new line with the same identifier. Any output produced through a view records the view identifier together with the at of that line (section 10).
• Whatever view is used, every claim carries its status marker. No view may make machine candidates look as if they were confirmed (principle 6). The arkive screen’s “faint line is a machine candidate, solid line is human-confirmed” is an example.
• Counts are not claims. A number such as “how many times did he meet Seoae” is counted by the view from the event claims. Numbers are not written in the ledger.

How this differs from Wikidata ranks: Wikidata gives each statement one rank: “preferred”, “normal” or “deprecated”. We take only “deprecated”, as retracted. “Preferred” is not written in the ledger; the view decides it. This is because, for the same material, what should come first differs from viewer to viewer.

8. Actions (the ways a claim changes)

A claim’s status changes only through defined actions, and each action leaves one line in the ledger. That line is the action record. (The same idea as Palantir’s actions and action log, and arkive’s correction cards)

event	Meaning	Who (01 Permissions)
claimed	Makes a claim. Always starts as candidate	Editors (human, AI), depositors
confirmed	Applies a confirmation stamp	A person given stamp authority for that record (decision 0006). AI cannot
retracted	Retracts. Not deleted, but marked “not correct”. reason required	A person given stamp authority. AI cannot
reopened	Withdraws a confirmation or retraction and returns the claim to candidate	A person given stamp authority
scope_changed	Narrows the scope. Only the depositor may widen it, and only within the scope of the source record	Depositor

• An action line records only id (the claim acted on), at, event, the person who acted (confirmed_by or made_by) and reason. The content is in the first line.
• Viewers cannot make claims. A viewer’s thoughts are kept as comments (01 Permissions), and an editor may make a claim based on such a comment.
• AI disagrees only by making claims. If a machine thinks “probably not”, it puts forward different_from or a different value as a new candidate. It cannot retract anyone else’s claim.
• For records that need two or more confirmers (arkive verification.required), the claim stays candidate until enough stamps are collected, and stamps applied so far accumulate in the confirmed_by list.

{"hgp":"2026.10","type":"claim","id":"0192a3f0-5b1c-7d2e-8f40-1a2b3c4d5e11","at":"2026-10-13T09:00:00+09:00","event":"confirmed","status":"confirmed","confirmed_by":{"who":"u_5d2k8r","as":"admin","at":"2026-10-13T09:00:00+09:00"}}

9. Scope

1. A claim’s scope cannot be wider than the narrowest of its source records. Claims about claims, and claims about events, also follow the narrowest scope among their materials.

2. The same fact from a different source is a different claim. If “Ryu Seong-ryong was born in 1542” appears both in a family diary (private) and in the published Seoaejip, there are two claims. The one based on the diary is private; the one based on Seoaejip is public. A public fact is opened through a public source, and the private record is not opened because of it. (HGP-0006 section 6, “public facts” and “private relations”)

3. A claim that states a private relation of another living person is sealed from the start. It is not opened until that person opens it. (00 Principles section 3, arkive protocol article 7, HGP-0006 section 6) Whether someone is possibly living is decided in the order below. The threshold in years is 1.2 times the life expectancy of Koreans (decision 0008).

   1. If a death claim (died) is confirmed, the person is not living.
   2. If a birth year claim (born) is confirmed, the person is possibly living if the threshold has not passed since the year of birth.
   3. If there is neither, the person is possibly living if the threshold has not passed since the source record in which they appear came into being (started_at; for old documents, the date written in them).
   4. If even that is unknown, the person is treated as living.

   Basis	Value
   Life expectancy of Koreans (at birth)	83.7 years (Statistics Korea, “2024 Life Tables”, released 2025-12-03)
   Threshold in years	83.7 × 1.2 = 100.44 → 101 years (rounded up. Better to err on the generous side than to fall short)

   When Statistics Korea publishes new life tables each December, the value is updated and the source and date in this table are changed. Devices do not hard-code this value; they read it according to the specification version (hgp).

4. Queries always run only over the subgraph the viewer is allowed to see. Claims that cannot be seen do not appear in results, in counts, or in “more exists” markers. A line from a sealed face does not leak even “who met whom”.

5. Records from several depositors may be counted together only when there are five or more depositors. Queries that single out one person from an aggregate result are not accepted. (HGP-0006 section 4, “aggregate layer”)

6. Anything made from claims (summaries, compilations, training material) inherits the narrowest scope among its materials. Releasing it outside requires separate use consent (00 Principles section 4). (HGP-0006 section 3, and the way Palantir markings are inherited along lineage)

7. Outside this ledger: introducing people. Introducing living people to each other (“connection” in HGP-0006 section 5) is not covered by this document. Such candidates are not kept in the ledger, because the very record that someone was a candidate for someone else would itself be relation information.

10. Compilations (outputs bundled from a viewpoint)

Texts, maps, relation diagrams and answers to questions made by selecting and bundling claims through a view are derived (provenance grade derived). They are entered as records in 03 Manifest, and the following are kept with them. (arkive protocol article 11, “AI is not a spokesperson”)

Field curation.	Meaning
query	What was asked (the query as written)
view	Which view was used to select (identifier and at)
claims	List of identifiers of the claims used (same meaning as derived_from)
count	How many items were bundled
period	Which period (EDTF)
criteria	What criteria were used to select
exceptions	What was left out for not meeting the criteria, and what contradicted each other
inferred	Where inference begins (basis: inferred claims, and anything newly inferred while compiling)

An AI that answers questions does not train the material into the model; it reads the ledger and sources each time it answers (00 Principles section 4, arkive protocol article 10). Every sentence of an answer points to a claim or a source position.

11. Identifiers

11.1 Form

• Identifiers for nodes, claims and views are UUIDs (RFC 9562; time-ordered version 7 recommended).
  • They do not collide even when created on phones or in other projects without checking with each other.
  • Personal names are not put into identifiers. Names change, a person may have several, and different people share the same name.
• Human-readable aliases go separately in handle. The form is <project>:<alias>, and it only needs to be unique within the project. Example: arkive:p-kimtae. Screens and conversations may use the handle, but lines in the ledger are joined by UUID.

11.2 When the same target has received two identifiers

• If nodes set up separately by different projects (secretary’s “grandfather”, arkive’s “person in the diary”) are the same person, they are joined with a same_as claim. Evidence is needed (a genealogy, words in a recording).
• The index shows nodes whose same_as is confirmed as one bundle. The representative of the bundle is the identifier created earliest (Wikidata practice).
• No identifier is ever deleted. To undo a bundle, retract the same_as. If “this is the same person” and “this is not” (different_from) are both candidates, they are left superposed.
• Candidate same_as claims are viewed bundled or separately, depending on the view.

11.3 Outside identifiers

• Outside resources are not copied; they are pointed to only by identifier and link (arkive PLAN chapter 8). An external_id claim attaches {"scheme","id","url","retrieved"}.
• To use the content of an outside resource as evidence, make a separate claim whose source position (source.external) is that resource. The scope of outside resources is public.
• Outside links found by a machine are candidates. A person confirms them.

scheme	What	Identifier form	Note
wikidata	Wikidata	Q + number	When items are merged, the old number redirects to the new one
aks-people	Korean Historical Figures Information System	PPL_…	Service suspended from 2026-09-30, planned to reopen at the end of 2027. It is not known whether numbers will carry over. Always record retrieved
encykorea	Encyclopedia of Korean Culture	Entry number	Wikidata P9475
itkc	Korean Classics Database	ITKC_MO_…	No commitment to permanent addresses
viaf, isni	International name authority files	Number
tgn, geonames	Place names	Number

12. International standards and what we learn from others

Grades are the same as in section 7 of 03 Manifest. Conforms means checked with a validation tool; aligned means the meaning and structure match so it can be exported as is; referenced means the idea was borrowed. At present nothing in this document “conforms”.

Standard	What was aligned	Grade
Factoid model (King’s College London prosopography)	“One point that a source says about a person” is the smallest unit. Does not decide true or false, and keeps contradictions together. Separates the time of fact from the time of writing	Aligned
Wikidata data model	Statement = property + value + qualifiers + references. “Unknown” and “none”. Merging redirects rather than deletes. Ranks are taken differently (section 7)	Aligned
nanopublication	A unit that exports one claim as three parts: “assertion, provenance, publication info”. Trusty URIs, which put the fingerprint into the identifier, follow the same idea as 02 Fingerprint	Referenced
RDF 1.1 named graph (W3C Recommendation)	Exporting one claim as one named graph	Aligned
RDF 1.2 triple term	A new way to hold “claims about claims”. Still a Candidate Recommendation (2026-04-07), so the first export uses named graphs, to be revisited once it becomes a Recommendation	Referenced
W3C Web Annotation (Recommendation)	Position = SpecificResource + FragmentSelector (xywh=, t=). refers_to = motivation identifying	Aligned
CIDOC-CRM 7.1.3 (ISO 21127:2023)	Event-centred: meetings and letters attach participants, place and time to an event node. A claim itself is E13 Attribute Assignment	Referenced
Linked Art 1.0	The JSON-LD form of CIDOC-CRM. “Someone saw it this way” as AttributeAssignment	Referenced
W3C PROV-O (Recommendation)	made_by = wasAttributedTo, source = wasDerivedFrom, replaces = wasRevisionOf	Aligned
EDTF (ISO 8601-2)	when.edtf	Aligned
TEI att.datable.custom	Lunar original and Gregorian value side by side	Referenced

Learned from widely used implementations rather than standards:

What	What we took	What we did not take
Graphiti / Zep (AI memory graph)	Two times (time of fact and time of record). Each fact carries its source “episode”. Contradictions are expired, not deleted	A new fact automatically expires an old one. We keep them superposed, and only people retract. It does not separate what a machine extracted from what a person confirmed
MCP memory server	The simplicity of keeping nodes, relations and observations in one JSONL file	No evidence, time or certainty, and editing means deleting
Microsoft GraphRAG	Each fact carries evidence down to the text chunk. Cluster summaries	A language model decides true or false status. Scope is not inherited by summaries. Our summaries are derived outputs and carry the fields in section 10
Palantir ontology	The four elements objects, properties, links and actions, taken as nodes, claims and actions. Edits only through defined actions, each one recorded. Security markings are inherited along lineage by derived outputs, and only people holding all the markings can see them	The owner is the institution. For us the depositor is the owner, and only the depositor can widen scope (Palantir lifts markings with administrative rights). Property values are single, so there is no superposition and user edits win. We keep them superposed and let the view choose

Memory built up by machines versus facts confirmed by people: the AI memory graphs above do not separate the two. Every claim here has made_by.type and status, so we always separate them. This is where this specification differs most from them.

13. Example: Kim Sa-yeol and Kim Tae

The transcription scholar’s notes write the courtesy name of Kim Tae (金兌) as “士說”, while the dated entries in the diary text write it as “士悅” (arkive design document). Both readings are pronounced Sa-yeol. The two readings are kept together.

{"hgp":"2026.10","type":"node","id":"0192a3f0-5b1c-7d2e-8f40-1a2b3c4d5e01","kind":"person","handle":"arkive:p-kimtae","made_by":{"type":"machine","name":"claude-opus-5-5"},"at":"2026-10-12T15:00:00+09:00"}
{"hgp":"2026.10","type":"claim","id":"0192a3f0-5b1c-7d2e-8f40-1a2b3c4d5e10","at":"2026-10-12T15:01:00+09:00","event":"claimed","about":"0192a3f0-5b1c-7d2e-8f40-1a2b3c4d5e01","prop":"name","value":"金兌","basis":"stated","source":[{"book":"book-0001","line":"note-133","quote":"김태의 자가 사열(士說)"}],"made_by":{"type":"human","who":"transcription scholar","via":"transcription and translation notes"},"status":"candidate","scope":"private","depositor":["u_9c4w1n"]}
{"hgp":"2026.10","type":"claim","id":"0192a3f0-5b1c-7d2e-8f40-1a2b3c4d5e11","at":"2026-10-12T15:01:00+09:00","event":"claimed","about":"0192a3f0-5b1c-7d2e-8f40-1a2b3c4d5e01","prop":"courtesy_name","value":"士說","basis":"stated","source":[{"book":"book-0001","line":"note-133","quote":"자가 사열(士說)"}],"made_by":{"type":"human","who":"transcription scholar","via":"transcription and translation notes"},"status":"candidate","scope":"private","depositor":["u_9c4w1n"]}
{"hgp":"2026.10","type":"claim","id":"0192a3f0-5b1c-7d2e-8f40-1a2b3c4d5e12","at":"2026-10-12T15:02:00+09:00","event":"claimed","about":"0192a3f0-5b1c-7d2e-8f40-1a2b3c4d5e01","prop":"courtesy_name","value":"士悅","basis":"stated","source":[{"book":"book-0001","face":"c-008a","line":"d-01-05","quote":"士悅"}],"made_by":{"type":"machine","name":"claude-opus-5-5","score":0.8},"status":"candidate","scope":"private","depositor":["u_9c4w1n"],"note":"Notes have 士說, body text has 士悅. Needs checking against the original face"}
{"hgp":"2026.10","type":"claim","id":"0192a3f0-5b1c-7d2e-8f40-1a2b3c4d5e13","at":"2026-10-12T15:03:00+09:00","event":"claimed","about":{"book":"book-0001","face":"c-008a","line":"d-01-05","quote":"士悅"},"prop":"refers_to","to":"0192a3f0-5b1c-7d2e-8f40-1a2b3c4d5e01","basis":"inferred","source":[{"book":"book-0001","face":"c-008a","line":"d-01-05"},{"book":"book-0001","line":"note-133"}],"made_by":{"type":"machine","name":"claude-opus-5-5","score":0.9},"status":"candidate","scope":"private","depositor":["u_9c4w1n"]}

• The “Transcription scholar’s notes first” view puts 士說 first; the “Body text first” view puts 士悅 first. Both are visible.
• When a person given confirmation stamp authority checks the original face and confirms one of them, one confirmed line is added. The other stays a candidate, or is retracted if judged wrong.
• The face c-008a and the line keys note-133 and d-01-05 are for illustration. arkive will set the actual positions.

14. Mapping from what exists now (arkive)

arkive now	This document
Node records such as type: person, id: p-kimtae	A node line + handle: "arkive:p-kimtae". Names, Chinese characters and relations are split out into claims
Alternative name records (type: alias, basis)	courtesy_name and alias claims. If two nodes are the same, same_as
verified_by: transcription scholar (notes)	made_by: {"type":"human","who":"transcription scholar"} + the notes as source. This is not a confirmation stamp. The transcription scholar is not someone given stamp authority as an editor of this record, but a scholar who supplied evidence. Putting it first is the job of the “Transcription scholar’s notes first” view
status: candidate	status: candidate
status: verified	confirmed if applied by a person with stamp authority, otherwise candidate
Correction statuses proposed, held, partly_accepted	candidate (partly_accepted is the state where some stamps have accumulated in confirmed_by)
accepted	event: confirmed
rejected	event: retracted
reverted	event: reopened
Edge “mentioned together” + count	Each meeting as an event node and participant claims. The view does the counting
source: {“canvas_id”:“<book>/<page>”,“line”:…}	Position {"book","face","line"}
xywh + of in regions.json	The position’s xywh. Convert to original scan coordinates, or include of
Per-person scope example (p-kimbu: Conditional)	Scope attaches to claims, not to nodes. To close off everything about one person, narrow the scope of the claims about that person
place in reading lines (the face the line sits on)	Not a geographic place. Do not mix it up with place in this document (05 Glossary)

Rule table. Which fields go on which node, what form values take, and whether there is one or many are published as a machine-checkable rule table: https://hgp.hahoe.io/ns/relations-v1.json (08 Name file, section 5). The public address for field names is https://hgp.hahoe.io/ns/v1.jsonld.

15. To be checked

• Whether to keep one ledger file per depositor or per volume (arkive decides when it first builds it).
• Once RDF 1.2 becomes a Recommendation, revisit whether to move the export of “claims about claims” to triple terms.
• When the Korean Historical Figures Information System reopens, check whether the old PPL_ numbers carry over.