C2.2 Semantics in iCargo
•Télécharger en tant que PPTX, PDF•
1 j'aime•1,143 vues
The “Semantics in iCargo” webinar was celebrated last 26th of June, 2014. More than 45 attendees learnt why semantics is a solution for transport logistics interoperability problems and how iCargo has solved it. The different developed ontologies as well as the ontology-based components were introduced to the attendees. This event was the first webinar organized as part of the iCargo Training Series, and was organized by Tecnalia and TNO, who were the leaders of the semantic team at iCargo project. At the end of the webinar a Questions & Answers section was open where the main regards were about if agreements were (or not) needed between entities to collaborate, the use of already existing standards, the ontologies implementation or the cost to adopt these solutions by companies.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (15)
Similaire à C2.2 Semantics in iCargo
Similaire à C2.2 Semantics in iCargo (20)
Dernier
Dernier (20)
C2.2 Semantics in iCargo
- 1. www.i-cargo.eu Intelligent Cargo in Efficient and Sustainable Global Logistics Operations Semantics in iCargo --- iCargo Training Series webinar 26.06.2014
- 2. www.i-cargo.eu Intelligent Cargo in Efficient and Sustainable Global Logistics Operations iCargo is a large-scale integrating project co-funded by the European Commission within the FP7 Information and Communication Technologies Work Programme. iCargo involves representatives of the main stakeholders in the areas of research and technological development, logistics companies, shippers and public authorities. The 29 partners coming from 13 countries are coordinated by the Research and Innovation Hub of ATOS Spain. iCargo will design and implement a decentralized ICT infrastructure allowing real world objects, new planning services including CO2 calculation capabilities and existing systems to co-exist and efficiently co-operate at an affordable cost for logistics stakeholders. The iCargo project aims at supporting new logistics services that: ₋ Synchronize vehicle movements and logistics operations across various modes and actors to lower CO2 emissions ₋ Adapt to changing conditions through dynamic planning methods involving intelligent cargo, vehicle and infrastructure systems and ₋ Combine services, resources and information from different stakeholders, taking part in an open freight management ecosystem.
- 3. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Semantics in iCargo Training Session Marta González – Tecnalia Matthijs Punter - TNO
- 4. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu 1. Why semantics in iCargo? 2. Ontologies in iCargo 1. LogiCO 2. Common Framework 3. iCargo components supported by semantics 1. Sematic Gateway 2. Link software Module 4. Summary 5. Q&A Agenda 4
- 5. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Why semantics in iCargo? Motivation and aim 5
- 6. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu The iCargo challenge 6
- 7. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu 7 Semantic challenge in iCargo Truck Con- tainer Road Infra Ves- sel Ship- ment Order Way- bill Ter- minal Tra- der Train Con- sig- nee Con- sig- nor Bulk Tra- der ETA Re- lease Cer- tifi- cat • Different concepts • Different semantics and standards • Different organizations managing data • Different technologies for data sharing and exchange • Bridging the semantic gap • Speed-up IT implementation • Facilitating the iCargo ecosystem • Enabling business level innovations
- 8. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu iCargo Access Points 8 AP AP AP AP AP AP Organization OrganizationOrganization Organization Organization Ecosystem of connected Access Points Mobile Access Points for smart devices SG Semantic Gateway + Link software module to integrate with other systems Link
- 9. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu • iCargo Access Points for data exchange between parties – iCargo REST API for AP-AP interactions • Ontologies to capture semantics – Ontologies are used to deal with huge quantities of heterogeneous data cornerstone of big data – They provide a collection of concepts and their relations – Computer interpretable model of semantics – Used to configure Access Points • Semantic Gateway to connect with other systems – iCargo uses semantic technologies to integrate existing/third party systems, e.g. using existing message-based data exchange Semantics in iCargo 9
- 10. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Ontologies in iCargo 10
- 11. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Mapping multiple models 11 LogiCO Logistics Core Ontology Model A Model B Existing model, e.g. from business parter A mappingmapping Integrates commonly used concepts in logistics from various sources, e.g. WCO, Core Components, etc. Existing model, e.g. from business parter B
- 12. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Developing a new model 12 LogiCO Logistics Core Ontology Specific model New domain model for a new application, e.g. to configure an AP Used as a basis for specification Using semantic tooling
- 13. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu From models to messages 13 Domain model Ontology + specification of processes and interactions Message specifications Message specifications Mapping XML Schema EDI MIG Used by the semantic gateway Provides the capability to integrate existing message based systems into the iCargo ecosystem of Access Points
- 14. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu • Was developed through various EU-research projects for logistics to provide a common framework describing roles, business processes and information models • Specifies: – Information model (UML class diagram) – Processes and interactions – XML messages • Used in iCargo: – As a reference model and means of integration for end-user applications (e.g. chain planning tools) using XML messages – Common Framework Ontology for use with Semantic Gateway Common Framework 14
- 15. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Models in iCargo 15 LogiCO Common Framework Model Semantic gateway + Link software module Access Point Used to configure mapping Common Framework Messages Access Points Used for specific interaction patterns (orders, status messages, etc.)
- 16. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Common Framework – Reference Model The CF Reference Model decomposes the entire transport and logistics domain into manageable sub-domains each addressing responsibility areas. • Interfaces described by UML Class Diagrams, XSD Schemas and XML examples.
- 17. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Interfaces Common Framework – Reference Model Logistics demand Logistics supply Regulation Enforcement TS MWBGIITSD TEP TPS CRS Transportation Network Management TSD TEP GII TS
- 18. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu CF Ontology 18 CF network ontology: • PROTONT: lightweight upper-level ontology for use in Knowledge Management • OWL-TIME: to express facts about topological relations among instants and intervals. • Ontology formalization to include CF information models or messages and logistics controlled vocabularies as Cargo Type, Environmental Emission Type, Currency, etc.
- 19. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu 19 Common Framework Ontology- TSD
- 20. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Common Framework Ontology - TEP
- 21. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Common Framework Ontology - GII
- 22. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Common Framework Ontology - TS 22
- 23. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu iCargo components supported by semantics Semantic Gateway Link Software Module 23
- 24. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Semantic Gateway Access Point Semantic Gateway Semantic Gateway Message
- 25. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Access Point Link Software Module Architecture GII Message Semantic Gateway Temporal RDF repository Knowledge Base SPARQL endpoint Process and Reasoning Link Software Module TS Message TEP Message
- 26. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Link Software Module Vessel VTY-679-431 Container CFG-745-622 Plane PXZ_009_IK Train TR-567-LHJ Initial Situation: Entities in the iCargo ecosystem Company A Company B
- 27. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Link Software Module Message Transport Service Description Container CFG- 745-622 will be carried by Vessel VTY-679- 431 from Bilbao to Rotterdam by Company A. From Rotterdam to Singapur it will be carried by Plane PXZ_009_IK by Company B. Link Software Module A message arrives and the Link Software Module parses it Vessel VTY-679-431 Container CFG-745-622 Plane PXZ_009_IK Train TR-567-LHJ Company A Company B
- 28. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Link Software Module Message Transport Service Description Container CFG-745- 622 will be carried by Vessel VTY-679- 431 from Bilbao to Rotterdam by Company A. From Rotterdam to Singapur it will be carried by Plane PXZ_009_IK by Company B. The ecosystem now reflects: Vessel VTY-679-431 Container CFG-745-622 Plane PXZ_009_IK Train TR-567-LHJ Company A Company B
- 29. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Link Software Module Message Transport Service Description Container CFG-745- 622 will be carried by Vessel VTY-679- 431 from Bilbao to Rotterdam by Company A. From Rotterdam to Singapur it will be carried by Plane PXZ_009_IK by Company B. Vessel VTY-679-431 Container CFG-745-622 Plane PXZ_009_IK Train TR-567-LHJ Company A Company B 1st Shipment Stage 2nd Shipment Stage The ecosystem now reflects:
- 30. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Link Software Module Message Transport Service Description Container CFG-745- 622 will be carried by Vessel VTY-679- 431 from Bilbao to Rotterdam by Company A. From Rotterdam to Singapur it will be carried by Plane PXZ_009_IK by Company B. Vessel VTY-679-431 Container CFG-745-622 Plane PXZ_009_IK Train TR-567-LHJ Company A Company B The ecosystem now reflects:
- 31. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu • The transport logistics chain is made up of actors using their own information systems (IS) for the daily management. • Several standards from the logistics world are used for message exchange – But there is still a need of agreement on using the same language while preserving the internal way of operation at each company. Summary 31
- 32. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu • Two ontologies in transport and logistics were developed in iCargo – LogiCO – Common Framework • Ontology-based ICT tools allow the creation of an environment where transport logistics chain’s actors remain using their own IS while they are real-time situational-aware – additionally, proving a low entry-cost interoperability solution thanks to the avoidance of a costly shared and centralized ICT infrastructure usage. Summary 32
- 33. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Q&A 33
- 34. Intelligent Cargo in Efficient and Sustainable Global Logistics Operationswww.i-cargo.eu Marta González - Tecnalia Matthijs Punter - TNO Thank You 34 iCargo Training - 26 June 2014, Webinar
- 35. www.i-cargo.eu Intelligent Cargo in Efficient and Sustainable Global Logistics Operations Credits: Presented by: Marta González Tecnalia marta.gonzalez@tecnalia.com Matthijs Punter TNO matthijs.punter@tno.nl Material: Marta González & Matthijs Punter
Notes de l'éditeur
- Marta starts the session; introduces the training session. Session will be recorded. There will be a Q&A at the end of the session. People can use the chat-window to ask questions.
- This training session is about semantics. This is just a part of iCargo. Time is limited to talk about all aspects of iCargo. There are separate training sessions e.g. on the business proposition and the IT-environment. http://i-cargo.eu/training_courses Nevertheless, proper handling of semantics are crucial in iCargo.
- This is our challenge: we aim to provide innovative logistics concepts. E.g. being able to plan your chain from door-to-door by looking at available logistic services, being more situationally aware to respond faster to changes, improve load-factors, monitor and reduce carbon emissions. They all rely on the availability of accurate data. iCargo wants to build an ecosystem of interoperable parties that can easily and dynamically exchange this data. If we achieve this, this is the foundation for a new business ecosystem of competing and collaborating parties in the logistic chain.
- Semantics are an important part of this challenge. We do not only need to have the technical connections between the various different organization, but we also need to be able to understand the meaning of the available data. Semantics is about the meaning of data. This is not straight-forward: There are a lot of different concepts to consider in the logistic chain Different actors use different semantics for the same (type of) concept There are different organizations managing data, making it difficult to standardize on exactly one semantic standard. There are different technologies to exchange and share data. So we also have different (message) formats for data. So the resulting semantic challenge is: How can we bridge the semantic gap How can we do this in a way that is very easy to implement (requiring as little implementation efforts as possible) By doing this: facilitate the business and technical ecosystem By doing so: enabling the business level innovations iCargo envisions
- In our IT environment we use Access Points to share data between organizations. Every actor has an Access Point, together they form an ecosystem of collaborating organizations. iCargo Access Points use a specific REST-API to communicate with eachother. We use ontologies to capture semantics (see bullits). Ontologies are used to configure Access Points. We also use a Semantic Gateway to integrate with other systems that use message-based data exchange.
- Now we want to go more in-depth in the use of ontologies in iCargo by presenting the key use cases.
- In the project we developed LogiCO, an ontology that contains commonly used concepts in logistics. It provides built-in links to various existing standards (e.g. WCO, UN/CEFACT, etc.) In this first use case we use LogiCO to create a mapping between other (existing) models. Through LogiCO they become interoperable.
- Second use case could be: developing a new model. E.g. you want to configure your access point to share certain data. A specific model can be defined with LogiCO as a basis. This results in interoperability with other applications. In this way, we specified logistic services.
- Another use case is to provide a mapping between the model and message specifications. In this case we not only need to know the concepts, but also processes and interactions. By doing this we can use the semantic gateway (we’ll talk about this later) to integrate other applications that rely on these messages.
- In iCargo there are several business level innovations. In order to have a common reference (e.g. for pilot implementations), we defined the iCargo Common Framework. This builds on the work in previous projects. It provides semantics, processes and interactions and XML messages. We have now also defined these semantics as an (OWL) ontology – we’ll talk about this later. The XML messages provide a standardized way to integrate existing applications.
- Overview We use LogiCO as a basis for configuring Access Points But we also use the Common Framework as a reference model And are able to integrate with third party models Not just regarding concepts and semantics, but also regarding messages derived from these models, using the semantic gateway Matthijs hands over to Marta for a more in-depth look at the CF mode, Semantic Gateway and the Link-software module.
- The transport and logistics sector is so extensive and complex that a division into manageable domains is a necessity. The Common Framework Reference Model defines these domains and visualizes their overall need for interoperability. Each domain is a responsibility domain with specific responsibilities. Moreover, each domain has an overall role which is responsible for maintaining these responsibilities. In certain domains the overall role may be decomposed into sub-roles. The Common Framework for ICT in transport and logistics is a holistic architecture describing roles and responsibilities, business processes and information models relevant for the transport logistics sector. The Common Framework Reference Model decomposes the entire transport and logistics domain into manageable sub-domains - each addressing responsibility areas. The interfaces are described using UML Class Diagrams, XSD Schemas and XML examples.
- The following information models have been formalized as ontology: -Transport Service Description (TSD). Enables a Logistics Service Provider to announce his or her transport logistics services to one or more clients. -Transport Execution Plan (TEP). A plan for logistics services established jointly between a Logistics Service Client and a Logistics Service Provider. Used from the long term planning (forecasting and capacity planning) until the TEP is finalized (agreed) and ready to be executed. -Goods Item Itinerary (GII). Specifies the route and the time schedule for a transported item. Before the transport takes place, this is the planned route and time schedule. During and after the transport this is the actual route and time schedule. -Transportation Status (TS). Provides the status of the logistics service covered by a Transport Execution Plan. This includes both status on the overall execution and status of the condition of the transported items. -Transport Progress Status (TPS). A transaction where the Logistics Service Provider requests the Transportation Network Manager to provide status information related to a specific transport vehicle regarding its movement in the transportation network. These information models make reference to the 90% of the concepts described by the Common Framework. The codelists for the different concepts as Cargo type, Environmental Emission or Transport Equipment (among other twenty seven codelists) have been programmatically translated into the ontology from the original format in Microsoft Excel. The final aim of the developed CF ontology is to provide a common representation of resources as a mechanism to facilitate collaborative planning.
- The networked ontology approach was selected in order to reuse state-of-the-art ontologies, as much as possible. The criteria to select the ontologies to be reused were that the knowledge domains formalized by each of them cover a subset of the knowledge domain of the CF, and that the selected ontologies have been successfully applied in other environments. The networked ontology design was performed selecting a core or upper ontology, where the rest of existing or ad-hoc developed ontologies are aligned to. The complexity behind these alignments and ontology extensions was minimized thanks to the quality criteria for ontology selection and to the participation in the ontology engineering process of experts on the CF, that is, in the domain to be modelled. The selected upper ontology was PROTON (PROTo ONtology). PROTON was designed as lightweight upper-level ontology for use in Knowledge Management and Semantic Web applications. PROTON is meant to serve as a seed for ontology generation. It is extensible so any particular domain ontology can develop its domain ontology as an extension to PROTON [15]. PROTON has been applied with success when publishing under the Linked Data paradigm ERP (Enterprise Resource Planning) databases. For time formalization, OWL-Time ontology from the W3C was selected. This ontology provides a vocabulary for expressing facts about topological relations among instants and intervals, together with information about durations, and about date and time information [16]. OWL-Time has been used in applications that range from ubiquitous and pervasive computing, information integration, video event representation, to geographic information science, and so on [17]. The knowledge domain to be formalized by the CF ontology was made up by the messages that the different actors (logistics demand, logistics supply, transportation network management and regulation enforcement) exchange. The CF messages included in the ontology formalization were: the Transport Service Description, the Transport Execution Plan, the Transport Status and the Goods Item Itinerary. These messages have so-called core and full profiles. A core profile is a stringent sub-set of a full profile that enables collaborating actors to exchange information without the need of extensive a priori interchange agreements. The core profiles of all these messages were formalized, except in the case of the Transport Execution Plan where the full profile was also formalized. The different Code lists (controlled vocabularies of fixed values) for certain attributes (as Cargo Type, Environmental Emission Type, Transport Equipment Type and up to twenty-seven code lists) were also formalized in RDF, for this purpose it was developed a software module for automatic translation of the code lists in their provided format, to instances expressed in RDF. The final aim of the developed ontology was to be compliant with the first business level innovation - Collaborative planning – providing a common representation of resources as a mechanism to facilitate collaborative planning. www.ackbytecnalia.com
- The Transport Service Description interface is used for a Logistics Service Provider to announce his transport and logistics services. Such a service can be the carriage of goods between origins and destinations, but can also be warehousing or terminal handling services, document handling, and other services related to the movement of goods. The Transport Service Description interface consists of both a request and response message. A Transport Service Description is defined by a Logistics Service Provider (association to Party), may describe service charge information (the association to Payment Terms) and can involve one or more transport services (the association to the Transportation Service class). For a transport service it is relevant to specify the transport movement of the service (the association to the Shipment Stage class which describes transport event data and the associated transport means information). It is also relevant to specify the environmental emission data associated with a service (in the Environmental Emission class).
- This shows the Transport Execution Plan message has been formalized. The Transport Execution Plan is a plan established between a Logistics Service Client and a Logistics Service Provider. The Transport Execution Plan can be used for arranging other kinds of transport services than pure carriage, such as warehousing storage and terminal operation services (consolidation, loading and unloading, etc.). The process of establishing a Transport Execution Plan can be carried out by means of many interactions between the two roles, from what is typically called a quotation stage until the Transport Execution Plan is finalized (agreed). The Transport Execution Plan interface consists of a request and response message.
- This shows the Goods Item Itinerary message has been formalized. The Goods Item Itinerary (GII) interface specifies the route and time schedule as well as other service details for a transported item. It may contain one or more transportation segments, or legs, with different Transport Execution Plans with different Logistics Service Providers. The Goods Item Itinerary is an optional interface, usually taking place after a Transport Execution Plan is committed between a Logistics Service Client and a Logistics Service Provider. In addition to defining the initial route and time schedule, the GII is used to record the actual progress in the form of new estimated times for departure and/or arrival, actual departure and arrival times. The GII is therefore containing information that may be used for analysing the performance (in time) of transport services and for tracing the progress of cargo, if such analysis is required. The usage of the GII will be particularly relevant in scenarios where there are subcontracted parties involved in the transport service execution, for example in so-called third party logistics when a forwarder subcontracts carriers and/or other types of transport service providers at one or more levels or stages of the transport service. During consolidation handling units (and their identifiers) often change and this is reflected in the GII.
- The Transportation Status interface provides the status on a Transport Execution Plan. This includes both status on the overall execution (if the service is according to plan) and the condition of the transported items. The Transportation Status is exchanged between the Logistics Service Provider and the Logistics Service Client. The Transportation Status interface consists of both a request and response message.
- The CF ontology has been used in the both modules going to be described: The semantic gateway and the link software module.
- The semantic gateway allows external companies to the iCargo ecosystem to exchange messages with the companies compliant with such ecosystem. The Semantic Gateway abstracts users from the underlying ontology and the necessary technology to support its operation. The Semantic Gateway approach has been designed considering the case in which several companies are collaborating in a virtual community. This community is built around a commonly agreed information model. The Semantic Gateway enables external companies to offer their services to this virtual community without altering the common data that are shared by such a community. It takes as input the Common Framework messages as well as other kind of messages, and translates them to the Common Framework ontology, offering separate query end points where to query the information contained in such messages.
- - The link module supports a SPARQL endpoint We can integrate it in the Access Point infrastructure / ecosystem of iCargo The LSM (Link Software Module) enriches a shared common model with inferred knowledge from incoming CF messages (using the Semantic Gateway for messages translation) and user-defined rules. From the model, the LSM extracts knowledge to be used in the creation of new outgoing messages. The LSM is intended to be used by a virtual community, as explained above, where the arrival of a new message modifies the shared data. The architecture that supports the Link Software module is the following; it offers REST service for a new message appearance (click). The message is translated by the semantic gateway to RDF, and intermediate repository is created (click). Over the intermediate repository (clik) the information is processed (clik) in order to be incorporated in the knowledge base shared by the iCargo ecosystem.
- Go on with an example for the Link software modules: Suppose this situation, there are a number of entities in the common framework ontology shared by companies in the iCargo ecosystem. These entities are disconnected.
- The Link software module incorporates the semantic gateway for the translation needs that will be highlighted. A Transport Service Description arrives; it indicates that a specific cargo will be carried by a certain VESSEL from Bilbao to Rotterdam, and from there by plain to Singapur. The Link Software module treats it, modifying the common ontology resulting in
- That the disconnected entities are now connected.
- (And the different shipment stages are established. As well as
- The total environmental emission
- the transport logistics chain is made up of actors using their own information systems (IS) for the daily management. Although several standards from the logistics world are used for message exchange, there is still a need of agreement on using the same language while preserving the internal way of operation at each company. The solution to this need opens a new horizon in providing access to information in a common language (taking advantage of existing standards). This common language would allow deploying real-time cooperative planning algorithms to find the best route attending to criteria such as the most green, quick, economic and/or safe route as well as algorithms able to react to real-time events (e.g. delays, accidents, breakdowns).
- A common language, the Common Framework for ICT (CF) in transport and logistics, was developed; how this language is implemented by ontology means and the development of ontology-based ICT tools. Tools allowing the creation of an environment where transport logistics chain’s actors remain using their own IS while they are real-time situational-aware; and, additionally, proving a low entry-cost interoperability solution thanks to the avoidance of a costly shared and centralized ICT infrastructure usage.