TOOK_PLACE_AT

TOOK_PLACE_AT edge/relationship definition.

Description

Connects an ( :Activity ) node to a ( :Place ) node, establishing the event/activity location. Given the fact that Activity/Event nodes may be nested within each other, and that Place nodes may also be nested within other Places, it is important that this relationship is carefully assigned at the most specific and appropriate level. For example, it is usually sufficient to record that an ( :Activity:FieldSeason ) [:TOOK_PLACE_AT] a particular ( :Place:Site ) but this is probably insufficient for an ( :Activity:Sampling ), where it is far more valuable to record that this [:TOOK_PLACE_AT] a particular ( :Place:Context ).

Given the graph data model's ability to traverse relationships, it is unnecessary to secondarily record relationships higher up the hierarchy: as long as a ( :Place:Context ) node is properly related to a ( :Place:Site ) node (including via intermediary ( :Place:Trench ) and/or ( :Place:Area ) nodes, it is relatively easy to perform a query that returns this Activity as one that [:TOOK_PLACE_AT] that Site, even though this relationship was not explicitly recorded between those two nodes.

Analogy

Join row(s) or table(s) linking Activities to their locations.

CIDOC-CRM Mapping

MAYBE include a short summmary here, but leave the details for the designated CIDOC-CRM section.

Relevant Nodes, Directions, and Cardinality

Each Activity must take place at at least one (AND ONLY ONE????) location.
Each Place may be the location of zero or many Activities.

Edge/Relationship Properties

property	type	req?	uniq?	description	example(s)
-	-	-	-	-	-

There are no basic properties for this relationship, unless we decide to include the following audit properties:

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.

Description​

Analogy​

CIDOC-CRM Mapping​

Relevant Nodes, Directions, and Cardinality​

Edge/Relationship Properties​

POSSIBLE: System/Audit Properties​

Example Visualization​