For PostalAddress, Place and GeoCoordinates use schema.org rather than GS1 Web vocab

[mgh128]

A friendly suggestion...

For the following classes:

• PostalAddress
• Place
• GeoCoordinates

and attributes within those classes, please consider referencing schema.org URIs for those where they exist, instead of referencing the corresponding terms within the GS1 Web vocabulary.

GS1 Web vocabulary ( https://www.gs1.org/voc ) is positioned / acknowledged as an external extension to schema.org and provides a richer set of terms for describing products in greater detail. However, for Organization, Place, PostalAddress and GeoCoordinates we basically replicated most of what was in those schema.org classes without really adding much new, so it's much fairer to reference schema.org for those, even though other Linked Data ontologies (e.g. vCard ) provided some of those terms even earlier.

[OR13]

@mgh128 thanks for this suggestion, will do.

If you can think of any GS1 vocabulary with 100% should use, please open issues suggesting it.

[mgh128]

Hi Orie, all, As you probably already know from your work with Gena Morgan, the main GS1 standards for exchanging traceability event data between parties in a supply chain network are EPC Information Services (EPCIS) and Core Business Vocabulary (CBV). The current ratified version 1.2 of both standards are available at https://www.gs1.org/epcis and are supported by a number of commercial, free and open source implementations. They provide an interoperable machine-interpretable way to exchange event data about creation/commissioning of objects, packing/unpacking, shipping/receiving, transformation and cross-references to business transactions, including data fields that express the "what, where, when, why" of what happened within each event.
Since early 2018, the EPCIS/CBV v2.0 work group has been modernising both standards, including a REST / OpenAPI interface for EPCIS and a JSON/JSON-LD schema for the event data, to complement the existing WSDL+SOAP interface and XML data binding, as well as support for business-relevant summaries of sensor data, e.g. for use in the cold supply chain. You can find some of our examples, validation schema and interface definitions for EPCIS/CBV v2.0 at https://github.com/gs1/EPCIS . Because we have developed a JSON-LD data binding for EPCIS v2.0, every field within the EPCIS event data model will have a corresponding Linked Data Web URI linking to a definition and other details (domain, range / expected data type, etc.) We are also planning some extensions to the GS1 Web vocabulary, to add extra properties to the https://www.gs1.org/voc/CertificationDetails class and to add a code list for expressing measurement types (for Temperature, Pressure etc.) for use within the business-relevant sensor data expressible in EPCIS v2.0 and to support conversion between interconvertible units of measure, e.g. when the data is expressed in one unit of measure (e.g. °C) but a query for that data expresses a value in a different unit (e.g. °F) that is for the same physical property. We have also developed a data table and script for this at https://gs1.github.io/UnitConverterUNECERec20/ We are currently in the middle of prototype testing within the work group. This is expected to continue into the next few weeks and if all goes according to plan, a public review draft of EPCIS should be available within the next 2-3 weeks. I'm making the updates to the Linked Data models for EPCIS and CBV and we plan to post these within https://github.com/gs1/EPCIS later this week together with the other artifacts already there.

[OR13]

Opened https://github.com/w3c-ccg/traceability-vocab/issues/24 to address EPCIS directly

[brianwmunz]

Can we close this because of PR #46 ?

[mgh128]

Yes - just checked PR #46. Looks mostly OK but I would highly recommend ensuring that all date values are expressed in YYYY-MM-DD format so that they can be cast as xsd:date. I still see many examples where the date value is not in that order.