Model Concepts

The Shared Object Model provides an environment for collaboration around information in a semantic object model and fosters real-time collaboration and data exchange by allowing multiple stakeholders to work concurrently within a single, unified, seamless object model.

It handles outgoing and incoming work sets from Trimble Connect Object Manager and manages collaboration through the reserve, release, and receive of tasks in work sets.

There are four main concepts involved when creating a Shared Object model:
  • Location: Where the data is located
  • Type Catalog and Objects: What kind of data the model is describing
  • Tasks: Who did what, when, and managing the content in the model

Location

A Shared Object Model is usually defined with a specific public or custom Coordinate Reference System (CRS), but can also be defined with an arbitrary CRS.

Type Catalog

A type catalog is a structured collection of definitions and descriptions of objects and attributes that can be represented in a dataset. These object definitions can have different types of attributes both alphanumeric attributes, spatial attributes (geometry) and locational attributes can be included or not included in the object definition. In the type catalog. Relationships that are allowed between objects are also defined in the type catalog. The default Type Catalog for the Shared Object Model is based on the IFC 4x3 schema (Addendum 2).

A type catalog is essential for data standardization and interoperability, facilitating clear communication and data exchange between different systems and users.

Objects

Objects in the model are occurrences of objects according to the type definitions in the type catalog and may represent real-world objects or objects representing phenomena it makes sense to capture and locate, like a speed limit section located along the road network, or a geotechnical report for a given area.

Object occurrences may or may not have geometries, and it may or may not be located along the network. The object model is based on a generic concept that everything is an object. This includes road superstructure layers, bridges, buildings, walls, windows, pipes, noises, traffic lights, rails, bus stops, piles, and so on.

Tasks

When a large model with many objects is to be shared between many people, this must be done in a way that allows each user to work with exactly their tasks, with associated data, and with a minimum of points of conflict with other users.

Tasks are things that need to be done. It can be a WorkOrder, a road design task, and so on. They are typically organized within a hierarchy (WBS). One task can be input to another (which creates a dependency). Within the Shared Object Model, tasks provide the objects needed to do the task, a way to add result data, and the model sharing.

A task can be:
  • Import data. For example:
    • to add a road corridor by importing a file.
    • add landscape objects and other infrastructure objects with their properties.
  • Creating a model presentation.
  • Exporting information to a file where the input is independent on how the data was created.

The central Shared Object Model information is shared among multiple users who can access and reference information without duplicating data into files. As such, the ability to search, query, and filter is integral to all operations you perform as a user. In the workset of a Shared Object Model, you can query on any task, object, attribute and property, relationship, or location (both area and from/to).

To ensure you have control over your queries, they are connected to a task. All your interactions with a Shared Object Model's workset are governed by this process and task concept.

Working in Isolation and Sharing with Others

The task concept is central to how the Shared Object Model addresses the needs of multiple users. It effectively handles large models, allowing people from different disciplines to work in parallel on their respective tasks. Simultaneously, it enables easy integration of information into the same model for better control and coordination.

In a file-based system, a common approach has been to give each user their own file. While this might seem to avoid "conflict points" initially, conflicts inevitably arise because data isn't synchronized within a single model; instead, it resides in separate, independent files.

The task concept within the Shared Object Model addresses this by effectively acting like a file, but with significant advantages. Just as a file's extension indicates its associated tool and its content is the data, tasks in the task model serve a similar function. However, the crucial difference is that information isn't stored within the task itself. Instead, a task references its input and result objects directly within the object model. This means that these objects remain accessible for other tasks, such as presentations, analyses, and various successor workflows, promoting seamless integration and collaboration.