HAS_MODIFICATION
HAS_MODIFICATION edge/relationship definition.
Description
Connects a ( :Place:Context ) node to a ( :Vocab:FormationType ) node to record an informed determination of the type of formation process that MODIFIED this Context after its initial formation (with optional period and dates, via edge properties), selected from choices in Vocab:FormationType
Analogy
"Modification" column in "Context" table or join row(s), column(s), or table(s) defining relationship between a Context and a formation/modification type.
CIDOC-CRM Mapping
MAYBE include a short summmary here, but leave the details for the designated CIDOC-CRM section.
Relevant Nodes, Directions, and Cardinality
[ :Place:Context ] ——[ :HAS_MODIFICATION ]——> @[0..*] [ :Vocab:FormationType ] ⟵ @[0..*]
- Each Context may have zero or many MODIFYING FormationTypes
- Each MODIFYING FormationType may be related to zero or many Contexts.
Edge/Relationship Properties
| property | type | req? | uniq? | description | example(s) |
|---|---|---|---|---|---|
| - | - | - | - | - | - |
| period | [string list] | n | n | Whenever possible, an informed determination of the cultural period(s) in which this MODIFICATION took place, as a string array, selected from choices in Vocab:FormationType. | ["Late Roman", "Early Byzantine"] |
| dateEarliest | string (edtf) | n | n | Whenever possible, an informed determination of the earliest reasonably possible date for this MODIFICATION, in extended date-time format (level 0/1 supported). | "0300" for 300 CE |
| dateLatest | string (edtf) | n | n | Whenever possible, an informed determination of the latest reasonably possible date for this MODIFICATION, in extended date-time format (level 0/1 supported). | "0600" for 600 CE |
| confidence | string | Y | n | Confidence level for asserted MODIFICATION (including any recorded periods and dates) selected from options defined in the Vocab:Confidence controlled vocabulary. | "moderate" |
POSSIBLE: System/Audit Properties
Need to decide if we should include the full (or a partial) audit trail for edge/relationships. I'm leaning toward YES.(these are not required/enforced by Neo4j but are populated via the UJAP Database web application; these could also be handled—perhaps more simply—by edge/relationship to AuditEvent nodes)
| property | type | req? | uniq? | description | example(s) |
|---|---|---|---|---|---|
| proposedAt | datetime | n | n | Timestamp of entity proposal (initial database record creation) | "2026-01-30T02:39:15.638Z" |
| proposedBy | string | n | n | Email or userID of the person who created this entity's initial/proposed record | "person@email.com" |
| approvedAt | datetime | n | n | Timestamp of entity proposal (initial database record creation) | "2026-01-30T12:47:15.638Z" |
| approvedBy | string | n | n | Email or userID of the person who created this entity's initial/proposed record | "person@email.com" |
| committedAt | datetime | n | n | of node entity COMMIT (i.e., formal approval/ publishing to database by an admin). | "2026-01-31T02:41:56.043Z" |
| committedBy | string | n | n | Email or userID of the person who COMMITTED this node entity. | "person@email.com" |
Example Visualization
Insert visualization here, drawn in Arrows.app and using the correct color-coding.