TIC 4.0
Place (2025.017)
SUBJECT
Fields | Type | Description | Purpose |
|---|---|---|---|
ID (SUBJECT identifier) | M | Place | GRAMMAR |
SUBJECT name | M | Place | GRAMMAR |
Also known as | O | Place, site, point, region, zone, premises, address, spot, location. | TIC Description |
Definition | M | Place refers to a precisely defined and uniquely identifiable place within the subject's operational domain, well defined by its physical dimension, shape and location (mandatory), that can be used, occupied or referenced by an object. This definition includes fixed and moving or permanent and temporary places. | TIC Description |
Further Detail | O | In common language, a place is the place within which an object (usually another SUBJECT) can be placed. There are many ways to define places (or places), and all the places resulting could be used simultaneously, resulting in an overlap. ie (country, region, terminal, yard, road, ground slot). The purpose (reason for being) of a “Place” subject is to organise the processes and the space. Places are usually defined by a geometrical dimension to utilise the space for a primary purpose (to perform a task or to store an object). Place vs Location (place vs address) A Place is a subject itself (place) with a unique id, with its entity, concepts (mandatory to include location), observed properties, point of measurement or attributes and values. A Place always resides in a Location (address), i.e.:
Example
A Place can have a history relative to concepts (available, occupied, reachable, cycle, etc) with its observed properties: events, status, timers, durations, etc. A Location cannot have a history, it just defines “where”. For example, how is Place used in a container terminal? Place can be related to a cargo, or a cargo can be located inside one place. Place - like a container ground slot - can be linked to one or more pieces of objects (cargo), either because it physically holds them or because it's part of their movement (e.g. during a carrier visit). Place can be attached to an equipment or facility (general usage to express where those objects are located). A cargo “X” can be located in place “platform3” or the place “platform3” contains the cargo “X” Two (or more!) Places can be attached to a move/job instruction. A list of Places can be assigned to a terminal residing object (yard, quayside, gate, carrier, CHE etc.). This allows the terminal to organise the processes. Operational BoundariesThe Place boundaries could be defined by the spaces where containers or equipment might reside or be processed:
A typical example is the place “Berth-North” (designed to perform loading and discharging vessel operations) or the “Yard1” (designed to store cargo). They are usually defined by geometrical shapes but could also be defined by the type of pavement or any other particular characteristic, like the type of CHE. Place ConceptsA concept is what is, does, consumes or contains a subject. A Concept can only be, do or consume one thing for a specific timestamp (cannot be true and false at the same time or cannot be a berth and a yard at the same time). A concept “type” is used for classification and can only be one class (one value) at a time.
Place allows the nesting of subsubjects, the most common ones are the relative Places around it: placeabove / placebelow / place+1, +2, `+x, place -1, -2, -y, As one place has many-to-many relations, it is recommended to make the relation through location. The most typical nest subject (object) in a place is the object that contains. ie the cargo or cargo visit that is dwelling in the place. As TIC 4.0 is an ontology, some rules related to the definitions and the relations between them may be applied to guarantee that the information makes sense:
| TIC Description |
Example |
| "place": [ |
|
We introduced the subject https://tic40.atlassian.net/wiki/pages/resumedraft.action?draftId=2262532097&draftShareId=a02cc1a9-70b6-4a43-8d2f-1559cbeed75c and we need to strive to distinguish the idea from the existing concept of https://tic40.atlassian.net/wiki/spaces/TIC40Definitions/pages/608763917.
Location vs. Place: Semantic Distinction
https://tic40.atlassian.net/wiki/spaces/TIC40Definitions/pages/608763917 is defined in the TIC 4.0 Definitions as CONCEPT (https://tic40.atlassian.net/wiki/spaces/TIC40Definitions/pages/8618041/TIC4.0+Semantic#CONCEPT) with underlying OBSERVED PROPERTY (https://tic40.atlassian.net/wiki/spaces/TIC40Definitions/pages/8618041/TIC4.0+Semantic#OBSERVED-PROPERTY) of https://tic40.atlassian.net/wiki/spaces/TIC40Definitions/pages/48070844 and https://tic40.atlassian.net/wiki/spaces/TIC40Definitions/pages/48070837 together with the CONCEPT of https://tic40.atlassian.net/wiki/spaces/TIC40Definitions/pages/488997100.
In contrast to https://tic40.atlassian.net/wiki/spaces/TIC40Definitions/pages/608763917, we introduce https://tic40.atlassian.net/wiki/pages/resumedraft.action?draftId=2262532097&draftShareId=a02cc1a9-70b6-4a43-8d2f-1559cbeed75c as a SUBJECT (https://tic40.atlassian.net/wiki/spaces/TIC40Definitions/pages/8618041/TIC4.0+Semantic#SUBJECT%3A).
Location (concept)
Answers: Where is subject X?
Example: “Where is cargo unit ABC123?”
Subject: the cargo unit (or other tracked entity)
Object: its spatial assignment → Location
Point of reference: usually logical (yard structure) or physical (coordinates)
Academic question: “Where is cargo unit ABC123 currently located?”
Subject | Cargo Unit ABC123 → the entity we are talking about. |
|---|---|
Concept | Location → we want to describe its spatial placement (concept: where it is). |
Observed Property | Coordinate, Logical, Technical → depending on whether we want GPS, yard slot, or technical reference. |
Point of Measurement | Where the observation applies (e.g., measured from crane system, TOS, GPS, or operator input). |
Value | Actual location: Block C1, Row 4, Column 2, Tier 3 (logical) or Lat/Lon (physical). |
Location answers the where question about the subject.
CargoUnit ABC123 → hasLocation → Block C1, Row 4, Col 2, Tier 3.
By formalizing location in this layered semantic, TIC 4.0 enables:
Systems to ask and answer location questions uniformly (where is a subject).
Machine and human systems to interoperate (machines use coordinates; humans use logical slots).
Tracking and control to scale across complex nested hierarchies (subject/subsubject chains).
Place (subject)
Answers: What is located here? → the inverse question, What is this space for?
Example: “What is at Block B, Row 3, Column 7?”
Subject: the physical or logical point/slot/space
Object: the entity currently occupying or assigned to that space
Point of reference: the slot or physical coordinate
Academic question: “What is placeed at Block C1, Row 4, Column 2, Tier 3?”
Subject | Yard slot Block C1, Row 4, Column 2, Tier 3 → the space or spatial anchor. |
|---|---|
Concept | Occupant or assignment → what entity currently occupies this space. |
Observed Property | Identifier → container ID, cargo unit, equipment reference. |
Point of Measurement | Where the observation is anchored (sensor reading, database state, physical check). |
Value | Actual occupant: Cargo Unit ABC123. |
Place answers the what is here question about the subject.
place Block C1, Row 4, Col 2, Tier 3 → hasOccupant → Cargo Unit ABC123
By formalising place as a subject in TIC 4.0’s semantic grammar, the framework enables:
Digital representation of place-based queries such as “what is present here?”, what has happened here across time? What is around me? Am I busy, available or reachable? Am I dangerous, big or small?
Modelling of both static (yard, berth) and dynamic (CHE-mounted, vessel, train) places
Support for multi-layered addressing systems (logical, physical, technical), enabling both human and machine interpretation
Integration of place state, such as
occupied,available,reserved, and links to job instructions or operational processes
This semantic anchor complements the Location concept and enables two-directional tracking:
→ from entity to place (Location), and
→ from place to entity (Place).
Semantic Anchoring of Place
We are striving to properly anchor the https://tic40.atlassian.net/wiki/pages/resumedraft.action?draftId=2262532097&draftShareId=a02cc1a9-70b6-4a43-8d2f-1559cbeed75c within the TIC 4.0 semantic framework. We need to model and distinguish between Location and Place - two semantically related but fundamentally different concepts.
So far we’ve established:
Location
Is a concept applied to a subject (e.g., a cargo unit).
Answers: “Where is subject X?”
Expressed via logical (Block, Row, Tier) or physical (coordinates) references.
Place
Is a subject (tentatively, and this is your concern).
Represents a defined, identifiable place where objects can be located.
Can be fixed (yard slot), moving (CHE slot), or temporary (gate lane, vessel slot).
Answering: “What is located here?”
You realise that a Place must itself have a Location (it is spatially situated in the terminal).
Yet, you are trying to model Place as a subject, while Location is a concept.
This creates an awkward situation:
“If Place is a subject, and Location is a concept applied to subjects — then how do we model the location of a place?”
We're aiming to model:
Terminals having blocks
Blocks having rows
Rows having bays/tiers
Tiers having atomic Places
Places containing cargo or entities
Places are located somewhere
But there’s no clear grammar in TIC 4.0 to:
Express containment relationships (e.g., Place is part of Tier),
Abstract nested addressability,
And connect the content (e.g., CargoUnit) to both
LocationandPlacewithout redundancy.
We want to avoid semantic confusion and design something that is:
Machine-readable (via TIC 4.0's grammar)
Human-logical (clear and consistent)
Extensible (works across yard, quay, vessel, gate, etc.)
Modeling Idea
To make this conceptually clean, we need to define three distinct Concept Classes in your model:
Concept Class | Applied To | Describes |
|---|---|---|
|
| Where something is (logical/coordinate)
|
| as | A container/slot in a structure as an abstract thing that contains something |
|
| What is currently assigned to or stored in it |
This leads us to the nested concept of
“Place is located at” vs “Something is located in Place”
This dual relationship can be formally expressed using inverse properties:
CargoUnit → hasLocation → PlacePlace → hasOccupant → CargoUnitPlace → hasLocation → Coordinate/Logical Reference
Place (Subject)
Field | Description |
|---|---|
| Unique ID (e.g. POS_Y01_035_2) |
| Human-readable name |
| Reference to Yard, CHE, Vessel, etc. |
| Fixed, Moving, Temporary |
| Composite of logical and physical address |
| e.g., |
| What it is intended to hold (e.g. |
© Copyright - TIC 4.0 All rights reserved | Design web by Fundación Valenciaport