Add TransportMovement#movementLegs embedded object to transmit stops and distances for multi-stop transports

[NiclasScheiber]

The current TransportMovement implementation does not support multi-stop transports (milk runs) at a satisfactory level. I propose to add a new 1:n MovementLeg embedded object to create a list of locations and distances, akin to MovementTimes. It uses properties defined in the TransportMovement object as of now.

New Class: MovementLeg

Properties: TransportMovement#movementLegs (n): MovementLeg MovementLeg#arrivalLocation: Location MovementLeg#departureLocation: Location MovementLeg#distanceCalculated: Value MovementLeg#distanceMeasured: Value MovementLeg#sequenceNumber: string

Use Case: we need to transmit the distances between Locations in order to break down CO2-emissions according to ISO 14083 and the GLEC-Framework.

[RobZeilstra]

The introduction of a new class MovementLeg is the wrong design decision. A Transport Movement represents already a leg. A MovementLeg will require Movement Times and MovementTimes is already defined on the level Transport Movement.

In a milkrun, each stop marks the arrival of a separate Transport Movement.

Can you please clearify your requirement? 'Not satisfactory' is not a requirement.

[NiclasScheiber]

Thanks for the feedback, I suggest to discuss this in the next DMWG call as a proposal.

While modelling as multiple TMs is possible today, my rationale for this simplification is as follow:

1. Modelling as multiple TM increases traffic on the network due to re-linking all Loads and TransportMeans for each segment

2. Modelling as multiple TMs includes duplicate information (links to Loads/TransportMeans, transportIdentifier, modeQualifier, …) that can be eliminated by that

3. Adding to 1. + 2., stakeholders would also have to deal with less notifications/events to transmit the same information, as in “there was an immediate stop, but your Load is still on the truck”. Just movementTimes + events instead of additional change requests.

4. Since this proposal does not add any new properties, you can parse it exactly the same way as you would with a list of normal TMs (extract separate TMs)

5. Creating multiple TMs can be counterintuitive when you think in TMs as transportIdentifiers, for example on apron transportation where milk runs commonly happen. I faced this myself in discussions already. -> Here, documentation of the multiple TM approach as best practice can also mitigate this

Hope that clears up the background a bit!

[gxclark]

Hello Guys,

Many times there are two separate data structures to track the movements of different things. There is a physical movement of a conveyance (i.e. bus), and the logical movement of the passenger or cargo, a selection of two stops with roles of "boarding" the "alighting", of the many stops possible on a Route.

I thought I would compare these concepts with the OneRecord model, so I was trying to understand the business definition of "TransportLeg" ... when I look at the links below, I do not find a good business definition ...

https://onerecord.iata.org/ns/cargo/index-en.html#TransportLegs "TransportLegs details" https://onerecord.iata.org/ns/cargo/index-en.html#TransportMovement "Activity to describe transports, replaces the TransportSegment in v1.1 and above"

Are these the best definitions that exist? If I'm missing something, please point it out.

Back in the 2020 versions, there used to exist a spreadsheet version: IATA-1R-DM-Logical-Data-Model-vCOTB-Apr2020.xlsx IATA-1R-DM-Logical-Data-Model-vCOTB-Nov2020.xlsx But even these did not have a true business definition.

Back then, TransportSegment contained "CO2Emissions" meaning "Amount of CO2 emitted (e.g. 34 kg/km)". This is now "TransportMovement", and contains the same attribute ... GLEC's "transport chain" (i.e.) and "transport chain element" (TCE) is closely aligned to shipment, and is computed both ways, even if the shipment used only one way transport (typical for freight). Does this satisfy the requirement? It seems to align with GLEC already?

ICAO's CORSIA definitely computes this based on the aircraft's flight distance and flight time (and type of aircraft).

If you want to use the GLEC approach, then the existing TransportMovement seems to align and cover the requirement. The routing and intermediate stops (i.e. VIA points) can make these calculations very complex, so perhaps that is why GLEC took this approach.

Here are two other related models that have pretty good definitions:

This is an example of a detailed data model for an integrated transportation system dealing with buses, passengers (& freight) and the concept of a "ticket" or "ticket type", which contains the origin and destination for the passenger or freight. The definitions are not bad ... https://www.jstage.jst.go.jp/article/eastpro/2007/0/2007_0_368/_pdf

MITRE published the bolczak flight data model: https://www.mitre.org/sites/default/files/pdf/bolczak_flight_data_model.pdf

[DrPhilippBillion]

Dear Niclas,

Great work in General, thank you!

Still I would evaluate if the additional layer adds more benefit than complexity.

Comments on your discussion input:

1. Modelling as multiple TM increases traffic on the network due to re-linking all Loads and TransportMeans for each segment

   • That is ok as it follows the physics orientation: All pieces land and depart again at a transit, even if not unloaded. The data reflects this.

2. Modelling as multiple TMs includes duplicate information (links to Loads/TransportMeans, transportIdentifier, modeQualifier, …) that can be eliminated by that

   • Every data provider can decide if they want to model the transit with an additional transportMovement. As far as I know, Freighters in our network operate on separate Flight Numbers even if it is only separate legs in a multi-stop roundtrip. FRA-(DEL)-HKG is a different Flight than FRA-DEL, even if it is the same aircraft...

3. Adding to 1. + 2., stakeholders would also have to deal with less notifications/events to transmit the same information, as in “there was an immediate stop, but your Load is still on the truck”. Just movementTimes + events instead of additional change requests.

   • Same argument as in 1: doesn´t need to be;
   • plus: additional transparency might be relevant. As always: We cannot decide for the end user what is relevant and what not…

4. Creating multiple TMs can be counterintuitive when you think in TMs as transportIdentifiers, for example on apron transportation where milk runs commonly happen. I faced this myself in discussions already.

   • I would turn the logics around: The transportMovement is primarily the physical movement. That´s the way ONE Record works. If an airlines wants to put an additional logical layer onto it (like the Flight Number), then they must solve the problems. But too many aspects rely on the physics-orientation (emissions, tracking, etc.).

After all, I think the change would lead to more confusion than benefit. We had discussed the milk run examples with Geodis for days, and we didn´t see benefits in putting more layers into it.

Good discussion!

Kind greetings,

Philipp

Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Cargo AG, Frankfurt am Main, Registrierung / Registration Amtsgericht Frankfurt am Main HRB 90085 Vorsitzender des Aufsichtsrats / Chairperson of the Supervisory Board: Dr. Michael Niggemann Vorstand / Executive Board: Ashwin Bhat (Vorsitzender / Chairperson), Dietmar Focke, Frank Bauer

From: Niclas Scheiber @.> Date: Tuesday, 9. April 2024 at 17:15 To: IATA-Cargo/ONE-Record @.> Cc: Subscribed @.***> Subject: [EXT] Re: [IATA-Cargo/ONE-Record] Add TransportMovement#movementLegs embedded object to transmit stops and distances for multi-stop transports (Issue #235)

Thanks for the feedback, I suggest to discuss this in the next DMWG call as a proposal.

While modelling as multiple TMs is possible today, my rationale for this simplification is as follow:

1. Modelling as multiple TM increases traffic on the network due to re-linking all Loads and TransportMeans for each segment
2. Modelling as multiple TMs includes duplicate information (links to Loads/TransportMeans, transportIdentifier, modeQualifier, …) that can be eliminated by that
3. Adding to 1. + 2., stakeholders would also have to deal with less notifications/events to transmit the same information, as in “there was an immediate stop, but your Load is still on the truck”. Just movementTimes + events instead of additional change requests.
4. Since this proposal does not add any new properties, you can parse it exactly the same way as you would with a list of normal TMs (extract separate TMs)
5. Creating multiple TMs can be counterintuitive when you think in TMs as transportIdentifiers, for example on apron transportation where milk runs commonly happen. I faced this myself in discussions already. -> Here, documentation of the multiple TM approach as best practice can also mitigate this

Hope that clears up the background a bit!

— Reply to this email directly, view it on GitHubhttps://github.com/IATA-Cargo/ONE-Record/issues/235#issuecomment-2045437879, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AL5BQXTJXA5Q53SRWNADO2DY4QAXRAVCNFSM6AAAAABF6AJ3J2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBVGQZTOOBXHE. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[NiclasScheiber]

@gxclark: Thanks for this very good input!

Let me clarify: “TransportLegs“ is a nested object to transmit specific flights inside the booking process - so just a structural object (exactly as my proposal)

“TransportMovement” is the activity/process of physically moving things, eg. actual flights or truck rides. This is where you put the typical aviation timestamps such as STD, ATA, … (if a flight). This is also what you centrally use for track and trace. The connection to the Load (Piece and LoadingUnit) is made by a “Loading” node.

Example here: https://github.com/digital-cargo/good-practice-shipment-tracking

I agree that the documentation is a bit lacking at the moment, but it is something actively being worked at right now!

[NiclasScheiber]

Regarding GLEC, I agree that it is possible to derive TCEs from an ONE Record TransportMovement in principle. But it will get messy if goods are dropped off at various locations, think about a truck distributing a number of goods with different airlines (via points) at an airport. If you want to accurately track the travelled distance for each shipment.

Given this scenario in road transport to the airport: FWD -> GHA1 -> GHA2

it would have to be modelled by the Forwarder as two mostly identical TransportMovements: TM1: FWD -> GHA1 TM2: GHA1 -> GHA2

You have to virtually “unload” TM1 and “reload” the new TM2 on each VIA point then - despite no such physical actions happening in reality. And with the Forwarder probably considering TM1 and TM2 to be the same TransportMovement in its dispatching system.

I agree that for flights this approach makes sense @DrPhilippBillion. But not fully convinced for trucking and ground handling movements?

no matter how we decide, we need to formalise somewhere as a best practice

[DrPhilippBillion]

Gread discussion! It´s only that I would recommend the Forwarder to model it more like this:

TM1: FWD -> GHA1 TM2: FWD -> GHA2 If the Shipments for TM2 are not unloaded at GHA1, then there´s no point in modelling it in a chain. It is overlapping Point2Point connections 😉

Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Cargo AG, Frankfurt am Main, Registrierung / Registration Amtsgericht Frankfurt am Main HRB 90085 Vorsitzender des Aufsichtsrats / Chairperson of the Supervisory Board: Dr. Michael Niggemann Vorstand / Executive Board: Ashwin Bhat (Vorsitzender / Chairperson), Dietmar Focke, Frank Bauer

From: Niclas Scheiber @.> Date: Wednesday, 10. April 2024 at 08:17 To: IATA-Cargo/ONE-Record @.> Cc: BILLION, PHILIPP @.>, Mention @.> Subject: [EXT] Re: [IATA-Cargo/ONE-Record] Add TransportMovement#movementLegs embedded object to transmit stops and distances for multi-stop transports (Issue #235)

Regarding GLEC, I agree that it is possible to derive TCEs from an ONE Record TransportMovement in principle. But it will get messy if goods are dropped off at various locations, think about a truck distributing a number of goods with different airlines (via points) at an airport. If you want to accurately track the travelled distance for each shipment.

Given this scenario in road transport to the airport: FWD -> GHA1 -> GHA2

it would have to be modelled by the Forwarder as two mostly identical TransportMovements: TM1: FWD -> GHA1 TM2: GHA1 -> GHA2

You have to virtually “unload” TM1 and “reload” the new TM2 on each VIA point then - despite no such physical actions happening in reality. And with the Forwarder probably considering TM1 and TM2 to be the same TransportMovement in its dispatching system.

I agree that for flights this approach makes sense @DrPhilippBillionhttps://github.com/DrPhilippBillion. But not fully convinced for trucking and ground handling movements?

no matter how we decide, we need to formalise somewhere as a best practice

— Reply to this email directly, view it on GitHubhttps://github.com/IATA-Cargo/ONE-Record/issues/235#issuecomment-2046610664, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AL5BQXSYN2SW4W2ZXBLOFMDY4TKNPAVCNFSM6AAAAABF6AJ3J2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBWGYYTANRWGQ. You are receiving this because you were mentioned.Message ID: @.***>

[NiclasScheiber]

This is currently not possible, since a TransportMeans can only be connected to just one TransportMovement at a time. We would have to lift that restriction then?

[DrPhilippBillion]

Now I get the problem! Yes, we might change this to 1:n. An aircraft can be on >1 TMs, but one TM can only have one TransporMeans. Do you see any downsides here? Remindes me to CodeSharing Flights, with more than one flightNumber…..

Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Cargo AG, Frankfurt am Main, Registrierung / Registration Amtsgericht Frankfurt am Main HRB 90085 Vorsitzender des Aufsichtsrats / Chairperson of the Supervisory Board: Dr. Michael Niggemann Vorstand / Executive Board: Ashwin Bhat (Vorsitzender / Chairperson), Dietmar Focke, Frank Bauer

From: Niclas Scheiber @.> Date: Wednesday, 10. April 2024 at 08:26 To: IATA-Cargo/ONE-Record @.> Cc: BILLION, PHILIPP @.>, Mention @.> Subject: [EXT] Re: [IATA-Cargo/ONE-Record] Add TransportMovement#movementLegs embedded object to transmit stops and distances for multi-stop transports (Issue #235)

This is currently not possible, since a TransportMeans can only be connected to just one TransportMovement at a time. We would have to lift that restriction then?

— Reply to this email directly, view it on GitHubhttps://github.com/IATA-Cargo/ONE-Record/issues/235#issuecomment-2046620287, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AL5BQXWDDST5N6KLS6XUW3TY4TLOTAVCNFSM6AAAAABF6AJ3J2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBWGYZDAMRYG4. You are receiving this because you were mentioned.Message ID: @.***>

[NiclasScheiber]

But isn't that overlapping modelling approach opening a back door for poor data quality? And compromising on the Single Source of Truth? Lifting this restriction would make the creation for one TransportMovement per shipper or freight forwarder technically possible, resulting in potentially hundreds of TransportMovements describing the same flight.

Adding via points (as proposed) inside a TransportMovement is a lot more restrictive. It is mandated then that any single TransportMeans can only operate one TransportMovement at a time. This makes the information more useful for air cargo operations (query for a flight manifest, for example). It also reduces the request load massively, since you would not need to put events on every overlapping TransportMovement and remove duplicate information (saving on Database resources).

[RobZeilstra]

I agree with Philip that a Transport movement is the physical movement. If there is a need to define a milk run, we are free to define a new entity 'RoadTrip', A lot of trucking companies work with Trip ID's. A Road Trip is then a set of one or more consecutive Transport movement(s). A tip: separate the message construction from the data structure construction. Once the data structure is correct and complete you could easily, as a second step, design your information exchange. Always register carefully what the data object is of a message. A Transport Movement provides the information of a Transport leg. In fact the ride/flight/boat trip between two locations without an intermediate stop.

[NiclasScheiber]

Thanks for the input!

Given the scenario of a truck from HAM to BRU, dropping off freight at GHA_BRU1 and GHA_BRU2.

How would you model this currently? Just to be aligned here and ignoring the proposal of this issue.

Option A (sequential) - this is how I understand you @RobZeilstra: TM1: HAM to GHA_BRU1 TM2: GHA_BRU1 to GHA_BRU2

Option B (simultaneously) - this is what @DrPhilippBillion shared: TM1: HAM to GHA_BRU1 TM2: HAM to GHA_BRU2

[gxclark]

Great discussion guys! @NiclasScheiber,

Option A above models the physical movement of the truck. This would be somewhat more technically correct in emissions calculations, although it does get somewhat complicated, especially for backhaul. This approach is certainly what trucking companies do for route planning, asset management, distance computations, etc., etc. These items and analytical capabilities might all be out of scope for 1R?

Option B above seems to be most consistent with the GLEC framework, the "Transport Chain" and elements thereof. Note that the emissions for the freight should be computed as follows: TM1: HAM to GHA_BRU1 + TM1R: GHA_BRU1 to HAM TM1: HAM to GHA_BRU2 + TM2R: GHA_BRU2 to HAM

So, if the goal is to align to GLEC, seems Option B works well.

[gxclark]

Also, @NiclasScheiber thanks for your explanation on Transport Legs and Transport Movements. I was just reviewing the data model last night and saw the division Booking side (plan?) vs "Logistics Activities" side (actual?). The data model ... is a little tough to read ... is there a plan to publish something standard, like UML or an ER diagram? I can assist in this regard ...

[RobZeilstra]

I Fully support gxclark. If you want to construct a Data Model you first choose a methodology. UML is great. I am in favor of Information modeling IDEF1x [https://en.wikipedia.org/wiki/IDEF1X]. Quite old but very, very effective. Especially the concept of applying subtypes is very powerful and more simple than what UML offers. UML is fine but more difficult to read by a broad audience. Next to this each entity must have a definition to prevent discussions. The list of definitions shouldn't be 'hidden'. For defintions you should apply quality rules. I prefer to enforce definitions formatted according to Genus Differentia. See https://en.wikipedia.org/wiki/Genus%E2%80%93differentia_definition

[NiclasScheiber]

Hello, great idea. The main modelling language OWL, formalized as ontology. But for the visualization, we could do better. Mind opening an issue for this?

@gxclark: Alignment with GLEC is not the goal (instead it is compatibility, as in TOC + 1R data => TCE can be calculated). I want to formalize how to handle milk runs with the data model in the future. Option A, Option B (which is not possible with current cardinality restrictions) and Option C (this issue's proposal). We need to align?

[gxclark]

@NiclasScheiber @RobZeilstra OK, new issue regarding the data model is created: https://github.com/IATA-Cargo/ONE-Record/issues/236

Thanks for explaining the objective more fully ... compatible with GLEC, but also the capability to handle multi-stop trucking routes, as well as shipment-oriented movements. I've done that type of modeling before, I will post some example models a bit later.

[RobZeilstra]

In the CargoiQ RFS working group we started last year an initiative to create a data model for all RFS operations. I like to share this with you. As you can see the central entity is Truck Trip. Each Truck Trip has one or more truck trip legs (=Transport Movement). Cargo iQ RFS Data Model Specification v0.5.pdf

[NiclasScheiber]

Hello, thanks for both of your input!

@gxclark: I am looking forward to hearing about your models, but a major rework of the TransportMovement and/or the way Activities are modelled is off the table. ONE Record is already getting implemented as we speak. We may only decide on minor additions (such as the proposed addition of via points) and orchestration (how to use what we have now), unfortunately... If you are interested in the rationale and design decisions, I can try to explain!

@RobZeilstra: Very interesting, thanks for sharing. Looking at the TransportMovement as it is in ONE Record, it contains both properties of a leg and a trip. This results in the ambiguity we are discussing here (and need to solve in one way or another).

[gxclark]

Hello @NiclasScheiber : yes, I understand the situation, if it is implemented, then there are less opportunities to change it. This is normal as a system matures. Also, if it is implemented, then there is the nature of the data that is already loaded. Ideally the definition of the entity should match the nature of the data that was loaded. So, it is a good idea to get the definitions improved before the model is expanded further. I would say there is some risk in implementation, given the status of the definitions, based on experience. If a TransportMovement is ambiguous ... being sometimes "leg-ish" and "trip-ish", then it is worthwhile drilling into those cases (possibly the logical subtypes of TransportMovement), so then it can be properly and logically expanded and continue to make sense and be useful. There might be a type code or indicators implemented to separate the various types, once they are understood, defined and decided upon by the architect and the associated stakeholders. At this point, we are simply responding to your objectives and questions. If these past implementations give you some spark of ideas to expand rationally, including backward compatibility, then great!

@RobZeilstra : Thanks, will review it. The concepts of "Trip" and "Route" are pretty common. What I like about the model already is the definitions.

[gxclark]

@NiclasScheiber @RobZeilstra

Please see example model focused on "milkruns" (i.e. equipment movements & freight loads). Elsewhere in this model, there is the concept of the order, shipment, etc. I'll just mention a few more definitions that are above (i.e. parents) to the entities in this model:

Lane = Standard link between two nodes in a transportation network, with direction and demand.

Lane Route = When more than one route exists between two nodes, each route may have its own collection of segments. Each route may have its own time and cost requirements. This is the standard version of lane used to link facilities in order to optimize transportation requirements.

Lane Segment = The link between a Lane Route and a Segment. For a given Lane Route there can be one or more Segments. The first Segment should have the same origin node as the Lane Route and the last Segment should have the same destination node as the Lane Route. Example: A Lane Route might link an Assembly Facility and a Stocking Facility. The first Segment in the lane route might use mode Road between the Assembly Facility and a port. The second Segment might use mode Marine for a sea voyage to a destination port. The third Segment might use mode Road between the destination port and the Stocking Facility.

So you can see the Lane, Lane Route, Lane Segment & Segment structures match with Option B and GLEC. Whereas the Trip is akin to Option A. This model then links the Trips and Segments with Trip Segment. This model was much more focused on the freight loads that were moved by the Trip, rather than the breadcrumbs of the actual truck movements, but it can be extended to cover these.

It is tricky to cover equipment, moves, loads, and their relationships to shipments, freight, containers, etc.

This model is largely congruent with the UN/CEFACT "Buy-Ship-Pay" trade model (the last time I looked at it in detail): https://vocabulary.uncefact.org/classes

SCIP_transport_definitions.pdf

[NiclasScheiber]

Hello @NiclasScheiber : yes, I understand the situation, if it is implemented, then there are less opportunities to change it. This is normal as a system matures. Also, if it is implemented, then there is the nature of the data that is already loaded. Ideally the definition of the entity should match the nature of the data that was loaded. So, it is a good idea to get the definitions improved before the model is expanded further. I would say there is some risk in implementation, given the status of the definitions, based on experience. If a TransportMovement is ambiguous ... being sometimes "leg-ish" and "trip-ish", then it is worthwhile drilling into those cases (possibly the logical subtypes of TransportMovement), so then it can be properly and logically expanded and continue to make sense and be useful. There might be a type code or indicators implemented to separate the various types, once they are understood, defined and decided upon by the architect and the associated stakeholders. At this point, we are simply responding to your objectives and questions. If these past implementations give you some spark of ideas to expand rationally, including backward compatibility, then great!

@RobZeilstra : Thanks, will review it. The concepts of "Trip" and "Route" are pretty common. What I like about the model already is the definitions.

This is exactly why we are doing this excercise now. I am glad this issue "blew up" so to speak. TransportMovement, as it stands, can be used as a trip or a leg/segment which can be problematic. Current practical use cases are only flights, where milkruns are generally not happening.

More so, this highlights that we need to improve documentation sooner rather than later. Will talk to IATA on how to proceed here. The current model is heavily built on preexisting IATA standards and the outcome of working groups, that is why it is so complex.

Thank you also for sharing your example, really insightful.

[RobZeilstra]

@gxclark : thanks for sharing this data model. It is a very good representation of our actual business. I like the view with the definitions displayed in the entities. We need to ask IATA to also publish TWO views of the 1R Data Model: the current one and a one with the definitions displayed in the entities. I believe this is a must-have if we want more understanding of the 1R model amongst a broader audience. The only things i miss is a standardization of Way points; in the RFS model we introduced the entity Warehouse. When looking to the milk run requirement one could conclude that the industry is in need of such standardization. Furthermore i miss the entity Transportation Service; it is referred to in the definition of Carrier but not modelled.

[gxclark]

Hello @RobZeilstra, @NiclasScheiber Thanks for reviewing the model above, and glad you like the conceptual model documentation that focuses on the definitions. I'll send another subject area of this supply chain model, which is more akin to the 1R "Booking" side, with a focus on the transportation service request. Note that both this model and the 1R model and objectives are aligned in that the Shipment is a request, but it is composed of pieces of freight which are loaded and moved. Let me see if I can answer your questions asked above:

1. Transportation Service: You are right, this is mentioned in the "Carrier" entity. It is also mentioned in the "Trip" entity, which is defined to be providing the transportation services. At a basic level, transportation is indeed provided by some type of power equipment, and it is provided for the freight loaded as payload. This is the "nuts and bolts" viewpoint that we took in developing this model. One might argue that the more logical type of transportation service, which might involve consolidation of freight into larger containing equipment (e.g. HAWBs > MAWB) can also be modeled this way, just with different shippers & carriers holding the shipment contract.
2. Standardization of Waypoints: The way that this was dealt with is the entity named "Segment Waypoint". A Trip, which is providing the Transportation, moves along segments ("Trip Segments") and those Segments have an ordered set of Waypoints. We did not seek to be able to model the planned Waypoints vs the actual Waypoints, as a use case for a Dispatcher or Traffic Controller might require in order to monitor and manage equipment moves. This can be modeled, but it is yet another level of complexity.
3. Warehouse: This is just one kind of Facility that can act as an origin point or destination point for Trips, and has the proper infrastructure to load and unload various Freight Equipment. Many different facilities such as Crossdocks, Manufacturing Plants, Consolidation centers, etc. are capable in this regard, without the need to actually terminate the shipment and check it into inventory, to either be shipped later, be broken down and shipped as smaller units, or indeed be consumed and transformed into different products/items. Warehouse has the role of storing items long term, or be consumed, or reshipped, I would assert, and so it is not as general as Facility. The 1R model now has the concept of "Location", but this seems to be at a higher level, centered around an airport, for example? So, I think that driving down to actual structures where loading and unloading equipment that matches the Freight Equipment to be loaded/unloaded is indeed the right way to go, if that level of detail is required (seems like it is desired).

SCIP_Orders_Shipments_20240422.pdf

There is one more model that I found quite interesting, this is a separate model that is derived from UN/CEFACT, Supply Chain Reference Data Model, which originates from their standardization of supply chain messages (EDI/XML) ... It is an interesting contrast, but it does contain some interesting semantics. In particular, you might be interested in the "logistics transport movement" & associated entities.

UNCEFACT_SCM_RDM_MMT_20240422.pdf

[lambertciata]

Hi all,

We have discussed milk runs a few times in the past and as Niclas said, it is a complex use case that is not really applicable to flights.

Milk runs on current model work to some extent but can be limited as the model was not designed with this use case as a main priority. That does not mean we will not closely look at it but it brings a whole new level of complexity to a model that is already complex to many.

An option that has not been mentioned above is to use Actions to identify stops during a Transport Movement. see below:

This is also a viable alternative in my opinion if we can also consider that ONE Record may not hold all the data for all the ad-hoc use cases. I believe most stakeholders will still have TMS and systems to plan/optimize journeys of trucks for instance, I don't see those integrated within 1R are relying fully on 1R for the data side.

Seconding what Niclas mentioned about the fact hat we do not envision a major refactor of Transport Movement part in the short term, my suggestion would be to think of milk runs as an add-on to the Data Model and consider how we can fulfill the requirement without impacting too much the current model.

These are just some thoughts to further discuss with Data Model group :)

[RobZeilstra]

Hi Christophe, Refactoring impact should not always be an appropriate argument to not model something as it should be. Maybe in this case it is the right decision. Keep in mind that the goal of modelling is to have a precise representation of the real world. It is better to NOT model a part that is in a grey area of the scope of 1R than model a compromise.

I like your idea of handling milk runs as an add-on to the 1R Data Model.

[gxclark]

Hello @lambertciata Please note that the the model above seems a bit strange ... the text says "Loading/Unloading", but the image says "Loading/Loading"? These are supposed to be two types of LogisticsAction, and two different relationships to Transport Movement? Since loadingType can be "Onload/Offload" for both, isn't this just a single child entity?

[NiclasScheiber]

Hi @gxclark, this is indeed some imprecision in wording.

Generally speaking, we consider cargo:Loading to be the LogisticsAction describing „attaching“ OR detaching“ a number of PhysicalLogisticsObjects to a TransportMovement. The property cargo:loadingType set as cargo:LOADING or cargo:UNLOADING describes whether we attach or disattach (offloading and onloading were the terms used before switching to Named Individuals for enums).

The class used to be named cargo:LoadingAction, which was clearer. The concept of LogisticsActions itself is similar to Events from the Federated Platforms DM, if you are familiar with this?

[gxclark]

Hey @NiclasScheiber , Thanks for this reference, I think I found what you referred to: https://www.federatedplatforms.eu/index.php https://github.com/Federated-BDI/FEDeRATED-Semantic-Model This is the correct reference? If so, I will study this too. Thanks!

[NiclasScheiber]

This is correct, yes!

[lambertciata]

Put back in backlog for further review for next release