What is the relationship between this vocabulary and EPCIS?

[mgh128]

The GS1 Web vocabulary is an external extension to schema.org ( see http://blog.schema.org/2016/02/gs1-milestone-first-schemaorg-external.html ) and is primarily intended for expressing master data (e.g. ingredients, material composition, nutritional info, info about allergens, additives, certifications etc.) about products in greater detail than can currently be expressed using schema.org alone.

EPCIS is a GS1 open standard for interoperable exchange of visibility event data (for sharing traceability data), first released in 2007. Core Business Vocabulary (CBV) is a complementary GS1 open standard that defines a number of code lists and values that should be used for populating some of the EPCIS event fields, such as bizStep and disposition, or expressing the type of source or destination or type of referenced business transaction. Both of these GS1 open standards are available to download from https://www.gs1.org/epcis where you can also access machine-readable artifacts such as XSD and WSDL files. EPCIS and CBV are also recognised as ISO standards via the PAS process, as ISO/IEC 19987:2017 and ISO/IEC 19988:2017 respectively.

Both EPCIS and CBV are being updated to version 2.0, which introduces a REST OpenAPI interface (to complement the existing WSDL+SOAP bindings) for the query and capture interface, as well as a JSON / JSON-LD data binding for the event data and instance/lot master data. As part of that modernisation and the JSON-LD data binding, the CBV code lists and the EPCIS event data model will both be made available as browsable Linked Data models, probably with a very similar look-and-feel to the GS1 Web vocabulary and with a JSON-LD download available for the underlying RDF data model, although we (GS1) feel that these are logically separate from the GS1 Web vocabulary, so they will have their own separate Linked Data URI namespaces hosted at gs1.org.

EPCIS / CBV v2.0 modernisation efforts will also result in some updates to the GS1 Web vocabulary, including additional properties within the gs1:CertificationDetails class. The idea is that EPCIS events will be able to link to machine-interpretable certification details at a Web URL, using gs1:CertificationDetails and its attributes. We will also add a new code list for expressing different types of physical properties (e.g. Temperature, Pressure, Humidity etc.) since the high-level sensor data extensions in EPCIS v2.0 will need to indicate what type of measurement each sensor report represents, rather than inferring it solely from a UN ECE Rec20 UoM code string.

I hope this answers your questions regarding EPCIS / CBV and how it relates to the GS1 Web vocabulary and our other Linked Data efforts at GS1. If you have further questions or feedback, let's continue the discussion. I'm actively involved in the JSON/JSON-LD data binding for EPCIS and the updates to the GS1 Web vocabulary and Linked Data models for CBV and EPCIS.

[OR13]

We need a section at the top of the spec that describes EPCIS / CBV generally.

@mgh128 would you be willing to add a few paragraphs to the respec to close this out? may I assign you this issue?

[mgh128]

Yes. Did the explanation above look suitable or did you need something even more concise?

[OR13]

@mgh128 IMO the explanation above is perfect start :)

[mgh128]

@mgh128 IMO the explanation above is perfect start :)

@OR13 - please feel free to copy/paste my explanation into the traceability vocabulary document, making minor edits where appropriate. I'm happy to review it afterwards but have to focus on some other urgent things for GS1.

@OR13, @mprorock - I'm recommending that most references to gs1:Place , gs1:PostalAddress and gs1:ContactPoint and the properties within those classes should instead reference schema.org/Place, schema.org/PostalAddress and schema.org/ContactPoint instead - and the corresponding properties within those schema.org classes.

Known differences are that GS1 Web vocabulary defines gs1:crossStreet (absent from schema.org) and there might be one or two other minor differences on a couple of attributes. GS1 Web vocabulary will soon be adding a dedicated property for 'street address line 2' (because we will soon have dedicated GS1 Application Identifiers for ship-to/deliver-to street address line 1 and ship-to/deliver-to street address line 2 - and the same for the return-to address street address line 1 and line 2 ). GS1 Web vocabulary will also be adding a new property for address suburb (which a smaller geographic region than an addressLocality (which is typically a town or city).

[brianwmunz]

FYI I've submitted PR #46 that should address the GS1 references at least, but not the addition of the explanation.

[mprorock]

this has been merged - keeping issue open for now as there will likely be some debate on this issue still. once agreed on broadly, we will update the docs to reflect the selected approach

[OR13]

I think the remaining action for this issue is better EPCIS Event examples implemented as Verifiable Credentials

[OR13]

Discussed on call today. We still need examples.

ping @mgh128, are there other folks we should be reaching out to to help with this?

[mprorock]

should we close this one out and open a new issue for examples provided from gs1? @mgh128 any chance of working with us to get some examples in?

[mgh128]

The next two weeks are busy for me but if you can outline what the examples should express, I can try to prepare some this month - or ask @PhilArcher to help?

Did you already look at the draft JSON-LD examples for EPCIS 2.0 within github.com/gs1/EPCIS ?

[OR13]

@mgh128 thanks for pinging Phil, I think this is enough for us to start with:

https://github.com/gs1/EPCIS/blob/master/JSON/WithDigitalLinkID/Example_9.6.2-ObjectEventWithDigitalLink.jsonld

{
  "@context": ["https://gs1.github.io/EPCIS/epcis-context.jsonld",{"example": "http://ns.example.com/epcis/"}],
  "id": "_:document1",
  "isA": "EPCISDocument",
  "schemaVersion": "2.0",
  "creationDate": "2005-07-11T11:30:47.0Z",
  "epcisBody": {
    "eventList": [
      {
        "eventID": "ni:///sha-256;115b14983df54a9bcc3dd6a00dc4ebcab000bd52fda0abdd8996907e01dccc23?ver=CBV2.0",
        "isA": "ObjectEvent",
        "eventTime": "2013-06-08T14:58:56.591Z",
        "eventTimeZoneOffset": "+02:00",
        "action": "OBSERVE",
        "bizStep": "urn:epcglobal:cbv:bizstep:receiving",
        "disposition": "urn:epcglobal:cbv:disp:in_progress",
        "readPoint": {"id": "urn:epc:id:sgln:0614141.00777.0"},
        "bizLocation": {"id": "urn:epc:id:sgln:0614141.00888.0"},
        "quantityList": [
          { "epcClass": "https://id.gs1.org/01/70614141123451/10/998877", "quantity": 200, "uom": "KGM" }
        ],
        "sourceList": [
          { "type": "urn:epcglobal:cbv:sdt:possessing_party", "source": "urn:epc:id:sgln:4012345.00001.0" },
          { "type": "urn:epcglobal:cbv:sdt:location", "source": "urn:epc:id:sgln:4012345.00225.0" }
        ],
        "destinationList": [
          { "type": "urn:epcglobal:cbv:sdt:owning_party", "destination": "urn:epc:id:sgln:0614141.00001.0" },
          { "type": "urn:epcglobal:cbv:sdt:location", "destination": "urn:epc:id:sgln:0614141.00777.0" }
        ],
        "example:myField": "Example of a vendor/user extension"
      }
    ]
  }
}

"id": "_:document1", => credentialSubject.id

This could be a DID, but could also be the blank node identifier you provide in your example.

[mgh128]

@mgh128 thanks for pinging Phil, I think this is enough for us to start with:

https://github.com/gs1/EPCIS/blob/master/JSON/WithDigitalLinkID/Example_9.6.2-ObjectEventWithDigitalLink.jsonld

{
  "@context": ["https://gs1.github.io/EPCIS/epcis-context.jsonld",{"example": "http://ns.example.com/epcis/"}],
  "id": "_:document1",
  "isA": "EPCISDocument",
  "schemaVersion": "2.0",
  "creationDate": "2005-07-11T11:30:47.0Z",
  "epcisBody": {
    "eventList": [
      {
        "eventID": "ni:///sha-256;115b14983df54a9bcc3dd6a00dc4ebcab000bd52fda0abdd8996907e01dccc23?ver=CBV2.0",
        "isA": "ObjectEvent",
        "eventTime": "2013-06-08T14:58:56.591Z",
        "eventTimeZoneOffset": "+02:00",
        "action": "OBSERVE",
        "bizStep": "urn:epcglobal:cbv:bizstep:receiving",
        "disposition": "urn:epcglobal:cbv:disp:in_progress",
        "readPoint": {"id": "urn:epc:id:sgln:0614141.00777.0"},
        "bizLocation": {"id": "urn:epc:id:sgln:0614141.00888.0"},
        "quantityList": [
          { "epcClass": "https://id.gs1.org/01/70614141123451/10/998877", "quantity": 200, "uom": "KGM" }
        ],
        "sourceList": [
          { "type": "urn:epcglobal:cbv:sdt:possessing_party", "source": "urn:epc:id:sgln:4012345.00001.0" },
          { "type": "urn:epcglobal:cbv:sdt:location", "source": "urn:epc:id:sgln:4012345.00225.0" }
        ],
        "destinationList": [
          { "type": "urn:epcglobal:cbv:sdt:owning_party", "destination": "urn:epc:id:sgln:0614141.00001.0" },
          { "type": "urn:epcglobal:cbv:sdt:location", "destination": "urn:epc:id:sgln:0614141.00777.0" }
        ],
        "example:myField": "Example of a vendor/user extension"
      }
    ]
  }
}

"id": "_:document1", => credentialSubject.id

This could be a DID, but could also be the blank node identifier you provide in your example.

I should just caution that the EPCIS JSON-LD examples and context resource(s) in GitHub are still draft, hopefully fairly stable, but still potentially subject to change or errata fixes until EPCIS 2.0 is ratified.

[OR13]

related to #167

Discussed on the call today, decision to tackle smaller PR first, and gather reviews.

[OR13]

@mkhraisha pending PR

[mprorock]

@mkhraisha any updates on EPCIS, specifically as related to events?

[nissimsan]

We should aim for more EPCIS, less schema.org. Keeping this open, needs effort.

[mgh128]

Our draft EPCIS v2.0 examples and schema in JSON/JSON-LD at https://github.com/gs1/EPCIS/ should be fairly stable and GS1 is still hoping to publish the ratified version of EPCIS/CBV 2.0 this quarter, if all goes according to plan. EPCIS/CBV probably has plenty of what you need if the focus is on representing event data of activities within supply chains, even though it generally has much less focus on master data than I saw in the w3c-ccg traceability vocabulary - but of course, in Linked Data you can use terms from multiple vocabularies - and our schema for EPCIS 2.0 has plenty of 'extension points' where terms from 'other' namespaces can be included without upsetting the validation schema.

[nissimsan]

@mgh128, thanks for your patience. :) Would you be willing to spend an hour with me when the v2.0 dust has settled, and I'd be happy to take lead in giving our epcis schemas another swing? Around early July'ish?

[mgh128]

@nissimsan - yes, certainly - though late June (before 30th June) works better for me - I'm on holiday in early July. Already what you see at https://github.com/gs1/EPCIS is fairly stable. There have been some updates since the public review drafts of EPCIS and CBV 2.0, taking into account substantial amounts of feedback and the group's work to resolve those comments and make improvements, though if you already took a look at the public review drafts, you'll already have a very good idea of what to expect in the v2.0 release. I'm in the UK - so hopefully we can find a date and time in late June for a call for further discussion on this. Right now, it's just a case of fixing the last few glitches.

[OR13]

I suggest we link to the other tickets tracking supporting EPCIS and then close this ticket.

[brownoxford]

@nissimsan has volunteered to link and close

[nissimsan]

This conversation lives on on https://github.com/w3c-ccg/traceability-vocab/issues/385 and I also started some implementation work on https://github.com/w3c-ccg/traceability-vocab/pull/552. I suggest we close this issue and focus EPCIS discussions there.

[mkhraisha]

happy to close this issue and keep it running on the other issue