FALLS_WITHIN_PLACE

FALLS_WITHIN_PLACE edge/relationship definition.

Description

Connects a ( :Place ) node to another ( :Place ) node in order to record a nested hierarchical relationship between these places. Examples include the nesting of ( :Place:Context )→( :Place:Trench )→( :Place:Area )→( :Place:Site ), but also the location of Calvin University's campus within the city of Grand Rapids, MI, the location of a storage box inside a particular office, etc.. When Places are nested in such multi-level hierarchies, the relationship should be recorded only between each node and its immediate parent in the nested place hierarchy, as the graph data model excels at traversing such relationship trees.

Analogy

Join row(s) or table(s) linking Places to other Places.

CIDOC-CRM Mapping

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

Relevant Nodes, Directions, and Cardinality

There are several permutations for this edge/relationship, with different cardinalities, depending on the types of Places. Pay careful attention to the details here.

[ :Place:Area ] ——[ :FALLS_WITHIN_PLACE ]——> @[1] [ :Place:Site ] ⟵ @[0..*]

Each Area must fall within one Site.
Each Site may have zero or many Areas that fall within it.

[ :Place:Context | :Place:StratigraphicInterface ] ——[ :FALLS_WITHIN_PLACE ]——> @[1] [ :Place:Grid | :Place:Trench | :Place:Area | :Place:Site ] ⟵ @[0..*]

Each Context or StratigraphicInterface must fall within one Grid, Trench, Area, or Site (whichever is its immediate parent—at Umm Al-Jimal, this will almost certainly be a Trench).
The surface of any Grid, Trench, Area, or Site is recognized as Context "000" (e.g., Context "UJ.000" = somewhere on the surface of Umm Al-Jimal, Context "UJ.U.000" = somwhere on the surface of Umm Al-Jimal's Area U, etc.). This is especially useful for recording surface finds and in survey fieldwork, allowing for context to be recorded as precisely as possible (but even knowing an object was from somewhere at Umm Al-Jimal is useful).
Each Grid, Trench, Area, or Site may have zero or many Contexts or StratigraphicInterfaces that fall within it.

[ :Place:Grid ] ——[ :FALLS_WITHIN_PLACE ]——> @[0..1] [ :Place:Grid ] ⟵ @[0..*]

Each Grid Square may fall within zero or one other Grid Square.
Each Grid Square may have zero or many other Grid Squares that fall within it.

[ :Place:Grid | :Place:StorageLocation ] ——[ :FALLS_WITHIN_PLACE ]——> @[1..*] [ :Place:Region | :Place:Site ] ⟵ @[0..*]

Each Grid Square or StorageLocation may fall within one or more Sites or Regions.
Each Site or Region may have zero or many Grid Squares and/or StorageLocations that fall within it.

Each Point may fall within zero or many Areas, Contexts, Grids, Regions, Sites, StorageLocations, or Trenches.
Each Area, Context, Grid, Region, Site, StorageLocation, or Trench may have zero or many Points that fall within it.

[ :Place:Region ] ——[ :FALLS_WITHIN_PLACE ]——> @[0..*] [ :Place:Region ] ⟵ @[0..*]

Each Region may fall within zero or many other Regions.
Each Region may have zero or many other Regions that fall within it.

[ :Place:Site ] ——[ :FALLS_WITHIN_PLACE ]——> @[0..*] [ :Place:Grid | :Place:Region ] ⟵ @[0..*]

Each Site may fall within zero or many Grid Squares or Regions.
Each Grid Square or Region may have zero or many Sites that fall within it.

[ :Place:Trench ] ——[ :FALLS_WITHIN_PLACE ]——> @[1] [ :Place:Grid | :Place:Area | :Place:Site ] ⟵ @[0..*]

Each Trench must fall within one Grid, Area, or Site (whichever is its immediate parent—at Umm Al-Jimal, this will usually be an Area).
Each Grid, Area, or Site may have zero or many Trenches that fall within it.

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​