Legacy standard
You are viewing a standard that has since been updated. View the current standard.
1 Introduction
This document defines and describes the architecture of the GS1 system of standards. The GS1 system is the collection of standards, guidelines, solutions, and services created by the GS1 community.
The primary audience for the GS1 System Architecture includes end users, solution providers, GS1 Member Organisations, and others engaged in the definition and implementation of the GS1 system.
This document has several aims:
■ To introduce each of the components that are part of the GS1 system and to show how they are related. It also shows the relation between GS1 standard components and standards published by other organisations such as ISO, UN/CEFACT or W3C.
■ To explain the underlying technical foundations that guide the design of individual standards and service components within the GS1 system.
■ To provide architectural guidance to end users and solution providers who want to use the GS1 system and to set expectations as to how these elements function.
Other resources provide the technical details required to implement the GS1 system. Specifically:
■ Individual data, software and hardware interfaces, as well as their use in open value network applications. These interfaces are defined by GS1 standards developed by the GS1 Community through the Global Standards Management Process (GSMP).
■ Hardware and software components that implement GS1 standards. Implementers are free to innovate in the design of components, so long as they implement the interface between components in accordance with GS1 standards.
■ GS1 Data Services that are operated and deployed by GS1 itself, by other organisations to which GS1 delegates responsibility or by third parties.
Many parts of the GS1 system are well-established and covered by GS1 standards. Other parts of the GS1 system are evolving to meet needs that are determined by industry-prioritised use cases. For those elements of the system that are evolving, architectural analysis may be underway within the GS1 Architecture Group for the purpose of ensuring that the GS1 system remains cohesive.
This document identifies which parts of the GS1 system are well-established architecturally and which parts are expected in the near future.
2 Overview of the GS1 System Architecture
2.1 The role of standards
2.2 Open value networks
2.3 GS1 standards: Identify, Capture, Share, Use
2.4 Digital value networks
The GS1 system is based on globally unique identification and digital information. GS1 standards have the following objectives:
■ To facilitate interoperability in open value networks
Parties exchanging information must have agreement on the structure, meaning and mechanism of data exchange. The GS1 system includes technical standards for identification, automatic identification and data capture (AIDC) (i.e., barcodes and RFID tags), master data standards (e.g. product catalogue), and information exchange standards (e.g. Electronic Data Interchange), visibility event data (e.g., EPCIS). They also include application standards that determine a normative use of technical standards for a specific business use case.
■ To foster the existence of a competitive marketplace for interoperable system components
GS1 standards define interfaces between system components that may be produced by different vendors or by different organisations’ in-house development teams. This enables choice and leads to economies of scale that reduces costs for end users.
■ To encourage innovation built upon a standards foundation.
GS1 standards define interfaces. Interface standards ensure interoperability between competing systems. By building value-added features or functions upon a standard foundation, implementers can have greater confidence in the eventual adoption of their products and systems and, therefore, increased confidence to invest in innovation.
A value network is a set of parties who are involved in business relationships with one another. In many cases, value networks are concerned with the trade of physical objects such as products, parts, raw materials or digital objects such as music downloads, video-on-demand, data services, and so on.
An open value network is one where the complete set of trading partners is not known in advance and changes over time and where, to a certain degree, trading partners are interchangeable. This has great significance for the architecture and design of information systems. Interfaces between different system components form the basis of interoperability. In a value network, the most important interfaces are those that exist between different organisations.
Figure 2‑1 Open value network
The open nature of value network interfaces manifests itself in two ways, as illustrated in Figure 2‑1.
Firstly, an interface may exist between two companies that do not have a direct business relationship. For example, a manufacturer may mark a product with machine-readable data in a barcode, the product may then be sold to retailers through distributors. In this case, the barcode can be read by all retailers who receive the product (because of the use of a common standard). In this example, the barcode is an interface between the manufacturer and the retailers (and increasingly with consumers via initiatives such as GS1 Digital Link), but the manufacturer’s only direct business relationship is with their distributors.
Secondly, a company may find over time that it needs to extend an existing interface to communicate data to new companies. For example, suppose that Companies A and B are in a trading relationship and utilise an electronic interface for exchanging purchase order and invoicing information. Companies C and D are in a similar relationship. Sometime later, Company A may find that it needs to trade with Company D, and likewise C may find that it needs to trade with B. The fact that all four companies already use common data interface standards enables Company A to use the identical interfaces and supporting information systems to trade with D as it does to trade with B, and likewise for C as it trades with B and D.
To ensure that standards are broadly adopted, interface definitions need to be negotiated and implemented outside the context of any trading relationship. Then, they need to be adhered to by all parties to ensure interoperability. For a standard to be adopted broadly, it must enable interoperability and be maximally applicable to a broad range of business contexts. These are precisely the foundation that underlie GS1 standards.
GS1 standards support the information needs of end users that interact with each other in value networks. The subjects of such information are the entities that are part of those business processes. Entities include things traded between companies, such as products, raw materials, packaging, and so on; equipment needed to carry out the business processes such as containers, transport, machinery; physical locations where business processes are carried out; legal entities such as companies; service relationships; business transactions and documents; and others.
Entities may exist in the physical world (such entities are generically called physical objects in this document) or may be digital or conceptual. Examples of physical objects include a consumer electronics product, a transport container, and a manufacturing site (location entity). Examples of digital objects include an electronic music download, an eBook, and an electronic coupon. Examples of conceptual entities include a trade item class, a product category and a legal entity.
GS1 standards may be divided into the following groups, according to their role in supporting information needs related to entities in value network business processes:
■ Identification Standards: These provide the means to Identify entities so that electronic information may be stored and/or communicated about them among end users. GS1 identification keys (simple or compound) may be used by an information system to refer unambiguously to an entity such as a trade item, logistics unit, asset, party, physical location, document or service relationship.
■ Capture Standards: These provide the means to automatically Capture identifiers and/or data that is carried directly on physical objects, bridging physical and digital worlds, the world of physical things and the world of electronic information. GS1 data capture standards currently include specifications for barcode and radio-frequency identification (RFID) data carriers. Capture standards also specify consistent interfaces to readers, printers, and other hardware and software components that read the content of data carriers and connect this data to relevant business applications. The industry term Automatic Identification and Data Capture (AIDC) is sometimes used to refer to the standards in this group, though in the GS1 System Architecture a clear distinction is maintained between identification and automatic identification and data capture (AIDC) because not all identification is automated and not all data capture is identification.
■ Share Standards: These standards provide the means to Share information, both between organisations and internally, providing the foundation for electronic business transactions, electronic visibility of the physical and digital world, and other applications. GS1 standards for information sharing include standards for master data, business transaction data, and visibility event data, as well as communication standards for sharing this data between applications and trading partners. Other information sharing standards include standards such as those that define the resolver infrastructure for GS1 Digital Link, which help to locate where relevant data resides across a network.
■ Use of Standards: GS1 Application Standards provide a normative selection of technology and data to meet business or regulatory requirements. These standards establish definitions, rules, and/or conformance specifications that shall be followed by all trading parties to establish a critical mass for implementation and the confidence of solution providers supporting that implementation. For example, industry chooses a technical standard methodology to assess barcode print quality, but they also establish a normative agreement for the minimum print quality grade needed for the business application. The minimum grade is established after considering what will permit efficient scanning, but also efficient printing. Industry then uses print quality conformance testing per the agreed methodology to establish if the industry “standard” has been met.
While GS1 standards may be used in any combination, the “Identify, Capture, Share” paradigm is pervasive in situations where GS1 standards apply, and most business application standards employ GS1 standards from all three groups. For example, consider the business processes that support the retail sale of consumer goods. GS1 standards are commonly used as follows:
■ Identify: Each class of trade item is assigned a Global Trade Item Number (GTIN) following GS1 identification standards. Because of this, any retailer/marketplace is assured of having a unique way to refer to a given trade item in its information systems, regardless of which trade items it chooses to carry. Each product brand owner need only assign a single identifier to its trade item for use globally.
■ Capture: Each trade item carries its GTIN directly on the product package using a barcode that complies with GS1 barcode standards, possibly also using a GS1-compliant RFID tag. Automated identification is used to retrieve information about the item scanned or read or record events as physical objects as they move through the value network, from shipping to receipt to point-of-sale.
■ Share: Brand owners may share product master data with retailers through GS1 master data standards. GS1 Electronic Data Interchange (EDI) standards may be used by the retailer to reorder products from the manufacturer when supplies run low. GS1 visibility event data standards may be used to provide detailed information about the movements of goods, such as what products entered and exited each store.
The relationship between GS1 standards for identification, capture, and share is depicted below.
Figure 2‑2 Identify, Capture, Share, and Use relationships
When discussing the Technical Standards, the key relationships between Identify, Capture, and Share layers are as follows:
■ Both capture and share standards make use of unique identifiers for entities. There is a dependency between the capture/share standards and the identification standards.
■ Where an entity exists in the physical world, AIDC data carriers are used to bridge the physical and digital worlds. In such situations, GS1 capture standards come into play, and sit between the identification standards and the sharing standards.
■ There are other situations in which identification is used directly by sharing standards without any AIDC data capture. For example, master data describing a trade item may be shared between trading partners without any physical product having been produced yet. There are also cases where the capture layer provides business data through an AIDC data carrier such as the weight of an item in a barcode at retail point-of-sale (POS).
Within each broad category of standards for identification, capture, and share, there are many individual standards that may be classified into subcategories. The following figure illustrates various GS1 system components and how they fit into this framework. They are discussed at greater length in the following sections.
Note: Figure 2‑3 is not exhaustive in its details. For example, the number of EDI message standards in GS1 would fill the Figure and the identification layer does not contain all examples for the use of GTIN, such as count of GTINs contained within a Logistic Unit, ITIP, GTIN with Third Party Serial Number. For a more comprehensive list of GS1 standards, visit https://www.gs1.org/standards/log
Figure 2‑3 Visual representation of the Identify, Capture and Share layers
The central idea of a digital value network is that all information exchange is carried out electronically, through network pathways that effectively parallel the physical path taken by goods. In a fully realised digital value network, physical objects carry only a globally unique GS1 identification key, and all other information is communicated digitally using the unique identifiers to link the information to the physical objects. Changes in information needs may be accommodated without the need to re-engineer the business processes for marking and scanning physical objects. The use of global standards facilitates the rapid integration of new partners into the overall open value network.
The digital value network is based on the following principles:
■ Globally unique identification: All objects of interest in the value network should be identified with a globally unique identifier at the lowest level.
■ Affixing as few data carriers as possible: If an object is physically handled, ideally only one AIDC data carrier should be affixed to carry the object’s unique identification.
■ Use master data to carry object attributes: All relevant descriptive attributes of an object should be carried in master data associated with the object’s unique identification and communicated between parties using synchronisation or other means.
■ Use common data definitions in business documents, internal and external: Business data exchanged between applications within a company and between companies should refer to objects using their unique identification. Descriptive information about those objects needed to process the data may then be obtained through master data.
This approach is directly supported by GS1 standards for Identification, Capture, and Sharing.
3 General considerations
3.1 Standards, guidelines, data services, solutions
3.2 GS1 System Architecture vs. End user system architecture
3.3 Scope of standards
3.4 Consistency across data standards – the Global Data Dictionary
There are four types of artefacts that make up the GS1 system:
■ GS1 standard: Document that provides normative specifications and rules agreed, per due process, by industry and GS1 Member Organisations to meet a business need of the GS1 community. A GS1 standard contains normative statements and are written in such a way that conformance to the normative statements is sufficient for a system component to achieve the interoperability or other goals for which the standard is designed.
■ GS1 guideline: Document that provides information considered useful in implementing one or more GS1 standards. A GS1 guideline never provides additional normative content beyond the standard(s) to which it refers. GS1 standards typically focus on “what” system component(s) is selected or must do, whereas GS1 guidelines may provide additional suggestions for “how” such a component may be implemented. GS1 guidelines may be general in nature or may be specific to a limited number of use cases or industries.
■ GS1 data service: GS1 standards-based applications offered to industry to address a specific business need. A GS1 data service may be static (e.g., the Global Product Classification browser, which offers a simplified way to navigate the GPC schema) or dynamic (e.g., GEPIR, which is a lookup service coordinated by GS1 GO that provides all end users with the ability to lookup licence information and data about GS1 identification keys).
■ GS1 solution: GS1 offering to industry that combines GS1 standards, services, guidelines, and/or other activities to address a specific business need. An example of a GS1 solution is GS1 traceability which includes standards, data services, training, certification, guidelines, etc.
GS1 standards may be further distinguished according to the type of normative content they contain, as follows:
■ Technical standards: A technical standard is one that defines a set of behaviours for a system component. Technical standards focus on “what” a system component must be or do to be in conformance with the standard. Technical standards may define standardised data models and/or standardised interfaces for the exchange of data. Technical standards are typically written to be as broadly applicable as possible across business sectors and geographic regions.
■ Application standards: An application standard is one that specifies a set of technical standards to which end user systems must conform to support a particular business process application. Application standards provide a convenient way for different end users to express their agreement to follow certain standards to achieve mutually agreed interoperability goals in a given application context.
The following diagram illustrates how systems deployed by end users make use of GS1 system artefacts.
Figure 3‑1 Use of GS1 standard components in End user systems
The GS1 system is a collection of interrelated standards, guidelines, services, and solutions. End users deploy systems that make use of elements of the GS1 system. Each end user will have a system architecture for their deployment that includes various hardware and software components. These components may use GS1 standards to communicate with each other and with external systems. They may also make use of GS1 data services to support certain tasks. An end user’s system architecture may also use alternative or additional standards, including data and interfaces beyond those defined by GS1.
The GS1 System Architecture is a conceptual model of the GS1 system. It does not define a system architecture that end users must implement, nor does it dictate hardware or software components an end user must deploy. GS1 standards only define data and interfaces that the end user’s components may implement. An end user system architecture may need to employ only a subset of the GS1 standards and GS1 data services. The mapping between hardware and software components depicted in this document and actual hardware or software components deployed by an end user may not necessarily be one-to-one. The roles depicted in this document may be carried out by end user system components that may have additional responsibilities outside the scope of the GS1 System Architecture.
To the greatest extent possible, the components of the GS1 system are designed to be broadly applicable across all industry sectors and geographical regions. However, there are often needs that exist only within a sector. A similar pattern sometimes arises among smaller groups of trading partners within an industry and even among the divisions of a single company.
This leads to a hierarchy of standards, illustrated below:
Figure 3‑2 Scope of standards
The hierarchy is as follows:
■ Global, cross-sector: At the core of any implementation are the components of the GS1 system that have broad applicability across industry sectors and geographical regions. Most of the GS1 technical standards fall into this foundational layer. Some GS1 Application Standards are global and cross-sector.
■ Sector / Regional: An industry sector may develop GS1 Application Standards for use within that industry and/or region. There are also certain GS1 data standards that are sector specific. Sector-specific standards apply to all geographical regions and are developed globally via GSMP.
Regional requirements may be addressed via GS1 Application Standards or by other normative documents created by GS1 Member Organisations to serve their respective geographical regions. Such documents may also be sector-specific, or they may be cross-sector.
Both sector and regional standards should always be designed to be used seamlessly with the global standards. It is essential that users who do not use sector or regional standards are not disrupted by others’ use of them.
■ Trading group: A trading group within an industry sector or region may establish specific rules for use among themselves, building upon the GS1 system. Such rules may be developed outside of GS1, but can reference GS1 standards, guidelines and/or services.
■ Company: Individual companies are encouraged to develop their own internal architectural standards to drive the consistent use of GS1 standards across the enterprise.
Great care must be taken so that sector, regional, trading group, or company standards do not inadvertently create problems. A sector, regional, or trading group standard can create problems if some companies find themselves having to operate within two or more such sectors, regions, or trading groups that have mutually incompatible requirements. Ideally, requirements are pushed to the global level (and into global standards) whenever possible.
Many GS1 standards include normative definitions of data. These include definitions of individual data elements, definitions of “documents” comprised of many individual data elements, and definitions of messages that are exchanged between system components.
Each GS1 standard that defines data is designed to be self-contained and so includes a normative definition of each data element; however, many data elements recur across different GS1 standards and so some means of achieving consistency is required. The GS1 Global Data Dictionary (GDD) is intended to serve this purpose.
The GDD is a compendium of the data elements defined across all GS1 standards. The GDD is not itself a GS1 standard, but rather is a tool that helps to ensure consistency across all GS1 standards. It provides definitions for each distinct data element that may occur across several standards.
The current state of the GDD is not comprehensive nor fully up to date. GS1 is working on a plan to provide a Web GDD with the goal to arrive at a true “Single Semantic Model”. This approach will ensure full interoperability between implementations of different standards because they will all be based on the same definitions and process models.
4 Identify – GS1 identification keys
4.1 Data modelling terms
4.2 GS1 identification keys (simple or compound) and AIDC data
4.3 Classes of GS1 identification keys
4.4 Identifier Syntax: Plain, GS1 element string, EPC URI, GS1 Digital Link URI
This section defines common data modelling terms that apply to GS1 standards for identification.
4.1.1 Entities
An entity is something that is the subject of information in an information system. An entity may be:
■ Physical: A physical object to which a data carrier (barcode or RFID tag) may be physically affixed.
■ Digital: An artefact that exists in information systems and which has a recognisable lifecycle. Examples include a music download, an eBook and a digital coupon.
■ Abstract: A virtual object or process, including legal abstractions (e.g., a party), business abstractions (e.g., a class of trade item), intangible items which forms part of a trading relationship (e.g., repair of an item or a haircut).
4.1.2 Attributes
Information systems are concerned with associating information with entities. The items of associated information are called attributes.
■ Attribute: A piece of information associated with an entity. Something can be recognised as an attribute if one can construct a sentence of the following form: “The [attribute name] of [entity] is [attribute value].”
Attributes can be classified based on how frequently they change.
■ Static attribute: An attribute whose value does not change over the life of the entity. E.g., the load capacity of a specific forklift.
■ Dynamic attribute: An attribute whose value changes frequently over the life of the entity. E.g., the price of a product.
4.1.3 Keys
Information systems refer to an entity by means of a key.
■ Key: An attribute or group of attributes of an entity that serves to uniquely identify that entity. An information system uses a key as a proxy for the entity itself.
Often a single attribute is usable as a key, but sometimes a group of attributes is required. In data modelling terminology, these are called simple keys and compound keys, respectively.
■ Simple GS1 identification key: A single attribute that serves as a key. (E.g., a Global Service Relation Number assigned by a hospital to a patient).
■ Compound GS1 identification key: Two or more attributes that together serve as a key. (E.g., the combination of a GTIN and serial number identifies an individual instance of a trade item).
To be usable as a key, an attribute or set of attributes must have certain properties:
■ Uniqueness: A given key value corresponds to one and only one entity within the specified domain; two different entities within the specified domain must have different values of their keys.
■ Completeness: There exists a key value for every entity within the specified domain.
■ Persistence: The same key value denotes a given entity throughout the entity's life, including its representation in digital form.
4.1.4 Terms relating to construction of GS1 identification keys
In many applications, and in the case of GS1 identification, keys are designed specifically for the purpose of being a key. When developing GS1 identification keys, some design considerations apply:
■ Syntax: Common syntax rules include a choice of character set, limits on length, specifying fixed or variable length, having a grammar that supports a hierarchical structure.
■ Capacity: The uniqueness and completeness requirements for being a key are affected by the capacity that is implied by the syntax rules.
■ Assignment methodology: Keys can be assigned centrally from one single coordinating body or in a distributed manner. When intended to be assigned in a distributed manner, a hierarchical structure is often used, where some portion of the key is assigned by a central party and the assignment of the remainder is delegated to other parties, who may in turn delegate a portion of their portion, etc. This is the way GS1 has organised the assignment of GS1 identification keys, in a three-level hierarchy: GS1 Global Office, GS1 Member Organisation, GS1 licensee.
■ Resolution: The ability to locate data related to a specific value of a key, or at least to determine an entry point to locate such data.
■ Non-significance: A key is non-significant to the extent that it does not embed business information about the entity it identifies; such information is instead associated with the key.
The goal of GS1 data standards can be understood as defining standardised attributes for entities, including standardised attributes that may be used as keys to refer to specific entities.
■ GS1 identification key (simple or compound): The term “GS1 identification key” refers to those identifiers which are simple GS1 identification keys (GTIN, SSCC, etc.), and the term “key qualifier” refers to additional attributes that are designated for use as part of a compound key (e.g., GTIN + serial number is a compound GS1 identification key, with the serial number being a key qualifier for the GTIN).
■ AIDC data: Attributes of entities defined by GS1 standards, other than GS1 identification keys, which are capable of being directly affixed to an entity using a AIDC data carrier, e.g. best before date. While these are architecturally part of the Share layer, the Capture layer defines the syntax for including them in AIDC data carriers.
■ Other business data: Any data element that is not an GS1 identification key (simple or compound), e.g. product description. These are part of the Share layer of the GS1 System Architecture.
GS1 identification keys (simple or compound) and AIDC data are themselves identified using GS1 Application Identifiers (AIs). An AI is a short string (2, 3, or 4 characters) that identifies the data element, its brevity is particularly suited to identifying data elements when encoded into GS1 AIDC data carriers.
The following table summarises the GS1 identification keys in relation to the definitions in section 4.1.3. The column with the most relevant GS1 identification key (simple or compound) in the table below indicates which GS1 identification key may serve as a “key” (in the data modelling sense) for the entity listed in the first column.
Table 4‑1 Entities identified by GS1 identification keys (simple or compound)
The GS1 identification keys are the foundation of the GS1 system. However, some GS1 standards make provision for the use of other systems of identification for which some organisation other than GS1 is the issuing authority. For this reason, a classification of GS1 identification keys, drawn from a GS1 perspective, clarifies the relationship between a GS1 identification key and the rest of the GS1 system.
The following classification of GS1 identification keys is used:
■ Class 1: Keys administered by GS1 and fully under its control.
■ Class 2: Keys whose framework is controlled by GS1 and for which a portion of the identification capacity is allocated to an identification scheme administered by an external agency.
■ Class 3: Keys fully administered and controlled outside GS1, but which are supported in some parts of the GS1 system.
■ Other keys: Keys that are entirely outside the GS1 system, i.e. all identifiers that meet the technical definition of “key” but are not in the first three classes.
This classification is described in more detail below.
4.3.1 Class 1 GS1 identification keys
A class 1 GS1 identification key has its structure, allocation, and lifecycle rules defined by GS1. A GS1 Prefix is a unique string of two or more digits:
■ Issued by GS1 Global Office and allocated to GS1 Member Organisations to issue GS1 Company Prefixes or individual GS1 keys.
■ Allocated by GS1 Global Office for specific purposes (e.g., internal numbering, restricted circulation numbering).
■ A GS1 Company Prefix is a unique string of four to twelve digits issued by a GS1 Member Organisation and used to issue GS1 identification keys.
Class 1 keys always incorporate a GS1 Prefix and a GS1 Company Prefix or one-off GS1 Key licensed by a GS1 Member Organisation (MO) or by the GS1 Global Office to a user company. In some cases, class 1 keys are licensed one by one by MOs to themselves then associated to user companies. They are subject to allocation rules defined in GS1 standards, and their association with attributes is governed by validation rules also defined in GS1 standards.
Class 1 keys include GTIN, SSCC, GLN, GRAI, GIAI, GSRN, GDTI, GSIN, GINC, GCN, CPID and GMN.
4.3.2 Class 2 GS1 Identification keys
A class 2 GS1 identification key starts with either a GS1 Prefix or a GS1 Company Prefix, incorporates a key administered by an external organisation, and includes a check digit if required by its corresponding class 1 key format. Class 2 keys are unique with respect to class 1 keys of the same type. Their allocation and lifecycle rules, however, are defined by an organisation external to GS1. The degree to which these rules are compatible with those of the corresponding class 1 keys is specific to each class 2 key.
Examples of class 2 keys include:
■ The International Standard Serial Number (ISSN) used with GS1 Prefix 977 to form a key compatible with GTIN-13.
■ The International Standard Book Number (ISBN) is issued using GS1 Prefixes 978 and 979 to form a key compatible with GTIN-13.
□ A subset of ISBNs starting with 9790 are reserved for the International Standard Music Number (ISMN).
■ GS1 Prefix 34 is used with Club Inter Pharmaceutique (CIP) codes for pharmaceuticals in France to accommodate national numbers inside the GTIN number range.
■ The Produce Electronic Identification Board uses the GS1 Company Prefix 033383 issued by GS1 US combined with a commodity code issued by the Produce Manufacturers Association to create “PEIB UPCs” inside the GTIN number range.
The arrangements leading to the existence of class 2 keys are exceptional and subject to accreditation agreements between GS1 GO or MO and the third party. A GS1 Policy on the Licensing of GS1 Identification Keys by Third Parties governs the establishment of such arrangements.
4.3.3 Class 3 GS1 identification keys
A class 3 GS1 identification key has its structure and its rules for use defined, administered, and managed by an organisation external to GS1. This organisation enters into an agreement with GS1 that enables its keys to be used in selected GS1 standards, for example, within an EPC header.
It is intended that class 3 keys are used in selected GS1 standards without disrupting users of class 1 and class 2 keys, but:
■ GS1 gives no assurance that class 3 keys will be recognised by users of class 1 and class 2 keys
■ GS1 has no expectation that systems relying upon class 3 keys should recognise keys from class 1 or class 2
■ GS1 has no expectation that systems relying upon one type of class 3 key should recognise other types of class 3 keys.
Companies can take advantage of GS1 technology, network, and communications standards for class 1, 2, and 3 keys, but should not expect full interoperability between keys in classes 1 and 2 and keys in class 3.
Keys in class 3 at the present time are:
■ The Auto-ID Center General Identifier (GID)
■ Keys compliant with US Department of Defence (USDoD) and Airline Transport Association (ATA) standards that are based on the Commercial and Government Entity (CAGE) and Department of Defense Activity Address Code (DoDAAC) identification standards.
■ Bureau International des Containers (BIC) codes
■ International Maritime Organization Vessel Number (IMO)
These keys are supported in the GS1 EPC Tag Data Standard and, consequently, have EPC URIs that can be used in EPCIS.
4.3.4 Other keys
Other keys are administered and managed externally to GS1 and are not accommodated by any GS1 standard as a key (primary identifier). Examples include:
■ Data Universal Numbering System (DUNS);
■ Vehicle identification number (VIN);
4.3.5 Summary
The following table summarises the key classification discussed above.
Table 4‑2 Classes of GS1 Identification keys characteristics
When a GS1 identification key or other identifier is used in an information system, it is necessarily represented using a specific syntax. The syntax that is used may depend on the medium in which the identifier exists; for example, an XML message is text-oriented, while the memory of an RFID tag is binary-oriented.
GS1 standards provide four different syntaxes for identifiers that support progressively broader application contexts:
■ Plain (physical, digital): This syntax is just the GS1 identification key with no additional characters or syntactic features. For example, a Global Location Number (GLN) is represented as a 13-character string, each character being a digit. The plain syntax is usable in a context where only a single type of GS1 identification key is expected. Examples of such single-key contexts include: a barcode symbology that is defined to only hold one type of GS1 identification key (e.g., ITF-14 which can only hold a GTIN), a column in a database table that is intended to hold only a single GS1 identification key.
■ GS1 element string (physical): This syntax consists of a short (2-4 character) “application identifier” that indicates what GS1 identification key (simple or compound) or AIDC data follows, followed by the key or data value itself. This allows one type of GS1 identification key or AIDC data to be distinguished. Related to the GS1 element string is the “concatenated element string”, in which two or more AI-value pairs are concatenated into a single string (with delimiters, if needed). This provides a syntax for compound keys such as GTIN + serial number or keys and AIDC data such as GTIN + weight + expiry date.
■ Electronic Product Code (EPC) URI (physical, digital): This syntax is a Uniform Resource Identifier (URI), specifically a Uniform Resource Name (URN) beginning with urn:epc:id:… and the remainder having a syntax defined by the GS1 EPC Tag Data Standard. This provides a syntax for any GS1 identification key that identifies a specific physical or digital object, including some class 3 keys as defined in section 4.3.3. Objects that are not identified at the instance-level are either expressed as an EPC Class URI (urn:epc:class:...) or an EPC Pattern URI (urn:epc:idpat:...).
■ GS1 Digital Link URI (physical, digital): The GS1 Digital Link URI provides a syntax for expressing GS1 identification keys (simple or compound) AIDC data in a format that can be used on the Web in an intuitive manner (via a straightforward Web request) to enable direct access to relevant information and services about products, assets, locations, etc. While any given GS1 identification key may be represented in more than one of the above four syntaxes, its meaning is always the same regardless of syntax. The following table illustrates a GS1 Global Returnable Asset Identifier (GRAI) in each of the four syntaxes:
Table 4‑3 Example of GS1 identification key representation in identifier syntaxes
5 Capture – Automatic Identification & Data Capture (AIDC)
The “Capture” standards in the GS1 system are standards for automatically identifying a physical entity or for capturing other data that is associated with a physical entity. At the ISO/IEC SC31 JTC1 level, this area of technology standards is called Automatic Identification and Data Capture (AIDC). An AIDC data carrier is a representation of data in a format that is designed to be machine-readable. Data carriers range in capability, from the simplest barcodes whose only function is to deliver a GS1 identification key when read, to complex 2D symbols capable of holding multiple data elements with error correction, to the most sophisticated RFID tags which are themselves small computing devices. Interaction with RFID tags may include more than only “data capture,” though the term “capturing” is still used for the process of encoding and/or decoding data into/from AIDC data carriers. The processes involved in putting data into AIDC data carriers, including printing of barcodes and programming of RFID tags, are also included under the label of “data capture.”
This section outlines the general foundations of GS1 AIDC standards.
5.1 Automatic Identification & Data Capture (AIDC) architecture
5.2 Automatic Identification and Data Capture Workflow
5.3 AIDC data carrier independence of data
5.4 Types of data carriers
The purpose of AIDC data carriers in the GS1 system is to provide a reliable way to automatically capture a GS1 identification key to link to the data held on computer systems as part of a workflow. In addition to the GS1 identification key, AIDC data (e.g., expiration date, weight, sensory data) may also be a part of the workflow. In a GS1 compliant application of AIDC data carriers, a GS1 identification key must always be present.
Within a given data capture workflow, there may be many individual interactions with AIDC data carriers. A data capture workflow may also involve interaction with humans, sensor devices, as well as with “back end” information systems such as an Enterprise Resource Planning (ERP) or Warehouse Management System (WMS). All these processes/systems combine to create the AIDC workflow, and this workflow gives meaning to the act of capturing the identifier or data from the AIDC data carrier.
For example, at a point-of-sale (POS) terminal, the business context is usually such that scanning a barcode containing a GTIN means that one instance of a product whose class is identified by the GTIN has just been purchased by the customer engaged in the checkout process. However, at the returns desk, scanning the same barcode may instead mean that the product is being returned rather than purchased. In each case, the business context gives meaning to each barcode scan.
Figure 5‑1 shows the elements of a typical AIDC application architecture. The exact architecture for any given AIDC application will vary from case to case. For example, not all AIDC applications use both barcodes and RFID. Figure 5‑1 shows commonly occurring relationships between components and how GS1 standard interfaces fit in from scan/read to application use.
Figure 5‑1 Overview of the elements of a typical AIDC application architecture
GS1 automatic identification and data capture (AIDC) applications originates when a device (e.g., scanner, RFID reader) determines that an AIDC data carrier is carrying GS1 identifiers or AIDC data. This workflow occurs between the scan or read of the AIDC data carrier and the use of the scan/read of the GS1 identification key or AIDC by the application.
Section 5.2.1 describes functions that are common (independent of carrier type) within the AIDC workflow (e.g., parsing, validation, augmentation, translation, processing, buffering).
Sections 5.2.2 through 5.2.5 describe workflow functions which are specific to a particular AIDC data carrier technology, data carrier technology use of different syntax, or for sensor devices.
■ Section 5.2.2, GS1 Barcodes with GS1 Element String syntax
■ Section 5.2.3, 2D symbol with GS1 Digital Link URI syntax
■ Section 5.2.4, EPC RFID
■ Section 5.2.5, Sensor systems (e.g., monitor temperature exposure)
Each of these four sections describe the infrastructure or interfaces required, the method of determining that the data carried is encoded according to GS1 standards and provides common application examples.
5.2.1 Generic AIDC Workflow Functions
There are several functions which are utilised independently of the data carrier type. How, when, or even if they occur depend on the application requirement and the data carrier supporting the application. These functions include, but are not limited to, the items described below.
1. Decoder: A barcode or RFID reader consists of a scanner, a decoder (either built-in or external), and a connection method to an application. A barcode or RFID reader generally captures and decodes the barcode into numbers, letters and/or character symbols, the data must be processed by a software application to make sense of the data
2. Parse: In an AIDC data carrier we would parse the data by analysing the data string and applying the GS1 syntax rules (Plain, Element String, GS1 Digital Link URI or EPC binary). As an example, the data string parsing result could be the list of application identifiers with their values ((01)-GTIN, (10)-Lot/Batch, (17)-expiry date, (21)-serial number…).
i. Data string transmitted by the scanner: ]d201095011014200693922995<GS>320200010017210615422123<GS>2112345678
ii. 2D symbol with parsed element string data
3. Validate: Is the content and data structure correctly formed based on the syntax rules. If the AIDC data carrier and the data encoded is using the correct GS1 syntax and the AIDC application meets the appropriate GS1 standards, then it is considered valid.
4. Verification: Does the AIDC data carrier conform to encode/decode algorithms and meet quality standards. For example, in a barcode symbol, the bars, modules and symbols must be correctly formed and meet standards for size, contrast, decodability, defects and other verification parameters.
5. Augment: Data and data carriers can be augmented in two ways in AIDC applications, one: the data may be augmented with business context data; and two: the data carrier may be augmented to improve decodability through error correction methods such as the Reed-Solomon algorithm.
6. Translate: Similar to translating words from one language to another, in AIDC the conversion is from the encoded GS1 syntax data to what the application needs, this could happen in the scanning or reading device (e.g., Point of Sale scanner, RFID reader, mobile devices app), in the application software.
7. Process: Is the defined steps from encoding an AIDC data carrier to use of the encoded GS1 identification key or AIDC data by an application to achieve the desired business or consumer outcome.
8. Buffer: Is a mechanism to temporarily store data while it is being moved from one place to another.
5.2.2 GS1 Barcode-Specific Workflow
GS1 barcodes infrastructure includes:
1. Barcode design software provides for all AIDC data carriers approved for use within a GS1 Application Standard. This software encodes a data string and renders a barcode image with a special start pattern to designate GS1 defined encoding and decoding that conforms to GS1 General Specifications definitions, specifications, and rules. The software may output directly to a printing system or to a file used in the production of packaging artwork.
2. Printing of barcodes may be digital or analogue. Digital printing is characterised by a print mechanism creating the barcode image on demand (e.g., thermal transfer, ink jet, laser printing devices). Analogue printing is characterised by printing a fixed barcode image onto a medium like paper or plastic using a printing press (e.g., flexographic, offset, screen printing processes).
3. Print quality verification takes place at some point after the barcode image is rendered. This may occur inline during the printing process or on a random sample basis. The devices used in this process support the methodology to measure print quality and the ability to report whether the minimum print quality needed for each application is specified in the GS1 General Specifications has been met. Conformance Test Cards are also available to ensure proper calibration of verification systems.
4. Scanning systems can determine whether the barcode carries GS1 identifiers or something else. If GS1, then the scanner system can decode the barcode according to GS1 General Specifications definitions and rules. The system includes software that supports the generic workflow functions described above. There are many types of scanners, but in broad terms, laser scanners support 1D barcodes and imaging scanners support 1D and 2D symbols.
Decoding process for a GS1 barcode
1. Determine symbology via symbology identifier standard or proprietary means. If EAN/UPC, process per GS1 definitions for its use. If ITF-14 (Interleaved Two of Five with a 14-digit numeric string) matches a GTIN look-up and validates on check digit, infer a GTIN is encoded.
2. For all other GS1 barcodes, utilise the symbology specifications for start character patterns to determine if the barcode is a GS1 barcode (encoded per GS1 definitions and rules as GS1 conforms to ISO/IEC 15459 as an Issuing Agency).
3. For GS1 barcodes, parse per GS1 element string definitions (Application Identifier and AI data field) and rules (e.g., sequence, concatenation) to yield an identifier to link to stored information or populate an event or yield business data for use or storage by the application (e.g., expiration date prevents the sale of an expired product).
1. General retail point-of-sale (POS) uses GS1 barcodes to identify a product and to retrieve product description and price information which are used to make check-outs faster and more accurate. GS1 DataBar can also be used at POS to provide business information beyond the GTIN like the weight of a variable measure product or an expiration date for a perishable product.
2. Transport and logistics operators use GS1 barcodes to automate receipt, storage, and movement of products and logistics units.
5.2.3 2D Symbol (GS1 Digital Link URI) Specific Workflow
2D Symbol (GS1 Digital Link URI) infrastructure
2D Symbol (GS1 Digital Link URI) shares much of the infrastructure described in GS1 Barcodes section, although the focus is on the use of 2D symbols with GS1 Digital Link URIs by consumers using apps on smartphones and other mobile devices, as well as B2B uses (e.g., GS1 Scan4Transport). Such apps need to retrieve information and interact with services on the Web over HTTP / HTTPS. For syntaxes other than GS1 Digital Link URI, the GS1 identification keys (simple or compound) and AIDC data will need to be converted into the standardised Web URI format.
Decoding process for a 2D Symbol (GS1 Digital Link URI):
The GS1 Digital Link standard defines a Web-friendly URI syntax for GS1 identifiers, including the ability to support any GS1 identifier at any level of granularity (e.g. GTIN, GTIN+Lot/Batch, GTIN+Serial) and to link or automatically redirect to multiple kinds of information and services on the Web, through the use of dedicated link types and a simple Web request for the GS1 Digital Link URI.
When a GS1 Digital Link URI is encoded within a QR code or Data Matrix symbol, there is no FNC1 or dedicated symbology identifier that indicates that the data content is defined by GS1 standards as discussed in Section 5.2.2 . Instead, it is necessary to check that the extracted Web URI conforms to the URI Syntax defined for GS1 Digital Link (see https://www.gs1.org/standards/gs1-digital-link and the URI Syntax chapter in particular). The GS1 Digital Link URI Syntax standard defines a formal grammar for constructing GS1 Digital Link URIs and also provides regular expression patterns that can be used for checking whether any Web URI is plausibly a GS1 Digital Link URI. One way to test whether a Web URI does or does not point to a GS1 conformant resolver for GS1 Digital Link is to check for the presence of a Resolver Description File in the relevant Well-Known location /.well-known/gs1resolver [RFC 8615]. Details of the Resolver Description File are defined in GS1 Digital Link Standard in the Resolution chapter.
1. Application Examples: For extended packaging applications, the GS1 General Specifications now permit the encoding of a GS1 Digital Link URI within a regular ISO/IEC 18004 QR Code symbol or regular ISO/IEC 16022 Data Matrix symbol. Such a 2D symbol can be scanned by a consumer smartphone, either using the native camera or Web browser applications, generic scanning apps or by dedicated apps for specific purposes. Dedicated apps might warn a consumer about allergens in a product or provide a consumer with advice about which product to choose, taking into account their dietary or ethical / sustainability preferences. Other convenient uses of GS1 Digital Link could be to scan a 2D symbol to download the instruction manual or recycling information or a patient safety leaflet for pharmaceutical products etc. Depending on the granularity of identification, QR Code and Data Matrix symbols can be printed dynamically (if the GS1 Digital Link URI is specific to a particular serial number or batch/lot) or can be generated with the general product packaging artwork if it only identifies a product by its GTIN. Additional data such as expiration date, weight can be expressed within the URI query string of a GS1 Digital Link URI.
2. Link Types are not typically included in the URI at the time of printing the QR Code or Data Matrix symbol. Instead, a mobile app or other software may specify a value for link type within the URI query string at the time of making a Web request for the GS1 Digital Link URI. This provides flexibility so that a single 2D symbol can link to multiple kinds of information and services on the Web. A full list of current defined link types can be found in the GS1 Web vocabulary at https://www.gs1.org/voc/?show=linktypes. A brand owner or other licensee / issuer of a GS1 identification key can specify multiple referral records per GS1 Digital Link URI, each link type indicating a specific kind of service. For example, gs1:pip = https://gs1.org/voc/pip points to a product information page, whereas gs1:instructions = https://www.gs1.org/voc/instructions points to an instruction manual. The brand owner or licensee/issuer of the GS1 identification key can also specify a default link, to select which link should be used if the client (e.g. smartphone app) does not express a preference. Often, this might be the link to the product information page, although there are product categories such as pharmaceuticals, where regulations may require this to point only to a factual patient safety information leaflet, whose structure and content is specified by legislation.
3. GS1 Digital Link URIs can be translated to element strings and element strings can also be translated to GS1 Digital Link URIs, provided that they include at least one primary GS1 identification key. GS1 provides open source toolkits to support this via its GS1 GitHub site at https://github.com/gs1 . This translation capability enables a single barcode (based on GS1 Digital Link URI within a QR Code) to serve supply chain and retail POS use, as well as consumer-facing extended packaging use through mobile apps on consumer smartphones and devices.
4. Even before migration to a single barcode is achieved, translation to the GS1 Digital Link URI format enables existing GS1 barcodes to make use of the resolver infrastructure for GS1 Digital Link to redirect to various kinds of information and services on the Web, both for consumer-facing / B2C use and even for B2B use. There can be multiple resolvers for GS1 Digital Link but the GS1 global root resolver at id.gs1.org serves as a ‘resolver of last resort’ so that even if an existing GS1 barcode does not indicate any Internet domain name or hostname to use within the GS1 Digital Link URI syntax, id.gs1.org can be used to construct a canonical GS1 Digital Link URI and the GS1-operated global root resolver will redirect to any information and services specified by the respective licensee of the GS1 identification key. In some cases, this may be via national resolvers operated by individual GS1 Member Organisations on behalf of their members.
5. EPCIS v2.0 will support a constrained subset of GS1 Digital Link URIs as an alternative to the EPC URN syntax. The constrained subset corresponds 1:1 with the existing EPC schemes based on GS1 identifiers but in GS1 Digital Link URIs, the length of the GS1 Company Prefix has no significance. This will make it easier to capture EPCIS event data from GS1 barcodes even in situations where the party scanning the barcode does not know (or cannot easily determine) the correct length of the GS1 Company Prefix component; instead they will simply be able to use the GS1 Digital Link URI format instead of the EPC URN syntax. The result is that traceability event data finally becomes easier to capture consistently and correctly, independent of the type of data carrier technology encountered.
6. GS1 Scan4Transport makes use of 2D data carriers in the logistics / postal / parcel delivery sectors. Although some implementations may encode significant address, routing and delivery information within the data carrier, particularly to ensure data availability in areas of low Internet connectivity, user companies are also exploring the use of GS1 Digital Link URIs within QR Codes to support direct Web access to the most up-to-date information, which can support in-flight changes to destination address, service priority etc., which may supersede such details printed on the package or encoded within the 2D data carrier.
5.2.4 GS1 EPC/RFID-Specific Workflow
GS1 EPC/RFID infrastructure
An RFID infrastructure consists of one or more RFID readers and one or more RFID tags.
Readers transmit standardised commands (in order to read from and write) to tags by modulating a radio signal. Readers also provide operating energy to tags by transmitting a continuous-wave (CW) signal. Tags are passive, meaning that they receive all of their operating energy via this signal, without needing to rely on a battery. To respond to a reader's commands (i.e., to provide an EPC or confirm execution of an operation), a tag modulates the reflection coefficient of its antenna, returning ('backscattering') information in a binary signal to the reader.
GS1's EPC UHF "Gen2" Air Interface standard specifies physical (i.e., signalling, modulation and other radio parameters) and logical (i.e., tag memory, selection, inventory and access) interfaces. This standard is a close subset of ISO/IEC 18000-63, and serves as the backbone for almost all passive UHF deployments of the past 15 years.
Some deployments also make use of GS1's Low Level Reader Protocol (LLRP), which specifies an interface between RFID readers and clients for full control of air interface protocol operations and commands.
Process for decoding a GS1 EPC/RFID tag
RFID tags encoded with Electronic Product Codes (EPCs) per GS1's EPC Tag Data Standard (TDS) are referred to as EPC/RFID tags. TDS defines EPC encoding schemes (in binary and URI form) that correspond to serialised GS1 identification keys, as well as detailed encoding/decoding* algorithms to convert EPCs to GS1 element strings (and vice-versa, provided that GS1 Company Prefix (GCP) length is known). TDS also specifies the memory layout of EPC/RFID tags and the procedures for encoding supplemental AIs (such as Lot/Batch and Expiry) into a tag's "User" memory.
Tags in the so-called 'interrogation zone' are captured by a reader in the context of air interface inventory operations. Read range is typically up to 10 metres from the reader, but this distance can be substantially reduced or extended depending on the amount of absorbing or shielding material present, intentionally or otherwise.
The air interface select operation allows for pre-filtering of desired sub-populations of tags, which can enable an application to focus on tagged objects whose EPCs are part of certain class (e.g., by item reference within a GTIN plus serial number) or from a certain brand owner (i.e., by specific GCP).
Readers will often provide the hexadecimal EPC encoding of captured tags as input to application-level software which might be used to perform additional filtering and, in turn, further decode into EPC Tag URI, EPC Pure Identity URI (e.g., for inclusion in EPCIS event data), GS1 element string or GS1 Digital Link URI format(s), as required by the business process application consuming this data.
TDS is complemented by GS1's EPC Tag Data Translation (TDT) standard, which includes machine-readable versions of TDS encoding/decoding rules to support automated translation between these formats.
Application Example
EPC/RFID-based electronic article surveillance (EAS) in a retail store environment (as described in GS1's RFID-based Electronic Article Surveillance guideline): Item-level EPC/RFID tags are captured at a retail outlet's goods receiving. The reader provides EPC captured data to application-level software, which performs TDT-based translation into EPC Pure Identity URIs. These EPC URIs are captured in EPCIS event data to provide inventory visibility, documenting the items' arrival/availability at this location, followed by their subsequent sale at some point in the future. EPC/RFID tags captured by electronic article surveillance (EAS) readers at the store's exit are checked against the list of inventory that has not yet been marked as sold, to determine whether to sound an alarm or other internal notification.
Figure 5‑2 EPC/RFID-based EAS in a retail store environment
5.2.5 Sensor Device-Specific Workflow
Sensor device infrastructure
In terms of the required infrastructure, there is a huge variety in the market of how sensor systems are designed.
First, a sensor device does not just comprise one, but typically several sensors measuring physical properties such as temperature, luminosity, movement, humidity, to mention only a few. Apart from basic devices that simply capture and provide observed physical properties as is, there are also smart sensor devices equipped with a local processing unit which, based on some local software logic, already abstracts, filters and aggregates raw sensor data.
Second, some sensor devices come with a logger feature which has the capability to locally store/cache a certain amount of data before it is transmitted or read out. In this context, there are both active and passive sensor devices, i.e. with or without an own power source enabling data transmission.
Third, there are several technologies to convey data from a sensor device to a base station: there are systems which make use of sensor gateways through leveraging e.g. Bluetooth Low Energy (BLE), RFID or Wi-Fi, whereas others transmit data directly e.g. via cellular or low power wide area networks (LPWAN).
Processing sensor data
Therefore, there is no one-size-fits-all workflow describing how sensor data is processed. Notwithstanding, the following bullet points try to characterise a typical workflow in a generic manner (note that devices outputting signals in a non-electronic manner, e.g. consumer-facing colour-changing labels, are out of scope):
■ Raw sensor data is recorded in binary (usually timestamped) datasets according to a vendor-defined protocol.
■ Based on a set of business rules, a local or central capturing application parses, validates and translates these datasets into a higher-level data format which can be better processed by business applications. Thereby, the data may be augmented with business context data.
Note: An appropriate output data format after this step is an EPCIS event providing the What, When, Where, Why and How of a given sensor-based observation. EPCIS and CBV v2.0 specify a flexible framework to accommodate all kinds of sensor data.
■ The datasets are then made accessible to either internal or external business applications, where they may trigger business processes to properly react to the events detected by the initial sensor reading.
Application example
Cold chain compliance comprises controlling the temperature range product need to be in as well as ensuring that a defined threshold is not exceeded. Organisations, as part of supply networks in which cold chains must not be interrupted, have different choices on how to set up an appropriate infrastructure. For instance, logistics units loaded in a truck can be tagged with sensor devices that continuously transmit sensor readings to a fixed gateway which in turn (typically after some local filtering/aggregation) sends the corresponding datasets to a central capture application.
As shown in the Figure 5‑3, the latter consumes the datasets and translates them into EPCIS events. This could be for documentation purposes (as shown on the left simplified example) or to trigger alerts for the respective process owners in case a temperature threshold was exceeded (right simplified example). In addition, there are many further business applications (e.g., quality assurance, business intelligence, tracking & tracing) for which sensor-enhanced visibility event data are relevant.
Figure 5‑3 Cold chain compliance application example
GS1 defines GS1 identification keys and AIDC data in a data carrier-neutral way so that their semantics are the same regardless of which data carrier, or electronic messaging, is used.
Figure 5‑4 Four AIDC data carriers encoding the same GTIN value 9506000134352
From a GS1 perspective, we can distinguish three types of data carriers, (see Table 5‑1). According to the categorisation below, only data carriers belonging to ‘Type A’ are considered global AIDC data carrier standards, (e.g., EAN/UPC, GS1 DataBar, GS1 2D, 2D (GS1 Digital Link URI), or UHF EPC/RFID).
Many data carrier technologies possess the capability to encode GS1 data structures, too. However, GS1 community members either did not see a (business- or technical-driven) reason to justify their introduction into the GS1 system or the technology did not meet GS1’s data carrier adoption policy as defined in Policy B-11 (available on https://www.gs1.org/standards/development/how-we-develop-standards). All technologies that fall into this category are termed ‘Type B Data Carriers’.
In addition, there are also carrier technologies (‘Type C’) that cannot encode GS1 data structures. Two examples for this category are the Deutsche Post Identcode and the Channel Code whose specifications, for instance, prohibit the encoding of any GS1 identification key apart from theoretical edge cases. Table 5‑1 provides a definition for each of the three data carrier types.
Table 5‑1 Data carrier types
Figure 5‑5 comprises an overview of all Type A data carriers in the GS1 system of standards (thereby distinguishing between the four different syntax forms which are supported so far). In addition, it names a few out of many data carrier instances that have the capability to encode GS1 data structures, but do not yet fulfil GS1’s adoption criteria (Type B). Further, it makes clear that there is no chance for a Type C technology to ever become a Type A data carrier.
Figure 5‑5 Data carrier systematisation 
The following paragraphs focus on Type A Data Carriers.
For all Type A GS1 AIDC data carriers there are three levels of abstraction through which the data passes. From highest to lowest, they are:
■ Application data: These are GS1 data elements defined in a data-carrier neutral way. A business application sees the same data regardless of data carrier used.
■ Transfer encoding: This is the representation of data used in the interface between a capturing application and the hardware device that interacts with the data carrier (barcode scanner or RFID Interrogator).
■ Carrier internal representation: This is the representation of data in the data carrier itself. In a barcode, this is the pattern of light and dark bars, squares or dots. In an RFID tag, this is the binary data stored in the digital memory of the RFID chip.
Table 5‑2 Data carrier representations and the corresponding GS1 standards
There are three types of data that may be involved in carrier internal representation and in transfer encoding:
■ Application data: Data that is delivered from the Capture layer to the Share layer. Application data is data carrier independent.
■ Control data: Data that is used to control interaction with the data carrier.
■ Carrier data: Data that describes the data carrier itself.
Table 5‑3 Means of indicating GS1 data structures in Type A Data Carriers
6 Share – Business data and communication
This section discusses the architectural foundations underlying GS1 standards for business data sharing.
The GS1 standards for sharing business data enable automated interactions between two or more end users. The end users involved must have a common understanding of the structure and meaning of business data, and this leads to GS1 standards that define the content of business data. Moreover, the end users must have an agreed method of communicating data between themselves, and this leads to GS1 standards for communication of business data. The open nature of value networks implies that an end user may not always know in advance where to find relevant business data, and this leads to GS1 interface standards for data and service discovery across the value network. In an international environment, such standards must balance the need for the seamless flow of data across the world with the need to respect national sovereignty and local regulation. This leads to principles of world-wide federation that inform the design of GS1-provided services that aid in discovery.
These four topics are discussed in detail in the remainder of this section.
6.1 Content of standardised business data
6.2 Communication of business data
6.3 Data and service discovery
6.4 Worldwide federation
6.5 Layering of interface standards – Content vs. Syntax vs. Transport
GS1 standards for business data pertain to three categories:
■ Master data that provide descriptive attributes of entities identified by GS1 identification keys, including trade items, parties, and physical locations.
■ Transaction data that consists of transactions related to business processes across the value network.
■ Visibility event data provide details about the “what, when, where, why” activity in the value network.
6.1.1 Master data
Master data are attributes of an entity that are static or nearly so. For a trade item class, for example, master data might include the trade item’s dimensions, descriptive text, nutritional information in the case of a food product, and so on. For a legal entity, master data might include the name of the organisation, its postal address, geographic coordinates, contact information, and so on.
Master data provide the information necessary for applications to understand entities and to process them appropriately in business processes.
Data sharing in the GS1 system is built on an architectural pattern that combines data in recurring business documents with master data:
■ Master data associates the GS1 identification key with the attributes that describe the corresponding entity.
■ Recurring business documents with transaction data and visibility event data refer to entities by use of GS1 identification keys.
■ Applications that process the recurring business documents obtain a complete set of information by combining the GS1 identification keys referenced in business documents with the associated master data. In this way, the repetition of master data attributes in each recurring business document is avoided.
There are six methods supported in the GS1 system by which a data recipient may receive master data from a data source:
1. Synchronisation in advance: A data recipient obtains master data prior to processing any recurring business documents. This is referred to as “synchronisation” because the process of obtaining master data in this way is repeated periodically in order that the data recipient’s copy of master data is consistent (“synchronised”) with the master copy published by the data source.
2. Peer-to-peer communication in advance: A data source of master data can send master data directly to a data recipient in a specialised EDI message, such as Item Data Notification (GS1 XML) and Price Sales Catalogue – PRICAT (GS1 EANCOM).
3. Query on demand: A data recipient obtains master data for a given entity by issuing a query to a lookup service, where the query contains the GS1 identification key for the entity whose master data is desired. In this method, it is possible to defer obtaining master data associated with a given GS1 identification key until the data recipient is processing a business document containing that key.
4. Embedding in a business document: A business document itself may contain master data attributes in addition to a GS1 identification key. In this way, the consuming application does not need to obtain master data from another source.
5. Embedding in a AIDC data carrier: A AIDC data carrier (barcode or RFID tag) affixed to an entity may contain attributes that describe the entity. GS1 standards for capture may be used to extract these attributes and pass them to a business application.
6. Embedding in a web page: A set of master data may be published on a web page using the GS1 Web Vocabulary. GS1 Digital Link URIs can be used to point to such data.
The first three methods in this list follow the architectural pattern of pre-aligning master data as described above. Methods 4 and 5 are used when it is not possible or convenient to pre-align master data. Method 6 can be used for pre-alignment and non-pre-alignment situations.
The following subsections cover master data for trade items in detail and for other GS1 identification keys more generally.
6.1.1.1 Master data for trade items
Master data for trade items may apply to one or more trade items. Five different scopes exist for trade item master data, each corresponding to a different level of identification:
■ Global Model Number-level: Attributes that apply to all GTINs that are part of a “Model” or “type” of trade item.
■ GTIN-level: Attributes that apply to all instances of a given GTIN are GTIN-level master data attributes.
■ Consumer Product Variant-level: Attributes that apply to a specific variant of a given GTIN.
■ Batch/lot-level: Attributes that apply to all instances of a GTIN within a single batch or lot as defined by the manufacturer.
■ Instance-level: Attributes that apply to a single instance of a GTIN identified by GTIN plus serial number.
An example of GTIN-level master data attributes for a trade item are the product name and its physical dimensions (for a fixed-measure trade item). An example of a batch/lot-level master data attribute is the expiration date, which is typically identical for all instances within a given batch/lot but varies from one lot to the next. An example of an instance-level master data attribute is the harvest geo-coordinates of a tuna carcass.
In all three of the above examples, the master data attributes do not change over the life of the trade item instances concerned. It is this static nature of such attributes that makes them “master data.” The volume and rate of creation of master data is different for different scopes of business application. GTIN-level master data is created infrequently, at the rate of new product introduction, instance-level master data is created every time a new trade item instance is manufactured, and batch/lot-level master data is somewhere in between.
The Global Product Classification (GPC) defines a code that locates a trade item within a taxonomy of all trade items; a trade item’s GPC code is therefore a very important master data attribute, both to describe the trade item and to identify what sets of category-specific master data attributes might be available for that trade item.
6.1.1.2 Master data associated with other entities
Besides trade items, the entities for which master data alignment is most important are locations and organisations. The GS1 identification key for locations and organisations is the GLN. Master data related to the GLN include for example its function, postal address, geo-coordinates, opening hours, etc. In case the GLN is used to identify an organisation, the master data may include other attributes such as a company registration number, associated bank account, etc. Peer-to-peer master data alignment related to locations or organisations can be done by implementing the GS1 EDI Party Information message (PARTIN).
Master data may exist for any of the types of entities that can be identified by GS1 identification keys. In practice, the communication of master data for entities other than those identified by GTIN or GLN is achieved during the sharing of business transactions or event data related to these entities.
6.1.2 Transaction data
Transaction data are business information required to support a collaborative business process shared bilaterally between organisations. Often these are functionally the same as their namesake paper documents, such as purchase order and invoice. Transaction data is consumed by software applications, not directly by humans. This means that the GS1 design principles include rules such as only exchanging coded rather than clear text information and that master data should be aligned before exchanging the transactional data.
GS1 standards for transaction data, collectively named GS1 EDI, are provided to automate business transactions commonly occurring across value networks. This includes business processes beginning with a buyer ordering goods from a supplier and progressing to the final receipt of cash by the supplier in exchange for those goods. GS1 standards for transaction data also support business processes such as demand forecasting, transport, traceability data, clinical trials, etc.
Transaction Data are always shared within the framework of a business agreement (contract) between two parties. Each document confirms the commitment to execute the agreement; for example, sending an electronic purchase order message implies that the sender wants to receive the ordered goods according to the conditions agreed in the contract, and will pay for them.
The GS1 standards for transaction data include:
■ GS1 EANCOM
■ GS1 XML
■ GS1 UN/CEFACT XML
6.1.2.1 EDI standards evolution
EDI standards evolve to support the emerging business requirements. There could be different technical solutions depending on the requirement. The range could be a simple addition of a new value in a code list to the creation of a new message or a set of messages. To drive consistency, identification of the best approach is a critical part of the standard evolution, keeping into account two main objectives:
1. Reduce the impact in terms of complexity and affected community outside the one requiring the change.
2. Keep the standards as much cross sectorial as possible.
To support these goals, a GSMP Procedure defines a workflow including the most relevant points to assess. This GSMP Procedure is not applicable when the business requirement is strongly related to the adoption of new technologies, not yet supported. In that case the extension of existing standards is not possible.
6.1.3 Visibility event data
Visibility Event Data are records of the completion of business process steps in which physical or digital entities are handled. Where Transaction Data confirm legal or financial interactions between trading partners, Visibility Event Data confirm the carrying out of a physical process or a comparable digital process. Examples of processes that may be the subject of Visibility Event Data include affixing of identification to a newly manufactured object (“commissioning”), shipping, receiving, movement from one location to another, picking, packing, transfer at point-of-sale, and destroying.
The same business process may simultaneously yield Visibility Event Data and Transaction Data as shown in the diagram below.
Figure 6‑1 Relationship between Transaction Data and Visibility Event Data
Examples of three business processes that generate different kinds of data:
■ In some cases, a visibility event coincides with a business transaction, so that there may be a piece of Transaction Data and a piece of Visibility Event Data describing different aspects of the same occurrence. For example, when products are shipped from a loading dock, there may be a Despatch Advice confirming the sender’s intent to deliver specific products to the receiver and one or several “shipping” EPCIS events confirming the observation of products leaving the loading dock.
■ A visibility event may occur with no corresponding business transaction. For example, when a trade item moves from the “back room” storage of a retail store to the sales area where a consumer can purchase it. This is a highly relevant event for purposes of assessing availability of product to consumers, but it has no associated business transaction.
■ A business transaction may take place with no corresponding visibility event. For example, when a buyer sends an “order” message to a supplier, there is a legal interaction, but nothing occurring in the physical world where the ordered products reside.
Each Visibility Event can have up to five data dimensions:
■ What: Identification of the physical or digital object(s) involved in the event, expressed using a GS1 identification key (e.g., GTIN with a serial number)
■ When: The date and time when the event took place
■ Where: The physical location involved in the event, which may include:
□ The physical location where the event took place
□ The physical location where the objects are expected to be following the event
■ Why: Details about the business process context in which the observation took place, which may include:
□ An identification of the business process taking place at the time of the event
□ The business state of the objects following the event
□ Links to relevant Transaction Data (especially in those cases where a visibility event and a business transaction occur simultaneously)
■ How: Conditional information about an object or a physical location, as captured by sensors (ranging from simple or multi-dimensional physical observations to outputs of smart sensor devices, incl. concentration of chemical substances and microorganisms)
Visibility Event Data is defined by the GS1 Electronic Product Code Information Services (EPCIS) standard.
This GS1 Lightweight Messaging standard provides a simple and lightweight messaging framework for value network participants to ask verification questions to each other. The standard defines how actionable information can be shared between parties. Messaging is based on various authentication checks on the product identifier and associated data.
GS1 standards offer several methods for communication of Business Data between end users. In summary, the methods are:
■ “Push” methods, where one party unilaterally transfers data to another in the absence of a prior request. Push methods may be further classified as:
□ Bilateral party-to-party push, where one party transfers data directly to another party
□ Publish/subscribe, where one party transfers data to a data pool, which in turn pushes the data to other parties who have previously expressed interest in that data by registering a subscription (“selective push”)
□ Broadcast, where a party publishes Business Data in a publicly accessible place such as a World Wide Web page, where it may be retrieved by any interested party.
■ “Pull” or “query” methods, where one party makes a request for specific data to another party, who in turn responds with the desired data.
In principle, any of the above communication methods could be used for any of the categories of business data that are governed by GS1 business data standards. In practice, the type of data dictates the most appropriate communication methods and GS1 standards support the combinations that end users have found to be most useful. They are summarised in the table below:
Table 6‑1 Summary of the most useful communication methods per data type
GS1 standards for business data and communication provide the means for two end users to share business data reliably, once they have identified each other. GS1 standards for data and service discovery exist to help end users identify each other.
In general, there are four ways that one end user might identify sources of data owned or maintained by other end users:
■ Pre-arrangement: In many cases, one end user identifies another by means of some pre-arrangement that takes place outside the scope of any GS1 standard. For example, bilateral sharing of business transaction data via GS1 EDI typically takes place between end users who have identified each other in advance and agreed to trade with each other. Pre-arrangement requires no GS1 standards. In principle, it is possible to share data across an entire value network by exploiting pre-arrangement in a “1 up, 1 down” pattern. In this pattern, it is presumed that each party in a value network has pre-arranged data pathways established between its immediate predecessor (“1 up”) and immediate successor (“1 down”) with respect to the flow of goods. Such pathways therefore form a chain along which data can be shared from any point in the chain to any other. However, the ability to do so is limited by the willingness of all parties along the chain to cooperate, and whether they are all operational at the time data is to be shared, and whether they are willing to propagate the data with the flow of goods or otherwise identify the next adjacent trading partner in response to a query.
■ Originating Party Service Lookup: In some cases, an end user may wish to share data with the party that originates a given entity, such as the brand owner of a trade item. Originating Party Service Lookup refers to methods by which any value network party can find and initiate data sharing with the originating party.
■ Identifier resolution: The concept of Identifier resolution is the ability to connect or redirect a GS1 identification key to one or more a Web resources that provide information and/or services related to the entity identified by the GS1 identification key.
■ Event Data Discovery: In some cases, an end user may wish to advertise the availability data to all parties that have interacted with or otherwise have an interest in a given entity throughout its lifetime in the value network. For example, in “tracking” goods through the value network it is useful to obtain observations made by all parties that handled the goods to form a complete picture of what happened. Event Data Discovery refers to finding the complete set of value network parties that have relevant data, though that introduces related problems of trust and access control.
Originating Party Service Lookup, Identifier Resolution and Event Data Discovery require additional services beyond the bilateral relationships between trading partners, and those services may be supported by GS1 standards. The following sections explain this in more detail.
6.3.1 Originating Party Service Lookup
The GS1 Digital Link standard specifies not only a Web URI syntax for GS1 identifiers but also a resolver / resolution capability for linking a GS1 Digital Link URI to one or more sources of relevant information and services. Resolvers for GS1 Digital Link typically redirect to one of those services, depending on the value of the link type specified by the client or the default link specified within the resolver records. Any party may operate a resolver for GS1 Digital Link and one resolver may redirect to another
GS1 operates a global root resolver for GS1 Digital Link at hostname id.gs1.org. This resolver has a special policy that only permits the respective licensee of the GS1 identifier to configure redirection records for that identifier. In some cases, the GS1 global root resolver redirects requests for a particular GS1 prefix to the corresponding national GS1 member organisation, if they also operate a resolver for GS1 Digital Link.
The GS1 global root resolver also acts as a 'resolver of last resort' to support resolution of GS1 Digital Link URIs in canonical or reference format. This is useful in situations where the data carrier encodes element strings and the GS1 Digital Link URI is obtained by translation, rather than being read directly from the data carrier.
Before GS1 Digital Link resolver infrastructure was standardised and operational, GS1 previously standardised and operated the Object Name Service, which had more limited capabilities and did not handle redirection natively via HTTP(S) redirection.
GS1 no longer operates an Object Name Service globally, and although its standard has not yet been deprecated or withdrawn, it is no longer maintained and the infrastructure for ONS is no longer supported by GS1 GO.
6.3.2 Identifier Resolution
A Resolver for GS1 Digital Link URIs connects a GS1-identified item to one or more online resources that are directly related to it. The item may be identified at any level of granularity, and the resources may be either human or machine readable. Examples include product information pages, instruction manuals, patient leaflets, clinical data, product data, service APIs, marketing experiences and more. By adhering to a common protocol based on existing GS1 identifiers and existing Web technologies, each conformant GS1 resolver is part of a coherent yet distributed network of information resources.
6.3.3 Event Data Discovery
Event Data Discovery refers to the challenge of finding all relevant source of visibility event data (traceability data) for an individual product instance / shipment at each stage of its journey through a supply chain network or value network.
Because of commercial sensitivities, companies are reluctant to share traceability data with parties beyond their immediate 1-up/1-down trading partners except on a need-to-know / right-to-know basis. As a list of links or proof of connectedness can be commercially sensitive, we need mechanisms that enable it to be prepared, shared and used/navigated in a way that does not enable harvesting of commercially sensitive business intelligence.
A viable prototype algorithm is now in development, which will enable a machine-interpretable cryptographic 'proof of connectedness' to be used to enable data sharing beyond 1-up / 1-down immediate trading partners, allowing each querying party to prove their 'connectedness' for any product instance or shipment mentioned in their query.
A fundamental architecture principle of the GS1 system is that each end user retains control over the data it originates. However, certain types of data are logically aggregated across many different end users. An example is master data in the Global Data Synchronisation Network, where each end user can synchronise master data for trade items identified by their Global Trade Identification Number (GTIN), regardless of the originator.
The most straightforward implementation of a global information resource of this kind is a single database maintained by some central authority. However, a single, centralised database has several drawbacks:
■ Scalability: A single database must be large enough to accommodate the aggregate volume of data and queries across the world.
■ Local Preferences: In different countries there may be different regulatory requirements as well as cultural preferences for critical services of this kind.
■ National Sovereignty: To the extent that each nation views services of this kind as an essential part of its business infrastructure, it may be uncomfortable with a centralised service hosted by another nation.
In contrast, a federated approach has the following properties:
■ Data distributed among multiple repositories, using the GS1 identification key as the basis for distribution.
In GDSN, this is realised through the existence of multiple certified GDSN Data Pools, each of which is the “home” repository for the master data associated with a subset of GS1 identification keys.
GS1 Resolvers can be set up by any party and are thus part of a federation, especially if they redirect to each other as appropriate to answer a given query.
■ Data may be replicated among repositories so that the failure of one repository does not affect users of others.
In GDSN, this is realised through synchronisation of data pools so that all data pools receive copies of the master data for all GS1 identification keys, regardless of where the data originated.
In the GS1 Registry Platform, this is realised through multiple redundant servers.
GS1 standards that define interfaces facilitate interoperability between different system components deployed by end users. They are typically specified in three layers. All standards in the Share layer, as well as some infrastructure standards in the Capture layer, are designed in this way.
■ Abstract content: This is the primary layer of an interface specification. In this layer, the roles that interact via the interface are defined, along with their specific interactions. Abstract content is often specified in GS1 standards using the Unified Modelling Language (UML). There is increasing interest in defining our semantic data models in a way that is independent of concrete syntax. In addition to the visual approach of UML, W3C Linked Data standards such as RDF, RDFS, OWL and SKOS are also relevant for such semantic modelling. The Semantic Data Modelling Technical Bulletin provides a primer on these and how they relate to UML class diagrams.
■ Concrete syntax: In this layer, the concrete syntax for the representation of data defined in the abstract content layer is specified. Many standards provide a single concrete syntax definition, but some standards may provide two or more alternative concrete syntaxes for the same abstract syntax. An example is the coexistence of GS1 XML and GS1 EANCOM syntax for GS1 EDI or the coexistence of JSON/JSON-LD and XML data bindings in the forthcoming new version of EPCIS (v2.0).
■ Message transport: In this layer, the means for delivering a message having a concrete syntax from one side of the interface to another is specified. Message transport is the area where there is the most variety in the technical choices that can be negotiated between the parties. The layered structure ensures, however, that regardless of the choice of message transport the content of the messages may have the same syntax, and in all cases have the same meaning.
These layers are illustrated in Figure 6‑2 (in this figure, the specific technologies mentioned are illustrative only; a given standard may specify a different set of options):
Figure 6‑2 Typical GS1 interface standard
7 GS1 Data Services
“GS1 Data Services” is an umbrella term for services that are defined by the GS1 federation for the ultimate benefit of the users of the GS1 system. Most of the services are provided by GS1 Global Office (GO), but in some cases, GS1 Member Organisations (MOs) are free to provide their own versions of the services as long as they are certified as being equivalent to those provided by GO. Furthermore, MOs are free to enhance the services provided by GO by supplementing them with additional features, as long as the core capabilities are still available to their users. Each GS1 Data Service is available globally and with consistent functionality (as viewed by the intended users of the service) around the world.
There exists a subset of GS1 Data Services that have, as their direct customers, only GS1 MOs. Some of these are mandatory to be implemented by all GS1 MOs. These are referred to as Core Data Services, as shown in Figure 7‑1. Additionally, there are SaaS Component Services that are available for optional use by GS1 MOs so that they may implement their own versions of some services.
MOs are required to offer the mandatory Core Data Services to their member companies, and also have flexibility to provide additional Value-Added Services in their geography. Such Value-Added Services are not necessarily offered globally and are not coordinated by GS1 globally. As such, value-added services are out of scope of this architecture document.
GS1 also offers a number of public data access mechanisms, including the GS1 Resolver service, GEPIR query service and the Verified by GS1 public query service (in 2021).
GS1 maintains and provides access to Data Services Resources that include the EPCIS Libraries and various software development kits (SDKs).
Lastly, GS1 maintains the GS1 Global Registry™, which is a single-function registry that is used solely within and across the Global Data Synchronisation Network (GDSN) Data Pools. It is considered a Core Data Service for GDSN.
These GS1 Data Services are illustrated in Figure 7‑1, which is intended to convey only the provision of a service (and does not represent the data flows back and forth for any particular service).
Figure 7‑1 GS1 Data Services breakdown
GS1 Global Office builds services on a series of foundational principles that ensure fitness for use by the GS1 Federation to serve industry:
1. Be user-centric: GS1 Data Services are designed to support business processes and use cases, focused on trading partner needs and providers of business value.
2. GS1 identification keys and standards as the foundation: GS1 Data Services are based on the foundation of the GS1 identification keys and associated basic master data. The formats of data stored in and shared by the services are compliant with the GS1 standards for data exchange and validation.
3. Security: GS1 Data Services are provided with appropriate physical, logical and commercial security (access control, authentication, non-repudiation and so on).
4. Data quality and integrity: Data quality is core to the design of all GS1 Data Services and supporting programs.
5. Regulatory compliance: The aim is to provide a framework that GS1 Member Organisations can draw on to help with local and regional regulatory compliance.
6. Service availability: GS1 Data Services should be available globally, at all times (24×7×365), and should be accessible and supportable to meet the needs of the industries that GS1 serves.
7. Extensible and backward-compatible system: Extensibility and agility are necessary for all GS1 Data Services to adapt to new technologies, to enable more efficient business processes and to expand the user community.
7.1 Services offered by GS1 Global Office to GS1 Member Organisations
7.2 Services offered by GS1 Global Office to Public
7.3 Standards Support Resources offered by GS1 Global Office to Public
7.4 Services offered for the GDSN Network
7.1.1 Core Data Services
Core Data Services are the GO-developed, mandatory services that are accessible by GS1 MOs and that serve as elements of an IT infrastructure to partially enable MO provision of Core Services to their member companies.
7.1.1.1 GS1 Registry Platform
In 2019, GS1 agreed to develop a global registry platform to store GS1 Company Prefix and single-issue GS1 identification key licences (Licence Registry) and only a minimal, thin set of basic master data attributes related to GS1 identification keys. These scalable, global, thin GS1 identification key registries are accessed by MOs only through a standard framework of APIs that enable GS1 MOs to get data IN and OUT.As of 2021, there exists a Licence Registry and a GTIN Registry. Additional GS1 identification key registries will be added in accordance with industry priority. Also, the registries are designed so that links to other sources of data (web links) may be recorded as well, independently of the GS1 identification key registries (and, in fact, independently of whether a GS1 identification key registry even exists for a given GS1 identification key type).
The GS1 Registry Platform also includes a Data Analytics environment for GS1 MOs that enables dashboarding and reporting on usage of the platform and about data quality and completeness.
7.1.1.2 GEPIR
GEPIR (Global Electronic Party Information Registry) is a unique, Internet-based service that provides basic contact information associated with GS1 Company Prefix and single GS1 identification key licences issued by GS1 Member Organisations (and, under special circumstances) by GS1 Global Office. Upon assignment of a GS1 Company Prefix or single-issue GS1 identification key to an organisation, the GS1 Member Organisation registers the organisation’s name and contact details in a server that complies with the GEPIR specifications.
The backbone for the GEPIR network is the GEPIR Root Directory. The Root Directory is an XML file that provides information on the routing of queries in the network based on the GS1 Prefixes assigned to individual GS1 Member Organisations.
Query services to GEPIR are provided by GS1 Member Organisations. They provide access to GEPIR records through a number of different access mechanisms.
GS1 Global Office Public Query of GEPIR services is discussed in section 7.2.1.
7.1.1.3 Resolver
The GS1 Global Office Resolver service (https://www.gs1.org/standards/gs1-resolver-service), while technically integrated into the GS1 Registry Platform infrastructure, is a standalone service that allows MOs to offer their members the ability to link their identifiers to one or more sources of information, as defined in the GS1 Digital Link standard. The GS1 Resolver service significantly increases the value of the GS1 system of identifiers. It means that GTINs, GLNs, SSCCs, GRAIs and more can act as gateways to multiple sources of information for business partners and consumers. The possibilities are endless: linking a food product to traceability and allergen information, linking an asset to its service history, linking a pharmaceutical to information for patients on the one hand and for clinicians on the other, and much more are possible. With the Resolver service, each barcode and/or RFID chip can perform multiple functions, eliminating the need to add new codes to an item every time there is a new use case.
7.1.2 SaaS Component Services
7.1.2.1 Global Activate Service Component (Data IN component)
GS1 Global Office has developed and maintains a service component that enables GS1 MOs to create GS1 identification keys and register those keys into the GS1 Registry Platform with the required attribution. This component enables simple integration of the necessary APIs into their existing systems.
7.1.2.2 Global Data OUT Service Component (in 2021)
The Global Data OUT Service Component is a web-based application/tool that provides MOs with a user interface that enables them to provide a query mechanism to their member companies for the GS1 Registry Platform.
7.2.1 GEPIR Query Service
GS1 Global Office provides a public access mechanism for GEPIR (https://gepir.gs1.org). Users may query for licensee information for any GS1 identification key and may request product or location information, if supported by the GS1 Member Organisation. Public access is limited to a fixed number of queries per day per IP address to preserve the integrity of the GEPIR network.
7.2.2 GS1 Resolver Query Service
GS1 provides an unrestricted public query service for the GS1 Resolver. Users may query the service for any links provided for a GS1 Digital Link URI.
GS1 offers a portfolio of support resources to make adoption of GS1 standards easier.
7.3.1 Global Product Classification (GPC) Browser
The Global Product Classification (GPC) is a standardised classification system (https://www.gs1.org/services/gpc-browser) that gives buyers and sellers a common language for grouping products in the same way, everywhere in the world. The official (normative) GPC schema and corresponding GPC Browser is published in Oxford English, and both the schema and the Browser are translated to other languages. The GPC Browser allows an end user to browse all components (Segment, Family, Class, Brick and Attribute) of the latest GPC schema and that supported by GDSN (which may be older).
7.3.2 Global Data Dictionary (GDD)
The Global Data Dictionary (GDD) is a repository of the data elements defined across all GS1 standards at (http://apps.gs1.org/gdd/SitePages/Home.aspx).
The scope of the GDD is the Business Message Standards (BMS) and their components with definitions for GDSN, GS1 XML for EDI, TDS and EPCIS. The Business Messages are composed of Business Information Entities that comprise classes of information and their attributes. The attributes, in turn, have data types that may contain code lists.
7.3.3 Check Digit Calculator
The Check Digit Calculator (https://www.gs1.org/services/check-digit-calculator) is available to the public as most GS1 identification keys need a check digit. After entering the GS1 identification keys’ numeric value, a check digit is automatically and accurately calculated to ensure the integrity of the GS1 identification key.
7.3.4 GS1 GitHub Site
GS1 maintains a GitHub site (https://github.com/gs1 ) with source code examples for solution providers and other third-party developers to create products based on the GS1 system of standards. This code library is available for anyone to create proofs of concept or to integrate into their solutions based on the standards. Public repositories at this time include code for the GS1 Digital Link standard, EPCIS, and interpreting GS1 barcodes.
7.3.5 EPC Tools
The set of EPC Tools allow third parties to make use of and build on GS1 EPC standards.
7.3.5.1 EPC Encoder/Decoder
This interactive application translates between different forms of the Electronic Product Code (EPC), following the EPC Tag Data Standard (TDS) 1.13.
7.3.5.2 EPCIS Workbench
The EPCIS Workbench (https://epcisworkbench.gs1.org) is a free, interactive tool for working with the GS1 Electronic Product Code Information Services (EPCIS) standard.
7.3.5.3 AIDC Translator Library
The AIDC Translator Library (https://www.gs1.org/sites/default/files/docs/epc/gs1 aidc translator brochure 2020 06.pdf) is commercial-grade licensed software designed to handle all the RFID and barcode data translation needs. Its API is designed for rapid integration with any application. All EPC schemes and their respective binary formats are supported.
7.3.5.4 FREEPCIS
The free EPCIS repository (https://freepcis.gs1.org) is for development and testing. It allows third party providers to test their systems with respect to EPCIS events.
7.3.5.5 RFIDcoder
RFID encoding and decoding API services (https://rfidcoder.gs1.org) provide a REST API for encoding and decoding UHF Gen2 RFID tags according to the GS1 EPC Tag Data Standard.
The GS1 Global Data Synchronisation Network (GDSN) is a network of interoperable data pools enabling the collaboration of users to securely synchronise master data based on GS1 standards. GDSN supports accurate, trade item updates among subscribed trading partners. This network relies on a central registry called the GS1 Global Registry™, which is developed and maintained by GS1 Global Office.
For more information visit https://www.gs1.org/services/gdsn.
Figure 7‑2 How GDSN works
8 Glossary
The glossary lists the terms and definitions that are applied in this document. Please refer to the www.gs1.org/glossary for the online version.
9 References
The various links and references contained in Annex A (Summary of GS1 standards: Identify, Capture & Share) and B (Summary of GS1 application standards & solutions) of the previous version of this GS1 System Architecture can be found at:
Change Log
Log of Changes