Remove all alternative consignment identifiers

[Fak3]

CEFACT BSP RDM has multiple alternative identifiers for a Consignment:

• CarrierAssignedIdentifier
• ConsigneeAssignedIdentifier
• ConsignorAssignedIdentifier
• CustomsIdentificationIdentifier
• FreightForwarderAssignedIdentifier
• IdentificationIdentifier

It has been brought up by @onthebreeze in the mailing list, that having multiple identifiers for a consignment is problematic.

I suggest to remove all the alternative identifiers listed above from the Linked Data vocabulary, since these are inviting implementors to break the interoperability.

We should make it clear in the documentation, that Consignment MUST have globally unique primary identifier.

If some party needs alternative local identifier to be included in the data, it could create its own usecase-specific vocabulary and json-ld context.

[onthebreeze]

This might not be so easy. Lets first understand why there are multiple identifiers and then think about how best to handle it in the vocabulary. Here's a real example

• Penfolds wines Australia is packaging up a shipment of wine for China. In the Penfolds system that shipment is given an id from their SAP system - which would be the "ConsignorAssignedIdentifier".
• Penfolds asks DBSchenker (freight forwarder) to manage the delivery of the wine and so they create a House airway Bill HAWB - which would be the FreightForwarderAssignedIdentifier
• DBSchenker lodges an export manifest with ABF (Customs) and they issue a thing called the customs reference number - which would be the CustomsAssignedIdentifier
• DBSchenker organises a carrier, Qantas to haul the goods to China. It's a big shipment and so there is a 1:1 between the house bill and the master airway bill. Qantas issues a MAWB according to IATA conventions - that is the "CarrierAssignedIdentifier"

It's not always true that the HAWB and MAWB are the same granularity - but they both can represent consignments.

So - this is business reality. How should our JSON-LD vocabulary represent this business reality? One way is to say these are actually separate resources

• A Penfolds created "shipment" resource - with ID == "ConsignorAssignedIdentifier".
• A DBSchenker created "house_consignment" resource - with ID == FreightForwarderAssignedIdentifier
• An ABF created "customs manifest" resource - with ID == CustomsAssignedIdentifier
• A Qantas created master_consignment" resource - with ID == "CarrierAssignedIdentifier"

This would also require a sub-class model where house_consignment" and "master_consignment" are both sub-classes of "consignment" and share all the same properties

or maybe we keep these separate qualified names as attributes of the consignment. But then we dont know which one is really the key entity identifier in a specific case..

thoughts?

[rhemeleers]

I would prefer the first approach whereby house and master consignments are sub classes of consignment and share the same/most properties. In the case of air-cargo, a master air waybill can consolidate multiple house waybills and include multiple CMR if the a shipment is split over multiple truck deliverables.