Recommendations For New Or Updated Standards D50042 FIspace D500.4.2

User Manual: D50042

Open the PDF directly: View PDF .
Page Count: 26

Deliverable D500.4.2

Recommendations for new or updated stand-

ards

WP500

Project Acronym & Number:

FIspace – 604 123

Project Title:

FIspace: Future Internet Business Collaboration

Networks in Agri-Food, Transport and Logistics

Funding Scheme:

Collaborative Project - Large-scale Integrated Project

(IP)

Date of latest version of Annex 1:

Start date of the project:

01.04.2013

Duration:

Status:

Final

Authors:

Esther Mietzsch, Andreas Füßler, Sabine Kläser, Henk

Zwinkels, Daniel Martini, Daan Goense, Christopher

Brewster

Contributors:

Tim Bartram, Heritiana Ranaivoson

Document Identifier:

FIspace-D50042_final.docx

Date:

2015-02-27

Revision:

007

Project website address:

www.cSpace.eu // www.FIspace.eu

FIspace 2015-02-27

FIspace-D50042_final.docx Page 2 of 26

The FIspace Project

Leveraging on outcomes of two complementary Phase 1 use case projects (FInest & SmartAgriFood), aim

of FIspace is to pioneer towards fundamental changes on how collaborative business networks will work in

future. FIspace will develop a multi-domain Business Collaboration Space (short: FIspace) that employs FI

technologies for enabling seamless collaboration in open, cross-organizational business networks, estab-

lish eight working Experimentation Sites in Europe where Pilot Applications are tested in Early Trials for

Agri-Food, Transport & Logistics and prepare for industrial uptake by engaging with players & associations

from relevant industry sectors and IT industry.

Project Summary

As a use case project in Phase 2 of the FI PPP, FIspace aims at developing and validating novel Future-

Internet-enabled solutions to address the pressing challenges arising in collaborative business networks,

focussing on use cases from the Agri-Food, Transport and Logistics industries. FIspace will focus on ex-

ploiting, incorporating and validating the Generic Enablers provided by the FI PPP Core Platform with the

aim of realising an extensible collaboration service for business networks together with a set of innovative

test applications that allow for radical improvements in how networked businesses can work in the future.

Those solutions will be demonstrated and tested through early trials on experimentation sites across Eu-

rope. The project results will be open to the FI PPP program and the general public, and the pro-active

engagement of larger user communities and external solution providers will foster innovation and industrial

uptake planned for Phase 3 of the FI PPP.

Project Consortium

 DLO; Netherlands

 Kühne + Nagel; Switzerland

 ATB Bremen; Germany

 University Duisburg Essen; Germany

 IBM; Israel

 ATOS; Spain

 KocSistem; Turkey

 The Open Group; United Kingdom

 Aston University; United Kingdom

 CentMa; Germany

 ENoLL; Belgium

 iMinds; Belgium

 KTBL; Germany

 Marintek; Norway

 NKUA; Greece

 University Politecnica Madrid; Spain

 Wageningen University; Netherlands

 Arcelik; Turkey

 PlusFresc; Spain

 EuroPoolSystem; Germany

 FloriCode; Netherlands

 GS1 Germany; Germany

 Kverneland; Netherlands

 Mieloo & Alexander; Netherlands

 North Sea Container Line; Norway

 OPEKEPE; Greece

 LimeTri; Netherlands

 Innovators; Greece

 BO-MO; Slovenia

 CIT; Spain

 MOBICS; Greece

 SDZ; Germany

 Fraunhofer IML; Germany

 Snoopmedia; Germany

 Q-ray; Netherlands

 EECC; Germany

 FINCONS; Italy

 CBT; Spain

More Information

Dr. Sjaak Wolfert (coordinator) e-mail: sjaak.wolfert@wur.nl

LEI Wageningen UR phone: +31 317 485 939

Harald Sundmaeker (deputy coordinator) e-mail: sundmaeker@atb-bremen.de

ATB Bremen GmbH phone: +49 421 220920

FIspace website: www.FIspace.eu

FIspace 2015-02-27

FIspace-D50042_final.docx Page 3 of 26

Dissemination Level

Public

Restricted to other programme participants (including the Commission Services)

Restricted to a group specified by the consortium (including the Commission Services)

Confidential, only for members of the consortium (including the Commission Services)

Change History

Version

Notes

Date

001

Creation of the document

10.11.2014

002

Preliminary outline

003

Draft version of introduction, outline of chapters

19.12.2014

004

Draft version of main chapters

14.01.2015

005

Added input from trial

21.01.2015

006

Complete version

06.02.2015

007

Final version

27.02.1015

Document Summary

This document summarizes the recommendations made as result of the Sub-Task 542 “Recommendations,

collaboration and dissemination”. The use of standards in each trial has been evaluated with a focus on

how products, business partners and locations are identified. Based on the gap analysis, recommendations

for future work were made. As a conclusion, open standards, a focus of interoperability and the implemen-

tation of Linked Open Data are recommended.

FIspace 2015-02-27

FIspace-D50042_final.docx Page 4 of 26

Abbreviations

AEF

Agricultural Electronics Founda-

tion

API

Application Programming Inter-

face

App

Software Application

AS2

Applicability Statement 2 (a

data transport specification)

Deliverable

DOOR

Database of Origin and Regis-

tration

DoW

Description of Work

European Commission

e.g.

Exempli gratia = for example

ELS

Electronic Logistic Status

EPB

Electronic Packing List

EPCIS

Electronic Product Code Infor-

mation Services

ERP

Enterprise resource planning

ETO

Electronic Transport Order

European Union

FAO

Food and Agriculture Organiza-

tion of the United Nations

FIA

Future Internet Assembly

FI PPP

Future Internet Public Private

Partnership

FMIS

Farm Management Information

Systems

FP7

Framework Programme 7

Grant Agreement

GRAI

Global Returnable Asset Identi-

fier

GDSN

Global Data Synchronisation

Network

GML

Geography Markup Language

GPC

Global Product Classification

GLN

Global Location Number

GTIN

Global Trade Item Number

HI-Tier

Herkunftssicherungs- und Infor-

mationssystem für Tiere (Ger-

man), Identification and Infor-

mation System for Animals

HTTP

Hypertext Transfer Protocol

ICT

Information and Communication

Technology

i.e.

id est = that is to say

Intellectual Property

IPR

Intellectual Property Rights

JAXB

Java Architecture for XML Bind-

ing

JSON

JavaScript Object Notation

KPI

Key Performance Indicator

Month

OGC

Open Geospatial Consortium

PDO

Protected Designation of Origin

PGI

Protected Geographical Indica-

tion

RDF

Resource Description Frame-

work

RFID

Radio-Frequency Identification

RTD

Research and Technological

Development

RTI

Returnable Transport Item

SDK

Software Development Kit

SGLN

Serialised GLN

SGTIN

Serialised GTIN

SME

Small and Medium Sized Enter-

prise

SOAP

Simple Object Access Protocol

SPARQL

SPARQL Protocol and RDF

Query Language

SSCC

Serial Shipping Container Code

Sub-Task

Task

TSG

Traditional specialities guaran-

teed

URL

Uniform resource locator

VBN

Vereniging van Bloemenveilin-

gen in Nederland (Dutch),

Dutch Flower Auctions Associa-

tion

VVVO

Europäische Viehverkehrsord-

nung (German), European Live-

stock Movement Order

Work Package

XML

Extensible Markup Language

FIspace 2015-02-27

FIspace-D50042_final.docx Page 5 of 26

Table of Contents

1 Introduction ....................................................................................................................................... 7

1.1 Purpose and content ................................................................................................................ 7

1.2 Approach to standardisation process ....................................................................................... 7

2 Use of standards in the trials .......................................................................................................... 8

2.1 Comments on D500.4.1 “Guidelines for the use of standards in FIspace” .............................. 8

2.2 Use of identifiers ....................................................................................................................... 8

2.3 Problems concerning the use of standards or access to standards ....................................... 10

3 FIspace initiatives impacting standardisation ............................................................................. 11

3.1 Arable farming ........................................................................................................................ 11

3.1.1 Developments in and demand from industry .......................................................................... 11

3.1.2 Existing Approaches ............................................................................................................... 12

3.1.3 Implementation and Alignment Path ...................................................................................... 13

3.2 Improvements in data exchange in the Dutch flower chain .................................................... 13

3.2.1 Business collaboration for the logistics in the supply chain of flowers & plants ..................... 13

3.2.2 Floricode develops standards for the logistics ....................................................................... 13

3.2.3 Process model ........................................................................................................................ 14

3.2.4 Standard messages ................................................................................................................ 15

3.2.5 Logistic code lists ................................................................................................................... 16

3.2.6 Logistic labels ......................................................................................................................... 16

3.3 Capturing and storing ambient data during transport ............................................................. 16

3.4 EU Geographical indications and traditional specialities ........................................................ 19

3.5 Improvements in the Meat Supply Chain ............................................................................... 20

3.6 Fish logistic data ..................................................................................................................... 23

4 Conclusions .................................................................................................................................... 23

4.1 Open standards / Open Supply Chains .................................................................................. 23

4.2 Interoperability ........................................................................................................................ 24

4.3 Use of available Linked Open Data resources on food and agriculture ................................. 25

FIspace 2015-02-27

FIspace-D50042_final.docx Page 6 of 26

List of Figures

Figure 1. The actors and logistic locations in the supply chain of potted plants .......................... 14

Figure 2: Logistic processes in the supply chain of flowers & plants ........................................... 15

Figure 3: Logistic label for a package of plants ........................................................................... 16

Figure 4: Showcase systematic IT structure ................................................................................ 17

Figure 5: Overview on Fosstrak EPCIS System .......................................................................... 18

Figure 6: Clients with temperature, humidity and luminosity ....................................................... 18

Figure 7: Geographical Indications – PDO; PGI and TSG ........................................................... 19

Figure 8: Scheme of Meat supply chain ....................................................................................... 21

Figure 9: Example of an eartag ID ............................................................................................... 22

Figure 10: Screen Shot MIP Aggregation App ............................................................................. 22

Figure 11: Fish supply chain ........................................................................................................ 23

Figure 12: The Linking Open Data cloud diagram ....................................................................... 25

List of Tables

Table 1: Structure of questionnaire ................................................................................................ 7

Table 2: Identifiers and standards used in each trial ..................................................................... 8

Table 3: Structure of DOOR database ......................................................................................... 19

FIspace 2015-02-27

FIspace-D50042_final.docx Page 7 of 26

1 Introduction

1.1 Purpose and content

This document covers Deliverable D500.4.2 “Recommendations for new or updated Standards”. Therefore

it is a report with a formulation of proposals towards developments in standards. It is one of three delivera-

bles describing the outcome of Task 540: “Standardization”, which aims to ensure standards are used

throughout the FIspace project and to identify where standards need to be modified or extended. The other

deliverables are

 D500.4.1 Guidelines to use of Standards in FIspace (available since M3), which provided a review of

the relevant standards.

 D500.4.3 Activities and results of the validation with other standardisation organisations and relevant

networks (due in M24)

The focus of this document is on the results of Sub-Task 542 “Recommendations, collaboration and dis-

semination” which examined whether additional standards and specifications will be required for the im-

plementation and roll-out of FIspace. Outputs from the individual trials were collected to identify require-

ments for changes and improvements in existing standards.

This document is also a follow-up of Deliverable D 600.2 “Plan for standardisation for large scale experi-

mentation” of the Phase I project SmartAgriFood. The recommendations made in the earlier document

are addressed also in this document.

The first part of this document evaluates how standards are used in each trial.

There are eight use case trials (subtasks = ST), organized along three themes:

 T 420 Farming in the Cloud

o ST 421 Crop protection Information Sharing

o ST 422 Greenhouse Management & Control

 T 430 Intelligent Perishable Goods Logistics

o ST 431 Fish Distribution (Re)Planning

o ST 432 Fresh Fruit & Vegetables Quality Assurance

o ST 433 Flowers & Plants Chain Monitoring

 T440 Smart Distribution and Consumption

o ST 441 Meat Information Provenance

o ST 442 Import and Export of Consumer Goods

o ST 443 Tailored Information for Consumers

In the next part, gaps are analysed and recommendations for further work are made, which will lead to an

improvement of standards in practical use. Finally, more general recommendations for the use of stand-

ards are made.

1.2 Approach to standardisation process

The basis of this document is the use of data standards in the trials and their needs for formats and proto-

cols to exchange data. In order to collect the input from the trials and to learn about their experiences, a

questionnaire was sent to all trial leads or the responsible technical contact.

Table 1: Structure of questionnaire

Question

Do you have any questions or comments on D500.4.1 Guidelines for the use of Standards in

FIspace?

Please give us access to the API or documentation of your trial or point us to it on OwnCloud

(xml schema, or even code, etc.).

Are you planning to use the baseline apps developed by WP 450?

Are you using any standards in designing your API or naming data field (If yes which ones)?

FIspace 2015-02-27

FIspace-D50042_final.docx Page 8 of 26

Are you using any identifiers for product batches or individual items? If so what is the system?

How are you identifying business partners and locations in your API?

Are there any issues regarding access to information on standards?

Did you experience any problems referring to standards or specifications?

Based on the outcome of this questionnaire, gaps where no standards exist were identified and possible

solutions to fill these gaps were analysed. Additionally, ad hoc-solutions which were realised during the trial

implementation led to proposals for new standards. The analysis focused on the trials related to agriculture

and the food chain. This focus is caused mainly by the availabilty of expert on this domain.

2 Use of standards in the trials

This chapter summarizes the results of a questionnaire, which has been issued to all trials.

2.1 Comments on D500.4.1 “Guidelines for the use of standards in FIspace”

In general, these guidelines are accepted, and the trial partners plan to use related e-business, identification

and communication standards whenever possible.

The trial on Transparency in the Meat Supply Chain (Meat Information on Provenance, MIP) for instance is

based on the EPCIS Standard cited in D500.4.1 with its new features Instance/Lot Master Data and Trans-

formation Event. This enables all business partners involved to refer to individual items as well as to groups

of items with the same parameter values like the same lot number. Identification of locations and parties

with a (Serialized) Global Location Number (SGLN) and Products (SGTIN), including medicine identification

in case an animal has been treated with it, build the unique reference to Products, Parties and Locations.

The VVVO Number (Cattle Identification System) is inherently part of the GLN and country of origin and

can be derived on demand. It is worth mentioning that also living animals are identified by their unique

SGTIN.

In the Flower and Plant supply chain worldwide growers, auctions, traders (importers, exporters and their

customers), carriers and governmental organizations are using the Floricode (semantic) standards that

partly consists of GS1 Standards cited in D500.4.1. The participants in Flowers and Plants Supply Chain

Monitoring trial are also using these standards in their (ERP) applications. New functionality that will be

developed within this trial needs to connect to these existing standards and systems to ensure the useful-

ness of the trial in practice. For this trial project Floricode is developing and improving the standard mes-

sages to support the logistic processes in the supply chain. Together with GS1 Netherlands a recommen-

dation for the labelling of the logistic units (trolleys) based on the use of the SSCC coding is under devel-

opment. This might lead into requests for improving the GS1 Standards globally accordingly.

According to the Fresh Fruit & Vegetables Quality Assurance the enumerated standards on master data

and master data communication are not explained as explicitly as needed for the trial app development.

Additional sources such as the standards themselves must be referred to.

2.2 Use of identifiers

For each trial, the use of identifiers is described in Table 2. The second column describes how the data

fields are structured and relates to the standards used for this. The third column gives the standards or data

formats for the product itself, the last column those for the business partners involved in the relevant supply

chain.

Table 2: Identifiers and standards used in each trial

Trial

Standards in design-

ing the API or naming

data field

Product batches / individual

items

Business partners and lo-

cations

ST 421

Crop Protection

drmCrop

Global Unique Identifier

(GUID), based on ISO15459.

Business Partners are

identified by the GUID.

FIspace 2015-02-27

FIspace-D50042_final.docx Page 9 of 26

Information

Sharing

Structure and definition of

that identifier in the package

DataTypes of drmCrop and

the corresponding xsd

schema for datatypes.

Business Partner’s will be

a Party in the drmCrop ref-

erence model and can ei-

ther be a person or an or-

ganization. The latter can

be a “father” organization

(for example Holding) of

“children” (for example de-

partments). A Party has a

GUID, so the business

partner is identified by the

GUID.

ST 422

Greenhouse

Management

and Control

drmCrop

URI based identifiers with fol-

lowing setup:

[Issuing agency]/[enterprise

id]/[Item type]/[item id]

For example for a CropField

this could be:

ANL/12345678/CFD/1234

Same as Crop Protection

Information Sharing

ST 431

Fish Distribution

and (Re-) Plan-

ning

Data model for book-

ings derived from the

stakeholder’s Softship

installation

Data exchange be-

tween legacy applica-

tions and CargoS-

wApp by Excel files

Global Unique Identifier

(GUID)

Business Partners are

identified by GUID. Loca-

tions are encoded in longi-

tude and latitude by deci-

mal degrees. Ports are

identified by their port

codes.

ST 432

Fresh Fruit and

Vegetables

Quality Assur-

ance

Pilot Implementation

Guide for Masterdata

in the Fruit and Vege-

table Business, pro-

vided by GS1

Other standards for

identifying the deliver-

ies in PIA

GTIN for identifying type of

box in Europool app, GRAI

for individual boxes.

GLIN and Global Gap num-

bers for identifying farmer

(not everyone has both).

There is also company iden-

tification number from Minis-

tries for agriculture e.g. DPA

in Netherlands for fruit com-

panies, etc.

Cf. Product batches / indi-

vidual items

ST 433

Flowers and

Plants Supply

Chain Monitor-

ing

Partners (e.g. grow-

ers) are identified via

GLN, products

(plants) via GTIN, trol-

leys via GRAI and lo-

gistic units (based on

lots) via SSCC. EPC

will also be used since

events are planned to

be communicated via

EPCIS compatible in-

terfaces.

In data communication in our

supply chain the VBN article

numbering system is the

leading standard worldwide

for product identification in

the sense of classification.

For certain types of products

(garden plants) the use of

GTINs starts to develop, alt-

hough customers (like retail

and garden centres) are not

often demanding this code

type up until now. With the

new GTIN guide and the

GPC for Plants and Flowers

in place a rise in the demand

GLN for partner and loca-

tion identification

FIspace 2015-02-27

FIspace-D50042_final.docx Page 10 of 26

of the unique GTIN is ex-

pected.

ST 441

Meat Infor-

mation Prove-

nance

EPCIS is used to cap-

ture and retrieve event

data within the meat

supply chain. Partners

are identified via

(S)GLN and products

via (S)GTIN. EPC is

used to communicate

all events via EPCIS.

Additional references

and terms will be

based on GDD expla-

nations and defini-

tions.

GS1 article numbering

schemes: GLN and GTIN for

master data, LGTIN /SGTIN

(Serialized GTIN) and SGLN

for event related data. VVVO

number as basis for capture

of birth events.

GS1 partner and location

numbering schemes: GLN

for partner identification,

SGLN for more granularity

such as read point identifi-

cation.

ST 442

Import and Ex-

port of Con-

sumer Goods

Data model for

transport demand web

app and the shipment

status mo-bile app de-

rived from the LPA So-

lution in order to en-

sure the integration

between these mod-

ules

Data exchange be-

tween legacy applica-

tions (SAP Extraction

– Order item inputs for

the transport De-

mand) and Transport

Demand Web Appli-

cation by Excel files

Global Unique Identifier

(GUID), based on ISO15459.

The Business Entities are

identified by GUID stand-

ard. In the Shipment Sta-

tus Mobile App and in the

Manual Event & Deviation

Reporting App the check-

point details associated to

location data are encoded

in longitude and latitude by

decimal degrees.

Receiver, Sender, Item are

identified by codes pro-

vided by SAP system.

Pick Up and delivery loca-

tion (Ports details) are

identified by their codes.

ST 443

Tailored Infor-

mation for Con-

sumers

Partners are identified

via GLN and products

via GTIN. EPC will be

used for identifying

products and/or

batches (events) and

will be communicated

via EPCIS compatible

interfaces (mainly mo-

bile phones).

Product data struc-

ture is built on xml and

data field names are

based on GDSN from

GS1.

For packed non-fresh prod-

ucts: GTIN, for fresh products

(vegetables, fruit, daily prod-

ucts, etc): internal EPCIS.

GLN for partner and loca-

tion identification

2.3 Problems concerning the use of standards or access to standards

In general, the trial partners had little or no issues regarding access to information on standards. Software

developers seem to be familiar with the standards relevant to their field. However ST 431 the trial “Fish

FIspace 2015-02-27

FIspace-D50042_final.docx Page 11 of 26

Distribution and (Re-)Planning” reports a lack of information from from the baseline apps and the platformon

the standards used by them.

Regarding the use of standards, the trial developers reported a number of issues, such as lacking continuity

and compatibility and cross-sectorial differences. In detail, the following gaps were identified:

 ISO11783 deviates from OGC/gml, gives wrong interpretation of some Time types and is (too) ab-

stract on some aspects. Corrections or improvements are rejected for reasons of backward compati-

bility.

 Within OGC; gml and ISO19123 are not in line. Gml uses identical names for some complex ele-

ments, resulting in errors by JAXB compilers, which must be overcome by special binding files.

 Issue of the data exchange of actual data of temperature, humidity and radiation measured with intel-

ligent RFID chips on locations and during transport to be able to combine these data with scanning

data. The Plants and Flowers Trial (ST 433) requires the capture of ambient data like temperature or

humidity. EPCIS serves as a basis for the trial. But since ambient data are not event related they

were not in the development of EPCIS focus so far. A general approach to solve this issue was devel-

oped within the trial (see 3.3).

 Registration numbers demanded by authorities like the German VVVO Number for the identification

of farms or the ear tag number should be aligned with identification schemes relevant for B2B or B2C

business. In the Meat Information on Transparency Trial (MIP, ST 441) an approach towards an inte-

gration of the ear tag number into the GTIN has been developed (see 3.5).

 No standard for the description of Geographical indications and traditional specialities (see 3.4)

3 FIspace initiatives impacting standardisation

3.1 Arable farming

Technically, it is possible to capture a considerable amount of data already on-farm in primary production

using either stationary sensor devices, logging facilities on mobile agricultural equipment or data captured

by mobile phones. However, only part of this data can be turned into useful information in the business

context, mostly due to lack of interfaces that are extensible and flexible enough to accommodate individual

user’s needs and environment and to allow for merging a number of data sources. Evaluation and data

interpretation logic building upon that infrastructure fails in that it can often only cover specific use cases

and misses important information that would be relevant for adequate decision support in a heterogeneous

environment.

3.1.1 Developments in and demand from industry

In parallel to the activities within the FIspace project, companies within the agricultural industry and ma-

chinery construction sector and farm management information system providers alike have realized the

potential that lies in integration of existing data sources, capturing and evaluation of mass data and provi-

sion of service networks and frameworks, that allow users to flexibly combine modules and/or apps to an

ecosystem tailored to their needs.

Apart from FIspace, several initiatives worldwide have therefore started out to develop and provide cloud

FMISes, data capturing and distribution platforms like telemetry systems or web based open sensor net-

works for e. g. weather data and modular app frameworks including SDKs for partners to implement their

own modules. There is however also a growing awareness, that farmers’ needs can only be satisfied by

networking several systems. As a consequence, an increasing number of system providers have started to

provide APIs. Currently, a number of solutions are built using ReSTful web services (REST: a set of archi-

tectural principles for web services, e.g. use of the HTTP methods POST and GET) and JSON as a serial-

ization format, however there are also approaches that lean towards different technologies for a number of

reasons, e. g. using POST against a single service URL or using other serialization formats like XML or

more efficient binary encodings. Especially within the agricultural machinery sector, there is also consider-

able effort to enable the most important existing standard for tractor-implement communication, the ISO-

BUS (ISO 11783) for internet based communication and to reuse experience and components created

there.

None of the publicly available specifications in production services currently uses semantic technologies in

the strict sense of the word (which would mean e. g. basing the APIs on an open lightweight, graph-oriented

FIspace 2015-02-27

FIspace-D50042_final.docx Page 12 of 26

agricultural knowledge model and auto-generating interfaces based on that semantic network). Although

matters regarding ease of exchanging data and networking between different systems have improved con-

siderably, real data integration, mapping data content between different systems’ interpretations and cre-

ating holistic data views in interfaces for the users still requires a considerable amount of bilateral discus-

sions, agreements and engineering and programming efforts.

3.1.2 Existing Approaches

3.1.2.1 API Standardization/Recommendation Efforts

ISO 11783 and 16867: Currently, within ISO SC19 WG5, standardization efforts are conducted on a com-

ponent called the agricultural activity server, which should enable providing planned- and capturing realized

working tasks, collecting sensor data from agricultural fields and in the future also information on grazing

animals at a central entity for requests and distribution.

Agricultural Electronics Foundation (AEF): The AEF is an association consisting mainly of representatives

from agricultural machinery industry and management and control software systems and electronics pro-

viders. It maintains a project group (PG9) dealing with farm management system issues and is currently

working on interfaces to enable cloud based systems to interact with mobile farm equipment. By member

overlap, there is a direct relation to the ISO 11783 committees, i. e. approaches developed in AEF are for

the parts, for which it makes sense, likely to be carried on into the ISO. Some partners in FIspace are also

members of the AEF. Based on demand and requirements, specifications from FIspace may be discussed,

improved and – depending on outcome – standardized via ISO through this path.

AgGateway: AgGateway is an US American association defining its role mainly in recommending existing

standards to use to facilitate business communication in agriculture but also to a certain degree conducting

pilot projects to draft new solutions. Together with John Deere, AgGateway is currently working on the

ADAPT APIs (see e. g. http://infoag.org/abstract_papers/papers/paper_257.pdf). There are a number of

sound concepts developed within these projects like e. g. ISOBUS XML to JSON conversion rules for web-

service operation. On the other hand approaches also seem to differ from the paths taken in Europe, e. g.

with regard to using the AEMP telematics protocol that plays no significant role in agricultural telematics

systems in Europe. Also, there is a certain overlap in members of AgGateway and AEF, thus facilitating

exchange between these organizations.

OpenAg Data Alliance: The Open Ag data alliance is a relatively new organization (activities can be tracked

roughly until mid 2014) founded in the US, also promising to provide agricultural APIs. Members seem to

be mainly agricultural software and data providers but also including industry players like Monsanto.

EDI-Teelt version 4: AgroConnect is responsible for standardisation of agricultural information exchange in

the Netherlands. These standards are based on SOAP web services using XML elements. For crop pro-

duction these elements are based on a common reference data model drmCrop. At this moment web ser-

vices are defined for: Cropping schemes, Advice, Laboratory results and Crop production specification.

3.1.2.2 APIs provided by companies

Here, only some of the most notable and publicly visible efforts are described with no claim for complete-

ness nor endorsement for or against a specific implementation. Activities include the ones conducted by

John Deere in the US around the myjohndeere.com platform and in Europe around the 365farmnet.com

platform. Both provide API interfaces and specifications or parts/drafts thereof have been circulated among

people involved in standardization in AEF or AgGateway. Implementations are based on ReSTful web ser-

vices to be called via HTTP.

3.1.2.3 Agricultural Knowledge Models

Already more than a decade ago, farm management system providers discussed potentials of a common

data exchange format accompanied by a flexible, extensible knowledge model, an ontology of agriculture.

These activities resulted in agroXML being developed in Germany. The exchange format was based on

XML and there have been efforts to create an ontology in parallel, describing semantic meanings of data

items. However, a technological analysis at the time of creation of agroXML revealed, that there were nei-

ther tools nor ontology specification methods available, that were able to fulfil the cross-platform, cross-

programming environment requirements necessary to cover the variety of agricultural software systems.

With more recent semantic web developments and simple, but powerful graph representation formats like

FIspace 2015-02-27

FIspace-D50042_final.docx Page 13 of 26

RDF including programming libraries and tools available in almost any major programming language being

available, the situation has improved considerably. That resulted in efforts within the German iGreen project

to create a semantic knowledge model of agriculture called agroRDF, that would allow for multiple seriali-

zation formats to be generated out of a single model, for easily created extensions, even beyond arable

farming only, multilingual support by using standard RDF constructs and that reuses existing standards and

vocabularies and provides for a standardized mapping mechanism against existing APIs and data formats.

The most notable problem around agroRDF is currently its lack of documentation, examples and tutorials

and prototype implementations.

On the other hand, in the Netherlands the drmCrop-Model has been developed, also covering most of

arable farming and worked out to a high level of detail. drmCrop is currently bound to a fixed toolchain using

Enterprise Architect as the interface to create the model and generate serializations and API interfaces.

Although its use is thus limited to a certain set of environments, the use of GUI tool provides an easy path

to dive into the model and derive other implementations.

3.1.3 Implementation and Alignment Path

The most promising approach to alignment probably lies within strengthening the activities within the AEF

on creation of web based APIs and interfaces for agriculture. Major stakeholders – also from FIspace – are

represented within the committees there and there is a chance of aligning European initiatives with efforts

undertaken abroad. While currently, the awareness of advantages of a knowledge model based approach

is not yet developed to a high enough degree, eventually, an introduction of these concepts within work

conducted at AEF might drive industry and companies to pick up methods that would allow for much more

lightweight implementation and facilitated development using semantic technologies.

3.2 Improvements in data exchange in the Dutch flower chain

3.2.1 Business collaboration for the logistics in the supply chain of flowers &

plants

The logistic processes in the supply chain of flowers & plants cause a large part of the total costs of the

products. Before a bunch of flowers (or a potted plant) reaches the consumer this bunch has passed

through a number of logistic steps in the international supply chain. From the original producer who might

be located in Kenya or Ethiopia to the airport in Nairobi, a flight to Amsterdam, transport to the wholesaler

located at a Dutch auction, road transport again to an importer in a country like Norway and finally to the

flower shop in Bergen or Oslo. Apart from all these logistic steps flowers & plants are extremely vulnerable

and have a short lifespan with a vase life after harvesting of on average 10 days. This means that all these

steps have to take place in a few days in the most effective way.

3.2.2 Floricode develops standards for the logistics

Floricode develops and maintains standard business models, business ‘languages’, electronic messages

and code lists for all partners who are involved in the logistic processes in the supply chain like producers,

marketplaces (the auctions), traders, logistic service providers and carriers. These standards give oppor-

tunities for these partners to set up effective ways of business collaboration with electronic messaging with

their business partners to improve the logistic processes. A platform like FIspace can support this business

collaboration.

For more information see:

http://www.floricode.com/en-us/standardization.aspx

The technical specifications of the standards are available mostly in English, although some older docu-

ments might only be available in the Dutch language.

As part of this trial project of FIspace Floricode together with GS1 Netherlands and several business part-

ners from the industry developed a new standard for the logistic label to be used in the supply chain of

Flowers & Plants (see § 3.2.6). This new standard was introduced officially on the yearly relation day of

Floricode on January 23 2015:

(http://www.floricode.com/Default.aspx?tabid=86&novusact=viewarticle&articleid=34).

FIspace 2015-02-27

FIspace-D50042_final.docx Page 14 of 26

Also the latest version of the standard messages for the logistic domain (see § 3.2.4) were developed and

published on Floricode’s website:

http://www.floricode.com/nl-nl/partijen/softwareleverancier/softwaredevelopmentkit(sdk)/xmldocumen-

tatiemethodiek/xmllogistiek.aspx

Software developers can make use of our Test Center to test the implementation of these logistic standard

messages:

http://www.floricode.com/en-us/partijen/softwareleverancier/testcenter.aspx

Code list (see § 3.2.5) are available both on the website and on the FTP site. A username and password

are necessary to get access to these code lists:

http://www.floricode.com/en-us/distribution/downloadingcodes.aspx

3.2.3 Process model

Standardization starts with the setup of a general process model for the international supply chain of flowers

& plants. The actors and logistic locations involved can be presented as follows:

Figure 1. The actors and logistic locations in the supply chain of potted plants

Next step is to define the logistic processes and the information flows between the partners involved. Part-

ners in logistic processes have a role as consigner, consignee, logistic agent and/or carrier.

FIspace 2015-02-27

FIspace-D50042_final.docx Page 15 of 26

Figure 2: Logistic processes in the supply chain of flowers & plants

In the phase of logistic planning, most of the time there will be no exchange of electronic data. Consigners

and consignees can ask logistic agents and carriers for their offers both for logistic services as well as for

package services. In this supply chain logistic agents (like the auctions) and carriers can offer services to

stock and deliver RTI’s for their customers. Both consigners and consignees (e.g. producers and exporters)

need RTI’s and single-use packaging to perform their logistic processes. Based on these offers consigners

and consignees will come to agreements or contracts how they will cooperate and execute the logistic

processes in the operational phase.

3.2.4 Standard messages

In the operational phase of the logistic processes a data exchange based on standard messages will

become common business in the supply chain of flowers & plants. Floricode has developed three specific

logistic electronic messages bases on the UN/CEFACT EbXML standards:

 The Electronic Transport Order (ETO):

o Consigner or consignee can send an order for the execution of a consignment to his lo-

gistic agent or carrier

o The order will be acknowledged by the logistic agent/carrier

o The order will be planned by the logistic agent/carrier

o The order can be changed or withdrawn

o The same is applicable for the order of package services like the delivering of RTI’s

 The Electronic Packing List (EPB):

o Based on the ETO and the original purchase order of the customer the definitive compo-

sition of the complete consignment with the exact loading of all the load carriers with

(SSCC) codes, lot numbers, packing list numbers etc. is exchanged from consigner to

carrier and consignee.

o The consignee has the opportunity to send an EPB-delivery advice to the consigner in

advance to demand for the exact loading of the different products on the load carriers.

o The EPB can be changed or withdrawn.

 The Electronic Logistic Status (ELS):

o All the partners involved in the execution of each transport order can deliver actual status

information to the other partners; some relevant statuses are:

 Ready for pickup

CONSIGNEE

Logistic operation

CONSIGNER LOGISTIC AGENT/

CARRIER

Logistic planning

Product

Order

handling

Package

planning

Transport

Handling

Product

Order

handling

Package

planning

Transport

Handling

Transport

planning

Transport

purchasing

Transport

order

Transport

planning

Planning

Product

logistics

Planning

package

logistics

Logistic

Planning

Package offer

Planning

Product

logistics

Planning

package

logistics

Logistic

planning

Offering

logistic

services

Offering

Package

services

Package

order

Transport

purchasing

Package

order

Transport

order

Status

message

Status

message

Transport

operation

Package

planning

Transport

planning

Despatch

message

Transport

Handling

Transport

selling

Despatch

message

Transport

Handling

Transport

selling

Package

agreement

Transport

agreement

Transport

offer

Logistic

planning

Transport

offer

Transport

agreement

Package offer

Package

agreement

Logistic

planning

FIspace 2015-02-27

FIspace-D50042_final.docx Page 16 of 26

 Exception

 Planned transport

 Pickup done

 Delivered

 Hub in

 Hub out

3.2.5 Logistic code lists

Floricode develops and maintains a relevant code list which must be used in the electronic data exchange

for logistic processes mentioned above. All companies involved in the supply chain have a Global Location

Number (GLN) company code and all relevant logistic locations for loading and unloading shipments have

a GLN. Floricode also maintains a code list for RTI types and packaging types which are in use in this

supply chain.

3.2.6 Logistic labels

Up to now the ‘auction packing list’ is used as the standard to support the execution of almost all the logistic

processes in the Dutch supply chain. Because of the internationalization of the supply chain in the last

years it is of importance to have a general international standard for the use of logistic labels. Therefore

Floricode together with GS1 has developed an implementation guideline for the use of standard logistic

labels (with SSCC codes) for the logistic processes in the supply chain of flowers & plants

(http://www.floricode.com/en-us/coding/floriculturelogisticlabel.aspx).

Figure 3: Logistic label for a package of plants

3.3 Capturing and storing ambient data during transport

The plants and flowers supply chain is a good example for the need of ambient data on every step of the

supply chain. As described in the process model in chapter 3.2.3 the path from the grower to the con-

sumer comprises several steps. Nonetheless, consumers want to have fresh and high quality flowers. A

quality management system capturing and documenting ambient data like humidity, temperature or lumi-

nosity can help to monitor storage and transport condition and avoid deterioration or spoilage of the

plants and flowers and thus help to save resources.

FIspace 2015-02-27

FIspace-D50042_final.docx Page 17 of 26

This implies the data must be captured, stored in a semantically consistent manner and communicated

via standardised interfaces. To meet these requirements a showcase based on EPCIS and implemented

on a small single board computer (“Raspberry Pi”) was developed. This computer provides several com-

munication interfaces to establish connection between the physical and the digital world.

In the scenario sensors capturing temperature, humidity and luminosity were attached to the Raspberry Pi

in order to document these quality determining data during transport. The computer also allows for decod-

ing barcodes or RFID tags through a reader connected via Bluetooth. This allows for the linkage between

the captured data and the product ID (GTIN) or the ID of the logistic unit (SSCC) or the RTI (GRAI). The

documented data can be shared in FI based systems like FIspace and checked against the optimal data,

either by a person or by means of an automated alert system.

In case the conditions do not meet the requirements of the flowers and plants, the lorry driver can be in-

formed and he can act accordingly. During loading and unloading processes the SSCC should be de-

coded and condition data should be communicated through the system.

These fine granular data captured during transport and storage allows for ex post data analysis e.g.: on

the transport duration, external impacts and the quality of the products. To guarantee semantic interoper-

ability of this cross-company communication it is based on GS1 Standards: Event data structures are EP-

CIS compliant and the capture and query interfaces for interactions with EPCIS repositories are standard-

ised as well. Moreover the events are communicated via XML as also defined in EPCIS. This allows for

the combination of numerous technologies and application systems such as ERP, Supply Chain Manage-

ment or Warehouse Management systems. Events like the transport of flowers or temperature measure-

ment are captured according to the four dimensions “what, when, where and why?” and documented in

Figure 4: Showcase systematic IT structure

FIspace 2015-02-27

FIspace-D50042_final.docx Page 18 of 26

an EPCIS repository. For data transfer the EPCIS repository uses HTTP in the capture interface. The

query interface exploits SOAP, XML via AS2 and XML via HTTP(S). The free of charge EPCIS Fosstrak

System and three sensors and a touch display were installed on the Raspberry Pi (see Figure 5 ).

Figure 6: Clients with temperature, humidity and luminosity

In all, the combination of the Raspberry Pi accompanying the products during transport and capturing am-

bient data and reporting the real-time data to a system via standardised interfaces and in a standardised

semantic allows for low-cost quality monitoring of plants and products and can add to less quality de-

crease in the domain.

Figure 5: Overview on Fosstrak EPCIS System

FIspace 2015-02-27

FIspace-D50042_final.docx Page 19 of 26

3.4 EU Geographical indications and traditional specialities

Three EU schemes known as PDO (protected designation of origin), PGI (protected geographical indica-

tion) and TSG (traditional speciality guaranteed) promote and protect names of quality agricultural products

and foodstuffs.

Figure 7: Geographical Indications – PDO; PGI and TSG (Source: http://ec.europa.eu/agriculture/qua-

lity/schemes/index_en.htm)

The registration procedure involves three main steps: application, publication and registration. The user

can find out which product names are registered or have been applied for in the DOOR database (“Data-

base of Origin and Registration). The DOOR database (link: http://ec.europa.eu/agriculture/qual-

ity/door/list.html) is openly available. It can be browsed in a web interface or downloaded as an Excel sheet

with the following fields:

Table 3: Structure of DOOR database

Field name

Comment

Searchable

and sortable in

web interface

Dossier Number

Designation

Name, e.g. “Stornoway Black Pudding”

Country

ISO

Status

Applied

Published

Registered

Type

PDO - Protected Designation of Origin

PGI - Protected Geographical Indication

TSG - Traditional Speciality Guaranteed

Last relevant date

The date when the current status was ac-

quired

Product Category

e.g. “2.1 Beer”

Latin Transcription

Needed for e.g. Greek product names

FIspace 2015-02-27

FIspace-D50042_final.docx Page 20 of 26

The database contains a few multi-country entries, which refer to meat products from the Slovak Republic

and Czech Republic.

Each entry links to the official documents for publication and registration.

The publication document covers the relevant information for the product in a number of paragraphs fol-

lowed by free text. The documents are available as PDF in 22 official languages. The ‘BAYERISCHE

BREZE’/‘BAYERISCHE BREZN’/‘BAYERISCHE BREZ’N’/‘BAYERISCHE BREZEL’ will be used here as

an example .

The structure of this document is as follows.

PGI /PDO

1 Name

2 Member State or Third Country

3 Description of the agricultural product or foodstuff

3.1. Type of product (e.g. “Class 2.4. Bread, pastry, cakes, confectionery and other baker’s

ware”)

3.2. Description of product to which the name in point 1 applies

3.3. Raw materials (for processed products only)

3.4. Feed (for products of animal origin only)

3.5. Specific steps in production that must take place in the identified geographical area (as in

5.1 below)

3.6. Specific rules concerning slicing, grating, packaging, etc.

3.7. Specific rules concerning labelling

4 Concise definition of the geographical area

5 Link to the geographical area

5.1. Specifity of the geographical area

5.2. Specifity of the product

5.3. Causal link between the geographical area and the quality or characteristics of the product

(for PDO) or a specific quality, the reputation or other characteristic of the product (for PGI)

The geographical area as described here might be a political entity like “Bavaria”, or defined by other bor-

ders such as “Ottersburg municipality, bordered to the south-east by the A1”.

The documentation of the geographical indications is far from being machine readable. The key information

for each product is available as PDF only. The structure of these documents seems to vary. Notably the

last paragraph might include historical anecdotes and other information which can be interesting to read

but might have little legal relevance.

Though an ISO standard exists to describe geographic regions like countries or areas within a country and

GS1 data fields and application identifiers referring to those codes, from trial perspective more granularity

is needed to reflect provenance of specialities with regional background. Efforts should be made to make

the information available no only as text but as machine readable structured data.

3.5 Improvements in the Meat Supply Chain

The meat supply chain has many intermediate stages with several complex processes. From slaughtering

to deboning the meat is processed several times. The processing can involve cutting and/or mixing steps

in which the logical link between inputs and outputs might get lost. It is therefore vital to capture information

at critical processing steps.

Submission date

Publication date

Registration date

1st Amendment date

2nd Amendment date

3rd Amendment date

FIspace 2015-02-27

FIspace-D50042_final.docx Page 21 of 26

The trial Meat Information on Provenance (MIP) aims at bringing more transparency to meat and meat

products within the entire meat supply chain by using EPCIS. All meat supply chain processes are stored

in one or more repositories that are designed to store EPCIS events.

Following the EPCIS standard, each time a data item is read, an event is generated containing fine-granular

visibility data encompassing four dimensions: what (uniquely identified objects), where (location and read

point), when (time of event) and why (status and business process). The events are stored in a database

(called EPCIS repository). The solution based on EPCIS within the MIP trial is based on the latest EPCIS

1.1 version (http://www.gs1.org/docs/epc/epcis_1_1-standard-20140520.pdf). It allows for capturing events

related to a group of animals or products that have undergone the same process (LGTIN) and the transfor-

mation event such as the slaughter of a calf or a processing step.

Compared to conventional traceability procedures the user can retrieve information beyond those he re-

ceives from his direct supply chain partners. Even upstream information on live animals like the birth of a

calf or an inspection and information requested by law stay accessible throughout the entire supply chain

can be queried.

Figure 8: Scheme of Meat supply chain

FIspace 2015-02-27

FIspace-D50042_final.docx Page 22 of 26

Figure 9: Example of an eartag ID (Source: Angela Schillings-Schmitz)

The screenshot of the MIP Aggregation App shows the linkage between the Eartag ID (requested by law)

and the (S)GTIN. Whereas the Eartag ID is displayed in a dedicated data field it is also the serial part of

the SGTIN. For all downstream processes the SGTIN as state of the art ID will be sufficient and the Eartag

ID can easily be derived. This screenshot also shows that when entering the ID of a calf all events related

to this calf like processing steps or examinations are displayed.

Figure 10: Screen Shot MIP Aggregation App

The slaughter event includes data like the slaughtering number and the identification of the mother, as

requested by the German HI-Tier database (http://www2.hi-tier.de/Entwicklung/Grundlagen/Default.htm).

Thus once authorities accept FIspace as reliable and sufficient data source and implement it the pieces of

information mentioned above can be used to populate authority data bases and need to be captured by the

farmer only once in a system.

FIspace 2015-02-27

FIspace-D50042_final.docx Page 23 of 26

With its established data fields like (S)GTIN and S(GLN) the information can be used as input to B2C

applications such as a consumer app.

3.6 Fish logistic data

To meet the legal requirements on fish traceability in Europe (see

Figure 11: Fish supply chain below for the fish supply chain), the following attributes/key data elements are

of special interest:

•coastal fisher

•inshore fisher

•far-sea fisher

•fishmonger

•food service

•market

•restaurant

•supermarket

•auctioneer

•importer/exporter

•port agent/broker

•wholesaler

•pallet of crates

•pallet of water tank(s)

•crate/box

•water tank

•live seafood

•fresh seafood

•chilled seafood

•frozen seafood

•further processed fish

•commercial fishing vessel

•subsistence fishing

•fisher

•aqua culturist

•fishing farm

•wild fish ranch

•commercial farm

•subsistence farming

primary processor*)secondary processor*)

e.g.

•washing

•heading and cutting

whole fish catching/harvesting •filleting

•skinning

•inspection

•cooking

•pressing

•drying

•freezing

•packaging

*) A processor does not need to be a separate party. A fisher or aqua culturist could take on this role as well.

mixed fish

•fixed/variable weight

•graded/ungraded

•full fish

•fish parts

•fish dish

•fish oil

depending upon

number of sales

and processing

steps

Figure 11: Fish supply chain

GTIN, lot, quantity or net weight, expiration or best before date (dependent upon product of concern), fishing

vessel GLN, production unit name, fish species, scientific name, commercial designation, catch area, catch

date(s), supplier GLN, supplier name and address, production method, first freeze date, storage state code,

fishing gear type, fish quality grade, fish size and fish presentation.

In order to support the business processes on each of these data elements GS1 provides automatic iden-

tification data capture (AIDC), electronic data interchange (EDI) (both EANCOM and XML), EPCIS as well

as GDSN standards.

Instead of exchanging data manually via Excel files, the use of GS1 standards could significantly improve

business processes in this context.

4 Conclusions

4.1 Open standards / Open Supply Chains

An open supply chain is one in which the complete set of trading partners (including service providers) is

not known in advance and changes continually. This is because:

 trading partnerships change so that new relationships have to be accommodated

 an organisation may be unaware of the destination or provenance of its products and other relevant

entities because it is unaware of the (upstream) trading relationships of its trading partners.

GS1 standards that are applied at the interfaces between trading partners are defined outside the context

of any particular trading relationship. This provides interoperability without the need for organisations on

each side of the interface to negotiate individually in advance.

FIspace 2015-02-27

FIspace-D50042_final.docx Page 24 of 26

At the heart of this, the GS1 Identification Keys provide identification that is not dependent on any particular

business relationship or process. Identification of trade items, services, locations, assets and other busi-

ness objects can be communicated to anybody anywhere in the world without any limitation and without

requiring qualification by one of the parties. This means that identification is portable across the entire

trading partner base including into unforeseen relationships and processes.

The acceptance of standards is expected to be higher, if the pre-conditions to access them are

lower. Free access and no or only nominal fees are therefore recommended.

4.2 Interoperability

Interoperability is the capability of different systems to exchange data based on a shared understanding

of business processes, to read and write in compatible formats and use compatible protocols. If competi-

tors' products are not interoperable (due to causes such as patents, trade secrets or coordination failures)

the result may be a monopoly, market failure, or costly inefficiency.

As for GS1 Standards it is requested that the GS1 System Architecture should promote interoperability.

This can be achieved in four ways:

1. Through product engineering,

2. Industry/community partnership,

3. Access to technology and intellectual property and

4. Implementation of standards.

Apart from this GS1 System components and any underlying processes that are developed must strive to

be interoperable in their design, development, and implementation to enable the widest adoption and us-

age by the GS1 community.

The GS1 System Architecture should support the integration of information and physical flows into trading

partners’ systems, so that as far as possible the business process can be supported by automated machine-

to machine messaging, providing a seamless flow of information through to the end user.

There is evidence of interoperability between applied standards within and across the FIspace trials. Here

are some examples:

 Floricode closely works together with GS1 (More information: http://www.floricode.com/en-us/cod-

ing.aspx). The VBN Code for flowers and plants traded in auctions is transformed into a GS1 data

structure and encoded in an EAN/UPC Code when sold at Point of Sale.

 Though VBN is used to categorize plants and flowers the need to enhance the Global Product

Classification (GPC) developed under the umbrella of GS1 was anticipated in the domain. Thus

from the end of 2014 GPC on bricks for the most common (appr. 800) plants and flower types ex-

ist. Whereas VBN maintains to be relevant in case full comprehensiveness is needed it will be

complemented by the GPC especially in case of downstream/retail business (More information:

http://www.gs1.org/1/productssolutions/gdsn/gpc/browser/index.html).

 All GS1 Identification standards have an ISO equivalent or are referenced by ISO standards

(http://www.gs1.org/1/productssolutions/gdsn/gpc/browser/index.).

 ISO/IEC 15459 is a series of standards specifying identification rules for logistic units, items, re-

turnable assets and groupings. This ISO/IEC standard is used in the Crop Protection Information

Sharing Trial. The standards make provision for Issuing Agencies Codes (IAC) that create

uniqueness between identification schemes from various bodies by prefixing the identifiers with a

code assigned by a registration authority. The IAC 0 to 9 have been assigned to GS1 (More infor-

mation: http://www.gs1.org/1/productssolutions/gdsn/gpc/browser/index.html).

 GS1 uses ISO 3166 Country Codes in the relevant data fields and application identifiers such as

the country of origin or the country of production.

The GS1 System Architecture should support the integration of information and physical flows into

trading partners’ systems, so that as far as possible the business process can be supported by

automated machine-to machine messaging, providing a seamless flow of information through to

the end user.

Besides openness and interoperability further principles are of relevance. A good overview could be found

at http://www.gs1.org/docs/architecture/GS1_Architecture_Principles.pdf.

FIspace 2015-02-27

FIspace-D50042_final.docx Page 25 of 26

4.3 Use of available Linked Open Data resources on food and agriculture

Tim Berners-Lee suggested a 5 star deployment scheme for Linked Data (see http://5stardata.info).

1. Data is available on the Web, in whatever format (1 star)

2. Available as machine-readable structured data, (i.e., not a scanned image) (2 stars)

3. Available in a non-proprietary format, (i.e. CSV, not Microsoft Excel) (3 stars)

4. Published using open standards from the W3C (RDF and SPARQL) (4 stars)

5. All of the above and links to other Linked Open Data (5 stars)

Some data on agriculture, food production and logistics can be already classed into one of those levels –

each marked with one up to five stars. However, only a few resources reach the upper levels, especially

four or five stars. A directory of Linked Data can be found at datahub.io. There is also a well-known and

ever-growing graphical representation available (see Figure 12).

Figure 12: The Linking Open Data cloud diagram (Linking Open Data cloud diagram 2014, by Max

Schmachtenberg, Christian Bizer, Anja Jentzsch and Richard Cyganiak.

http://lod-cloud.net/)

The open standards RDF and SPARQL are the core of the semantic web. RDF (Resource description

framework) is a syntax for defining a data model describing triples of subject, predicate, object. SPARQL

is a query language for querying RDF datasets. A SPARQL endpoint accepts queries and returns results

via HTTP.

A central resource for agriculture within the semantic web is CIARDRING, a directory of information ser-

vices and datasets in agriculture (http://ring.ciard.net/sparql1). The FAO’s multilingual thesaurus Agrovoc

is also available a SPARQL endpoint (202.45.139.84:10035/catalogs/fao/repositories/agrovoc). Denmark

published its agricultural government data as semantic web data (http://extbi.lab.aau.dk:8080/sparql/). A

domain-specific project is the ontology on beef production (http://onto.beef.org.pl/sparql.html). Another use-

ful resource for the agrifood domain is the European Environment Agency: http://semantic.eea.eu-

ropa.eu/sparql,

The approach followed by the given examples facilitates the sharing of data and the generation of

knowledge based on the available information. The publication of data as Linked Open Data and the

implementation of SPARQL endpoints are therefore recommended.

Recommendations For New Or Updated Standards D50042 FIspace D500.4.2

Navigation menu

Versions of this User Manual:

Views

Navigation