A (federation of) platform(s) has to meet particular user requirements. Since it is fairly complex to assess user requirements for all global data pipelines, those stemming from various European Union (EU) funded projects and literature will be transformed into design choices. An example of a design choice is for instance the support of the messaging paradigm, common to most interoperability implementations between organizations. By making these design choices explicit, discussion on their applicability to meet user requirements is supported. Design choices are on distinction of ‘service’, ‘protocol’, and ‘interface’, bilateral versus multilateral business process modeling, semantics, and data governances supported by privacy-enhanced technologies. This section presents choices based on practice inspired research  and briefly reflects the state of the art in research. It does not pretend to be complete, but identifies some basic research questions. The answers to these questions have to be supported by a federation of platforms; the next section shows the mechanisms to do so. Semantics is core to all choices made.
2.1 Participating in a Federated Infrastructure
Currently, organizations bilateral or multilateral develop interoperability agreements, encompassing both functional and non-functional aspects, like message implementation guidelines and process alignment, based on open standards or with proprietary formats leading to closed solutions . Each time a business relation with another enterprise needs to be established, investments in agreements has to be done. Seamless interoperability [7, 17] addresses this problem, but does not provide solutions. [9, 18–19] introduce business process modeling either for bilateral or multilateral interoperability as a solution, but  argues to model only behavior between any two peer entities. There are different ways to specify behavior;  provides transaction templates for bilateral interoperability to construct chains. A generic specification of behavior will not be applicable to all resources, since they all have different goals and capabilities . A generic specification can however serve as a reference framework for specifying these particular goals and capabilities.
This paper proposes to apply the concept of ‘resource’ offering both real time data and providing or requesting logistic services as specified by an ‘Information Profile’ of such a resource. In this respect, several issues need to be addressed, namely how to express the external behavior of a resource in terms of interactions and semantics. The concept of transaction templates to express external behavior for business transactions can be applied ; other mechanisms like events might be required to share any logistic state changes like arrival of a vessel and delivery of a container at its destination. Semantics of one’s profile can be expressed as an ontology, based on a networked ontology of logistics concepts and services (see for instance ontology.tno.nl for a logistics ontology). Semantics of data and behavior need to have a technical binding to a paradigm like messaging and SOA  supported by a syntax like XML or JSON. In case any two communicating organizations have different technical bindings, binding negotiation and a data transformation function have to be implemented, either by a data provider, a consumer, or as service of the federation of platforms (see next section). In case Information Profiles of any two communicating organizations are based on an identical - or matched semantic models, an on-the-fly technical binding by a platform can be constructed, as long as the federation of all platforms support that technical binding.
The concept ‘resource’ with its ‘Information Profile’ needs further research and examples stemming from real use cases. These examples are currently developed in EU funded projects like EU FP7 CORE.
2.2 Data Governance and Privacy Enhanced Technologies
Organizations are hesitant in sharing information due to for instance commercial or liability reasons, e.g. the amount of free capacity of a barge might reduce prices, the location of a truck might increase vulnerability for cargo theft or providing real-time and predicted depth of a waterway might increase liability. There are currently a number of barriers that block the adoption of data sharing amongst resources, e.g. data ownership, privacy, commercial sensitivity, liability, and culture . In this respect, data and events are classified as:
Open data. Data is publicly available to everyone. Open data is normally considered to be available without any costs, but in some occasions like the Cadastre data, one needs to pay.
Community data. Data is shared within a community according agreed rules. Like with open data, one might distinguish free - and paid data.
Partner data. Data is shared with a specific partner.
Internal data. Data is only shared within an organization, according internal data policies (Fig. 1).
Data classification has a lifetime, e.g. it may change over time and/or may be applicable for one or more calls or interactions. For instance, available capacity on a trip may be shared only once in a community at the start of the trip or can be updated during the trip. Communities can also be flexible, e.g. organizations can join and leave a community over time.
The previous figure shows the decision model developed by . It addresses various aspects like data ownership, privacy and commercial sensitivity, and economic aspects, resulting in a data policy supported by interventions. Many of these interventions are supported by privacy-enhanced technologies  like identification and authentication, access control, filtering, and homomorphic encryption . One particular technology might support data sharing for one or more decisions, but we have not yet found these for logistics data sharing. For instance, Role Based Access Control expresses access control for internal data, but a more fine grained access control mechanism like Attribute Based Access Control might be required for partner – and community data. Templates for particular roles can be specified to ease the specification of data policies, e.g. a template for a role like a forwarder. These templates are a form of Role Based Access Control that can thus be refined by organizations meeting their particular requirements as they operate in one or more roles. These templates may implement formal restrictions from a liability and financial perspective, e.g. carriers should not receive any data on the content of a container, whilst they are otherwise liable for any damage or loss to the content.
Role – and Attribute Based Access Control can be expressed as an ontology of a set of rules, based on the earlier mentioned networked ontology for logistics. To support global logistics and supply, protocols are required for a federation of identities . Further research is required with respect to the relation between privacy-enhanced technologies as interventions for data governance and implementing these technologies in real world cases.
2.3 Service, Protocol, and Interface
The Internet design principles of ‘service’, ‘protocol’, and ‘interface’  are applied for specifying a federation of platforms supporting data sharing between organizations. A federated platform is said to offer a ‘service’ to back office systems of supply and logistic stakeholders, e.g. the ability to exchange messages, validate the message structure and content, and validate the message sequence, whereas a ‘protocol’ between any two platforms provides the ability to actually share data with for instance messages. The protocol is the set of agreements for sharing data between any two platforms, independent of a local implementation of the service by each of those platforms to their users, which is called ‘interface’. The service is the conceptual representation of this protocol to a one or more back office systems and/or end-user. The same service can be implemented by various interfaces, e.g. a file sharing mechanism or an API can serve as an implementation of a service. In fact, ‘interface’ is the technical binding of a service offered to back office systems of an organization. The technical binding of an interface can differ from that of an agreed binding of the protocol, which requires transformation by a local implementation of the protocol and service by a platform (Fig. 2).
Introducing these concepts allows conceptually specification of a service and a protocol with different technical bindings, both for the service by its interface and a protocol for interoperability between two local implementations. Complexity reduction of federated platforms is achieved if all participating platforms support the same semantics and technical bindings of the protocol.
Each service – and protocol primitive has a particular structure with control information and a payload, where a semantic model specifies the semantics of the payload. Control information of a service primitive is applied by a local implementation for processing that primitive and constructing a protocol primitive with a negotiated - or on-the-fly technical binding (see before). It allows for instance the transformation between a SOA interface of a service to a message based protocol and vice versa. Communication is already implemented by various protocols and is therefore considered out of scope. Thus, the service and protocol for logistics will be elaborated, whereas a local interface is discussed in the next section considering back office integration.