ISO/IEC 19988:2017

INTERNATIONAL ISO/IEC
STANDARD 19988
Second edition
2017-10
Information technology — Core
Business Vocabulary Standard
Technologies de l’information — Vocabulaire normatif relatif aux
activités de base
Reference number
©
ISO/IEC 2017
© ISO/IEC 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2017 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardization.
National bodies that are members of ISO or IEC participate in the development of International
Standards through technical committees established by the respective organization to deal with
particular fields of technical activity. ISO and IEC technical committees collaborate in fields of
mutual interest. Other international organizations, governmental and non‐governmental, in
liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO
and IEC have established a joint technical committee, ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular the different approval criteria
needed for the different types of document should be noted. This document was drafted in
accordance with the editorial rules of the ISO/IEC Directives, Part 2
(see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such
patent rights. Details of any patent rights identified during the development of the document will
be in the Introduction and/or on the ISO list of patent declarations received (see
www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and
does not constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the
following URL: www.iso.org/iso/foreword.html.
This document was prepared by the GS1 and was adopted, under the PAS procedure, by Joint
Technical Committee ISO/IEC JTC 1, Information technology, in parallel with its approval by
national bodies of ISO and IEC.
This second edition cancels and replaces the first edition (ISO/IEC 19988:2015), which has been
technically revised.
The main changes compared to the previous edition are as follows:
— A new standard vocabulary for EPCIS error declaration reason identifiers is added.
— The URI structure for EPCIS event identifiers is specified.
— New business step values dispensing and voidShipping added.
— New disposition values dispensed and partially_dispensed added.
— A new section for trade item master data attributes is added, and the section on location and
party master data attributes is expanded.
© ISO/IEC 2017 – All rights reserved iii

Core Business Vocabulary Standard
Document Summary
Document Item Current Value
Document Name Core Business Vocabulary Standard
Document Date Sep 2016
Document Version 1.2
Document Issue
Document Status Ratified
Document Description specifies the structure of vocabularies and specific values for the
vocabulary elements to be utilised in conjunction with the GS1 EPCIS
standard
Log of Changes
Release Date of Changed By Summary of Change
Change
1.0 Oct 2010 Initial release
1.1 March 2014 A new standard vocabulary for EPCIS source/destination type is added.
Templates for new user vocabularies for EPCIS source/destination identifier,
EPCIS transformation identifier, and object classes are added.
New business step, disposition, and business transaction type values are
added. The definitions of existing values are also clarified.
Disposition values non_sellable_expired, non_sellable_damaged,
non_sellable_disposed, non_sellable_no_pedigree_match, and
non_sellable_recalled defined in CBV 1.0 are deprecated in favour of new
disposition values expired, damaged, disposed, no_pedigree_match, and
recalled introduced in CBV 1.1.
RFC5870-compliant geocoordinate URIs are now permitted as location
identifiers.
The introductory material is revised to align with the GS1 System
Architecture.
1.2 Sep 2016 CBV 1.2 is fully backward compatible with CBV 1.1 and 1.0.
CBV 1.2 includes these new or enhanced features:
A new standard vocabulary for EPCIS error declaration reason identifiers is
added.
The URI structure for EPCIS event identifiers is specified.
New business step values dispensing and voidShipping added.
New disposition values dispensed and partially_dispensed added.
A new section for trade item master data attributes is added, and the section
on location and party master data attributes is expanded.
Disclaimer ®
GS1 , under its IP Policy, seeks to avoid uncertainty regarding intellectual property claims by requiring the participants in
the Work Group that developed this Core Business Vocabulary Standard to agree to grant to GS1 members a royalty-
free licence or a RAND licence to Necessary Claims, as that term is defined in the GS1 IP Policy. Furthermore, attention is
drawn to the possibility that an implementation of one or more features of this Specification may be the subject of a patent
or other intellectual property right that does not involve a Necessary Claim. Any such patent or other intellectual property
right is not subject to the licencing obligations of GS1. Moreover, the agreement to grant licences provided under the GS1
IP Policy does not include IP rights and any claims of third parties who were not participants in the Work Group.
Accordingly, GS1 recommends that any organisation developing an implementation designed to be in conformance with this
Specification should determine whether there are any patents that may encompass a specific implementation that the
organisation is developing in compliance with the Specification and whether a licence under a patent or other intellectual
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 2 of 59
© ISO/IEC 2017 – All rights reserved

Core Business Vocabulary Standard
property right is needed. Such a determination of a need for licencing should be made in view of the details of the specific
system designed by the organisation in consultation with their own patent counsel.
THIS DOCUMENT IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF
MERCHANTABILITY, NONINFRINGMENT, FITNESS FOR PARTICULAR PURPOSE, OR ANY WARRANTY OTHER WISE ARISING
OUT OF THIS SPECIFICATION. GS1 disclaims all liability for any damages arising from use or misuse of this Standard,
whether special, indirect, consequential, or compensatory damages, and including liability for infringement of any
intellectual property rights, relating to use of information in or reliance upon this document.
GS1 retains the right to make changes to this document at any time, without notice. GS1 makes no warranty for the use of
this document and assumes no responsibility for any errors which may appear in the document, nor does it make a
commitment to update the information contained herein.
GS1 and the GS1 logo are registered trademarks of GS1 AISBL.
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 3 of 59
© ISO/IEC 2017 – All rights reserved

Core Business Vocabulary Standard
Table of Contents
1 Introduction – Core Business Vocabulary . 7
2 Relationship to the GS1 System Architecture . 7
3 Relationship to EPCIS . 8
3.1 EPCIS event structure . 8
3.2 Vocabulary kinds . 9
3.2.1 Standard Vocabulary . 9
3.2.2 User Vocabulary . 10
4 Terminology and typographical conventions . 10
5 Compliance and compatibility . 11
5.1 CBV Compliant . 11
5.2 CBV compatible . 13
6 Use of Uniform Resource Identifiers (URIs) . 14
6.1 URI prefix for Standard Vocabularies in the CBV. 14
6.2 Limitation on Use of the URI prefix . 14
6.2.1 Example of limitation of use of URI prefix (non-normative) . 14
7 Standard Vocabularies . 15
7.1 Business steps . 15
7.1.1 URI structure . 15
7.1.2 Compliant usage . 15
7.1.3 Element values and definitions – Business step . 16
7.2 Dispositions . 22
7.2.1 URI structure . 22
7.2.2 Compliant usage . 23
7.2.3 Element Values and definitions – Dispositions . 23
7.3 Business Transaction Types . 27
7.3.1 URI structure . 27
7.3.2 Compliant usage . 27
7.3.3 Element Values and Definitions – Business Transaction Types . 27
7.4 Source/Destination types . 28
7.4.1 URI structure . 28
7.4.2 Compliant usage . 28
7.4.3 Element Values and Definitions – Source/Destination Types . 28
7.5 Error reason identifiers . 29
7.5.1 URI structure . 29
7.5.2 Compliant usage . 29
7.5.3 Element Values and Definitions – Error reason identifiers . 29
8 User vocabularies . 29
8.1 General considerations . 29
8.1.1 General Considerations for EPC URIs as User Vocabulary Elements . 30
8.1.2 General Considerations for Private or Industry-wide URN as User Vocabulary elements . 31
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 4 of 59
© ISO/IEC 2017 – All rights reserved

Core Business Vocabulary Standard
8.1.3 General Considerations for HTTP URLs as User Vocabulary elements . 31
8.2 Physical or digital objects (Instance-Level Identification) . 32
8.2.1 EPC URI for Instance-level identification of objects . 33
8.2.2 Private or Industry-wide URN for Instance-level identification of objects . 33
8.2.3 HTTP URLs for Instance-level identification of objects . 33
8.3 Physical or digital objects (Class-level identification) . 34
8.3.1 EPC URI for Class-level identification of objects . 34
8.3.2 Private or Industry-wide URN for Class-level identification of objects . 35
8.3.3 HTTP URLs for Class-level identification of objects . 36
8.4 Locations . 36
8.4.1 EPC URI for Location identifiers . 37
8.4.2 Private or Industry-wide URN for Location identifiers . 37
8.4.3 HTTP URLs for Location identifiers . 37
8.4.4 Geographic Location URIs for Location identifiers . 38
8.5 Business transactions . 38
8.5.1 EPC URI for Business transaction identifiers . 39
8.5.2 GLN-based identifier for legacy system business transaction identifiers . 39
8.5.3 Private or Industry-wide URN for business transaction identifiers . 40
8.5.4 HTTP URLs for business transaction identifiers . 40
8.6 Source/Destination identifiers . 40
8.6.1 EPC URI for Source/Destination identifiers . 41
8.6.2 Private or Industry-wide URN for Source/Destination identifiers . 41
8.6.3 HTTP URLs for Source/Destination identifiers . 41
8.7 Transformation identifiers . 42
8.7.1 EPC URI for Transformation identifiers . 42
8.7.2 GLN-based Identifier for Legacy System Transformation identifiers . 42
8.7.3 Private or Industry-wide URN for Transformation identifiers . 43
8.7.4 HTTP URLs for Transformation identifiers . 43
8.8 Event identifiers . 43
8.8.1 Universally Unique Identifier (UUID) URIs for Event identifiers. 44
9 Trade item master data . 44
9.1 Trade item master data attribute names . 45
9.2 Trade item master data attributes . 45
9.2.1 Trade item master data attributes – trade item level . 46
9.2.2 Trade item master data attributes – lot level . 47
9.2.3 Trade item master data attributes – instance-level . 49
9.2.4 Values of type measurement . 49
10 Location and party master data . 50
10.1 Location and party master data attribute names . 50
10.2 Location and party master data attributes . 51
10.3 Location master data code list values . 52
10.3.1 Sub-Site Type . 53
10.3.2 Sub-Site Attributes . 53
11 Example EPCIS Documents (non-normative) . 55
11.1 CBV-Compliant object event using standard vocabulary . 55
11.2 CBV-Compliant object event using HTTP URLs and Private or Industry-wide URNs . 56
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 5 of 59
© ISO/IEC 2017 – All rights reserved

Core Business Vocabulary Standard
11.3 CBV-Compatible event . 57
11.4 Location master data . 58
12 References . 58
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 6 of 59
© ISO/IEC 2017 – All rights reserved

Core Business Vocabulary Standard
1 Introduction – Core Business Vocabulary
This GS1 standard defines the Core Business Vocabulary (CBV). The goal of this standard is to
specify various vocabulary elements and their values for use in conjunction with the EPCIS standard
[EPCIS1.2], which defines mechanisms to exchange information both within and across organisation
boundaries. The vocabulary identifiers and definitions in this standard will ensure that all parties
who exchange EPCIS data using the Core Business Vocabulary will have a common understanding of
the semantic meaning of that data.
This standard is intended to provide a basic capability that meets the above goal. In particular, this
standard is designed to define vocabularies that are core to the EPCIS abstract data model and are
applicable to a broad set of business scenarios common to many industries that have a desire or
requirement to share data. This standard intends to provide a useful set of values and definitions
that can be consistently understood by each party in the supply chain.
Additional end user requirements may be addressed by augmenting the vocabulary elements herein
with additional vocabulary elements defined for a particular industry or a set of users or a single
user. Additional values for the standard vocabulary types defined in this standard may be included
in follow-on versions of this standard.
This standard includes identifier syntax and specific vocabulary element values with their definitions
for these Standard Vocabularies:
Ŷ Business step identifiers
Ŷ Disposition identifiers
Ŷ Business transaction types
Ŷ Source/Destination types
Ŷ Error reason identifiers
This standard provides identifier syntax options for these User Vocabularies:
Ŷ Objects
Ŷ Locations
Ŷ Business transactions
Ŷ Source/Destination identifiers
Ŷ Transformation identifiers
Ŷ Event identifiers
This standard provides Master Data Attributes and Values for describing Physical Locations
including:
Ŷ Site Location
Ŷ Sub-Site Type
Ŷ Sub-Site Attributes
Ŷ Sub-Site Detail
Additional detailed master data regarding locations (addresses, etc.) are not defined in this
standard.
2 Relationship to the GS1 System Architecture
The Core Business Vocabulary is a companion standard to the EPCIS standard. EPCIS is the
standard that defines the technical interfaces for capturing and sharing event data. EPCIS defines a
framework data model for event data. The Core Business Vocabulary is a GS1 data standard that
supplements that framework by defining specific data values that may populate the EPCIS data
model. As such, the CBV exists in the “Share” group of GS1 standards.
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 7 of 59
© ISO/IEC 2017 – All rights reserved

Core Business Vocabulary Standard
3 Relationship to EPCIS
This section specifies how the Core Business Vocabulary standard relates to the EPC Information
Services (EPCIS) standard.
3.1 EPCIS event structure
The EPCIS 1.2 standard [EPCIS1.2] specifies the data elements in an EPCIS event. The following
lists these data elements, and indicates where the Core Business Vocabulary provides identifiers
that may be used as values for those data elements.
Ŷ The “what” dimension: The what dimension for most event types contains one or more
unique identifiers for physical or digital objects or classes of physical or digital objects.
Identifiers for physical or digital objects in the Core Business Vocabulary are specified in
Section 8.2 (instance-level) and Section 8.3 (class-level). In the case of an EPCIS
TransformationEvent, an optional TransformationID may be used to link together multiple
events that describe the same transformation. The Core Business Vocabulary includes
TransformationIDs in Section 8.7.
Ŷ The “when” dimension: The moment in time at which an EPCIS event occurred. Event time is
fully specified in the EPCIS standard.
Ŷ The “where” dimension: The “where” dimension consists of two identifiers that describe
different aspects of where an event occurred:
Ƒ Read Point: The location where the EPCIS event took place. In the case of an EPCIS event
arising from reading a barcode or RFID tag, the Read Point is often the location where the
barcode or RFID tag was read. Identifiers for read points in the Core Business Vocabulary
are specified in Section 8.3.
Example: A reader is placed at dock door #3 at the London Distribution Centre (DC).
Product passed through the dock door. Read point = DC Dock Door #3>
Ƒ Business Location: The location where the subject of the event is assumed to be following
an EPCIS event, until a new event takes place that indicates otherwise. Identifiers for
business locations in the Core Business Vocabulary are specified in Section 8.3.
Example: A product is read through the sales floor transition door at store #123. The
product is now sitting on the sales floor. Business location = store #123 Sales Floor>
Ŷ The “why” dimension: The “why” dimension consists of two identifiers and a list of business
transaction identifiers, which collectively provide the business context or “why” the event
occurred:
Ƒ Business Step: Denotes a specific activity within a business process. The business step
field of an event specifies what business process step was taking place that caused the
event to be captured. Identifiers for business steps in the Core Business Vocabulary are
specified in Section 7.1.
Example: an EPCIS event is generated as a product departs the location identified by the
Read Point. Business Step = 
Ƒ Disposition: Denotes the business state of an object. The disposition field of an event
specifies the business condition of the subject of the event (the things specified in the
“what” dimension), subsequent to the event. The disposition is assumed to hold true until
another event indicates a change of disposition. Identifiers for dispositions in the Core
Business Vocabulary are specified in Section 7.2.
Example: an EPCIS event is generated and afterward the products can be sold as-is and
customers can access product for purchase. Disposition = “sellable and accessible”>
Ƒ Business Transaction References: An EPCIS event may refer to one or more business
transaction documents. Each such reference consists of two identifiers:
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 8 of 59
© ISO/IEC 2017 – All rights reserved

Core Business Vocabulary Standard
- Business Transaction Type: Denotes a particular kind of business transaction.
Example: the identifier that denotes “purchase order”. Identifiers for business
transaction types in the Core Business Vocabulary are specified in Section 7.3.
- Business Transaction Identifier: Denotes a specific business transaction document of
the type indicated by the Business Transaction Type.
Example:
Identifiers for business transactions in the Core Business Vocabulary are specified in
Section 8.5.
Ƒ Source and Destination References: An EPCIS event may refer to one or more sources
and/or destinations that describe the endpoints of a business transfer of which the event is a
part. Each source or destination reference consists of two identifiers:
- Source or Destination Type: Denotes a particular kind of source or destination.
Example: the identifier that denotes “owning party”.  Identifiers for source and
destination types in the Core Business Vocabulary are specified in Section 7.4.
- Source or Destination Identifier: Denotes a source or destination of the type
indicated by the Business Transaction Type. Example: Example Corp as an owning party> Identifiers for sources and destinations in the Core
Business Vocabulary are specified in Section 8.6.
3.2 Vocabulary kinds
(The material in this section is adapted directly from [EPCIS1.2], Section 6.2.)
Vocabularies are used extensively within EPCIS to model conceptual, physical, and digital entities
that exist in the real world.
Examples of vocabularies defined in the EPCIS standard are business steps, dispositions, location
identifiers, physical or digital object identifiers, business transaction type names, and business
transaction identifiers. In each case, a vocabulary represents a finite (though open-ended) set of
alternatives that may appear in specific fields of events.
It is useful to distinguish two kinds of vocabularies, which follow different patterns in the way they
are defined and extended over time:
Ŷ Standard Vocabulary: A Standard Vocabulary is a set of Vocabulary Elements whose definition
and meaning must be agreed to in advance by trading partners who will exchange events using
the vocabulary.
Ŷ User Vocabulary: A User Vocabulary is a set of Vocabulary Elements whose definition and
meaning are under the control of a single organisation.
These concepts are explained in more detail below.
3.2.1 Standard Vocabulary
A Standard Vocabulary is a set of Vocabulary Elements whose definition and meaning must be
agreed to in advance by trading partners who will exchange events using the vocabulary. For
example, the EPCIS standard defines a vocabulary called “business step,” whose elements are
identifiers denoting such things as “shipping,” “receiving,” and so on. One trading partner may
generate an event having a business step of “shipping,” and another partner receiving that event
through a query can interpret it because of a prior agreement as to what “shipping” means.
Standard Vocabulary elements tend to be defined by organisations of multiple end users, such as
GS1, industry consortia outside GS1, private trading partner groups, and so on. The master data
associated with Standard Vocabulary elements, if any master data is defined at all, are defined by
those same organisations, and tend to be distributed to users as part of a standard or by some
similar means. New vocabulary elements within a given Standard Vocabulary tend to be introduced
through a very deliberate and occasional process, such as the ratification of a new version of a
standard or through a vote of an industry group.
The Standard Vocabularies specified in the Core Business Vocabulary standard are: business steps
(Section 7.1), dispositions (Section 7.2), business transaction types (Section 7.3), and source and
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 9 of 59
© ISO/IEC 2017 – All rights reserved

Core Business Vocabulary Standard
destination types (Section 7.4). The elements and definitions are agreed to by parties prior to
exchanging data, and there is general agreement on their meaning.
Example: the following is a business step identifier defined in Section 7.1 herein:
urn:epcglobal:cbv:bizstep:receiving
This identifier is defined by the GS1 Core Business Vocabulary standard, and its meaning is known
and accepted by those who implement the standard.
While an individual end user organisation acting alone may introduce a new Standard Vocabulary
element, such an element would have limited use in a data exchange setting, and would probably
only be used within an organisation’s four walls. On the other hand, an industry consortium or other
group of trading partners may define and agree on standard vocabulary elements beyond those
defined by the Core Business Vocabulary, and these may be usefully used within that trading group.
3.2.2 User Vocabulary
A User Vocabulary is a set of Vocabulary Elements whose definition and meaning are under the
control of a single organisation. For example, the EPCIS standard defines a vocabulary called
“business location,” whose elements are identifiers denoting such things as “Acme Corp. Distribution
Centre #3.” The location identifier and any associated master data is assigned by the user. Acme
Corp may generate an event whose business location field contains the identifier that denotes
“Acme Corp. Distribution Centre #3,” and another partner receiving that event through a query can
interpret it either because the partner recognises the identifier as being identical to the identifier
received in other events that took place in the same location, or because the partner consults
master data attributes associated with the location identifier, or both.
Example:
urn:epc:id:sgln:0614141.12345.400
This identifier is assigned by the End User who owns the GS1 Company Prefix 0614141, and the
meaning of the identifier (that is, what location it denotes) is determined exclusively by that end
user. Another End User can understand the meaning of this identifier by consulting associated
master data.
User Vocabulary elements are primarily defined by individual end user organisations acting
independently. The master data associated with User Vocabulary elements are typically defined by
those same organisations, and are usually distributed to trading partners through the EPCIS Query
Interface or other data exchange / data synchronisation mechanisms. New vocabulary elements
within a given User Vocabulary are introduced at the sole discretion of an end user, and trading
partners must be prepared to respond accordingly.
While the Core Business Vocabulary standard does not (and as the discussion above makes clear,
cannot) specify particular user vocabulary elements, the Core Business Vocabulary does provide
syntax templates that are recommended for use by End Users in constructing their own user
vocabulary elements. See Section 8.1. The user vocabularies for which templates are specified in
this standard are: physical or digital objects (Sections 8.2 and 8.3), locations which include both
read points and business locations (Section 8.4), business transaction identifiers (Section 8.5),
source/destination identifiers (Section 8.6), and transformation identifiers (Section 8.7).
4 Terminology and typographical conventions
Within this standard, the terms SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY, NEED NOT, CAN,
and CANNOT are to be interpreted as specified in Annex G of the ISO/IEC Directives, Part 2, 2001,
4th edition [ISODir2]. When used in this way, these terms will always be shown in ALL CAPS; when
these words appear in ordinary typeface they are intended to have their ordinary English meaning.
All sections of this document, with the exception of Sections 2, 3 and 3 are normative, except where
explicitly noted as non-normative.
The following typographical conventions are used throughout the document:
Ŷ ALL CAPS type is used for the special terms from [ISODir2] enumerated above.
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 10 of 59
© ISO/IEC 2017 – All rights reserved

Core Business Vocabulary Standard
Ŷ Monospace type is used to denote programming language, UML, and XML identifiers, as well as
for the text of XML documents.
Placeholders for changes that need to be made to this document prior to its reaching the final
¾
stage of approved GS1 standard are prefixed by a rightward-facing arrowhead, as this
paragraph is.
5 Compliance and compatibility
The GS1 Core Business Vocabulary is designed to facilitate interoperability in EPCIS data exchange
by providing standard values for vocabulary elements to be included in EPCIS data. The standard
recognises that the greatest interoperability is achieved when all data conforms to the standard, and
also recognises that individual End Users or groups of trading partners may need to extend the
standard in certain situations.
To that end, this standard defines two levels of conformance for EPCIS documents:
Ŷ CBV-Compliant: An EPCIS document that only uses vocabulary identifiers specified in the Core
Business Vocabulary standard in the standard fields of EPCIS events.
Ŷ CBV-Compatible: An EPCIS document that uses a combination of vocabulary identifiers
specified in the Core Business Vocabulary standard and other identifiers that are outside the
standard.
An EPCIS document is neither CBV-Compliant nor CBV-Compatible if it wrongly uses identifiers
defined in the Core Business Vocabulary standard or if it violates any other rules specified herein.
The formal definition of these terms is specified below.
5.1 CBV Compliant
A “CBV-Compliant Document” is a document that conforms to the schema and other constraints
specified in [EPCIS1.2], and which furthermore conforms to all the normative language in this
standard that pertains to a “CBV-Compliant Document.”
A “CBV-Compliant Application” is any application for which both of the following are true:
Ŷ If it operates in a mode where it claims to accept a CBV-Compliant Document as an input, the
application SHALL accept any document that is a CBV-Compliant Document according to this
standard, and furthermore in processing that input SHALL interpret each CBV identifier
according to the meaning specified herein.
Ŷ If it operates in a mode where it claims to produce a CBV-Compliant Document as an output,
the application SHALL only produce a document that is a CBV-Compliant Document according to
this standard, and furthermore in generating that output SHALL only use CBV identifiers to
denote their meaning as specified herein.
The following list summarises the requirements for an EPCIS document to be a “CBV-Compliant
Document,” as specified elsewhere in this standard:
Ŷ A CBV-Compliant Document SHALL conform to the schema and other constraints specified in
[EPCIS1.2].
Ŷ A CBV-Compliant Document SHALL NOT use any URI beginning with urn:epcglobal:cbv:
except as specified in this standard.
Ŷ Each EPCIS event in a CBV-Compliant Document SHALL include a bizStep field, and the value
of the bizStep field SHALL be a URI consisting of the prefix urn:epcglobal:cbv:bizstep:
followed by the string specified in the first column of some row of the table in Section 7.1.3.
Ŷ A CBV-Compliant Document MAY include a disposition field. If the disposition field is
present, the value of the disposition field SHALL be a URI consisting of the prefix
urn:epcglobal:cbv:disp: followed by the string specified in the first column of some row of
the table in Section 7.2.3.
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 11 of 59
© ISO/IEC 2017 – All rights reserved

Core Business Vocabulary Standard
Ŷ Each EPCIS event in a CBV-Compliant Document MAY include one or more bizTransaction
elements. If bizTransaction elements are present, each such element MAY include a type
attribute. If a given bizTransaction element includes a type attribute, the value of the type
attribute SHALL be a URI consisting of the prefix urn:epcglobal:cbv:btt: followed by the
string specified in the first column of some row of the table in Section 7.3.3.
Ŷ Each EPCIS event in a CBV-Compliant Document MAY include one or more source or
destination elements. The value of the type attribute of each such element SHALL be a URI
consisting of the prefix urn:epcglobal:cbv:sdt: followed by the string specified in the first
column of some row of the table in Section 7.4.3.
Ŷ Each EPCIS event in a CBV-Compliant Document MAY include an ErrorDeclaration element,
and when present, the ErrorDeclaration element MAY include a reason field. When present
in a CBV-Compliant Document, the value of the reason field of the ErrorDeclaration
element SHALL be a URI consisting of the prefix urn:epcglobal:cbv:er: followed by the
string specified in the first column of some row of the table in Section 7.5.3.
Ŷ URIs defined in the EPC Tag Data standard SHALL only be used in a CBV-Compliant Document
as specified in Section 8.1.1.
Ŷ A CBV-Compliant document SHALL use one of the three URI forms specified in Section 8.2 to
populate instance-level identifiers in the “what” dimension of EPCIS events (that is, the
epcList, parentID, childEPCs, inputEPCList, and outputEPCList fields in EPCIS
ObjectEvents, AggregationEvents, TransacationEvents, and
TransformationEvents), for every such field that is not null. A CBV-Compliant document
SHOULD use the EPC URI form as specified in Section 8.2.1 unless there is a strong reason to
do otherwise.
Ŷ A CBV-Compliant document SHALL NOT use an SGLN EPC (urn:epc:id:sgln:…) as an object
identifier.
Ŷ A CBV-Compliant document SHALL use one of the three URI forms specified in Section 8.3 to
populate class-level identifiers in the “what” dimension of EPCIS events (that is, the epcClass
fields in all EPCIS event types), for every such field that is not null. A CBV-Compliant document
SHOULD use the EPC URI form as specified in Section 8.3.1 unless there is a strong reason to
do otherwise.
Ŷ A CBV-Compliant document SHALL use one of the four URI forms specified in Section 8.4 to
populate the “where” dimension of EPCIS events (that is, the readPoint and
businessLocation fields in all EPCIS event types), for every such field that is not null. A CBV-
Compliant document SHOULD use the EPC URI form as specified in Section 8.4.1 unless there is
a strong reason to do otherwise.
Ŷ When using an EPC URI as a location identifier (Section 8.4.1), a CBV-Compliant document
SHOULD NOT use EPC schemes other than SGLN (urn:epc:id:sgln:…), unless there is a
strong reason to do so.
Ŷ A CBV-Compliant document SHALL use one of the four URI forms specified in Section 8.5 to
populate the business transaction identifier field (that is, the text content of the
bizTransaction element) of EPCIS events, for every such field that is not null.
Ŷ When using an EPC URI as a business transaction identifier, a CBV-Compliant Documents
SHOULD NOT use EPC schemes other than GDTI EPCs (urn:epc:id:gdti:…) or GSRN EPCs
(urn:epc:id:gsrn:…), unless there is a strong reason to do so. GDTI EPCs SHOULD only be
used as business transaction identifiers when they have been assigned to denote a business
transaction, rather than a physical document not connected with any business transaction.
Ŷ A CBV-Compliant document SHALL use one of the three URI forms specified in Section 8.6 to
populate a source or destination identifier field (that is, the text content of a source or
destination element), for every such field that is not null. A CBV-Compliant document
SHOULD use the EPC URI form as specified in Section 8.6.1 unless there is a strong reason to
do otherwise.
Release 1.2, Ratified, Sep 2016 © 2016 GS1 AISBL Page 12 of 59
© ISO/IEC 2017 – All rights reserved

Core Business Vocabulary Standard
Ŷ When using an EPC URI as a source or destination identifier (Section 8.6.1), a CBV-Compliant
document SHOULD NOT use EPC schemes other than SGLN (urn:epc:id:sgln:…), unless
there is a strong reason to do so.
Ŷ A CBV-Compliant document SHALL use one of the four URI forms specified in Section 8.7 to
populate the transaction identifier field (that is, the text content of the transformationID
element) of EPCIS TransformationEvents, for every such field that is not null.
Ŷ When using an EPC URI as a transformation identifier, a CBV-Compliant Document SHOULD NOT
use EPC schemes other than GDTI EPCs (urn:epc:id:gdti:…) unless there is a strong reason
to do so. GDTI EPCs SHOULD only be used as transformation identifiers when they have been
assigned to denote a transformation, rather than a physical document not connected with any
transformation.
Ŷ A CBV-Compliant document SHALL use one of the URI forms specified in Section 8.8.1 to
populate the event identifier field (that is, the text content of the eventID element) of an EPCIS
event, whenever that field is not null.
5.2 CBV compatible
A “CBV-Compatible Document” is a document that conforms to the schema and other constraints
specified in [EPCIS1.2], and which furthermore conforms to all the normative language in this
standard that pertains to a “CBV-Compatible Document.”
A “CBV-Compatible Application” is any application for which both of the following are true:
Ŷ If it operates in a mode where it claims to accept a CBV-Compatible Document as an input, the
application SHALL accept any document that is a CBV-Compatible Document according to this
standard, and furthermore in processing that input SHALL interpret each CBV identifier
according to the meaning specified herein.
Ŷ If it operates in a mode where it claims to produce a CBV-Compatible Document as an output,
the application SHALL only produce a document that is a CBV-Compatible Document according
to this standard, and furthermore in generating that output SHALL onl
...