search

gs1 / EPCIS

Draft files being shared for EPCIS 2.0 development
Other
22 stars 7 forks source link

define ILMD #195

Closed VladimirAlexiev closed 3 years ago

VladimirAlexiev commented 3 years ago

ILMD is "Instance/Lot master data" and is defined in EPCIS 1.2 sec 7.3.6 as follows:

(Please, where can I read the draft EPCIS 2.0?)

descriptive attributes that provide information about one or more specific objects or lots. It is similar to ordinary master data... ILMD is similar to event-level EPCIS extensions, but is separate in order to emphasise that ILMD applies for the entire life of objects... standards and systems for dissemination of ILMD do not yet exist. The structure of ILMD defined in this EPCIS standard consists of a set of named attributes, with values of any type. In the XML binding (Section 9.5), the XML schema provides for an unbounded list of XML elements having any element name and content

EPCIS-JSON-Schema.json defines it a a JSON object (dictionary) with any level of nesting:

"ilmd": {
            "type": "object"
        },

EPCIS-SHACL.ttl makes a half-hearted attempt, which is invalid (sh:nodeKind cannot have the value used here):

epcis:ILMD_TypeConstraint  owl:sameAs [
    sh:path epcis:ilmd ;
    sh:nodeKind epcis:ILMD ;

So both XML and JSON define ILMD as a set of name-value pairs where the values can be structured (nested).

In RDF, that can be accommodated easily by saying that the names are (mapped to) URLs, i.e. ILMD is a node with any attributes or outgoing links.

So I think this is needed:

{
  "@context": ["https://gs1.github.io/EPCIS/epcis-context-protected.jsonld","https://gs1.org/voc/"],
  "epcisBody": {
    "eventList": [
      {
        "isA": "ObjectEvent",
        "action": "ADD",
        "bizStep": "urn:epcglobal:cbv:bizstep:commissioning",
        "epcList": ["https://id.gs1.org/01/70614141123451/21/2017"],
        "ilmd": {
          "gs1:weight": 12.3,
          "gs1:expirationDate": "2021-04-19"
        }
      }
    ]
  }
}
mgh128 commented 3 years ago

Hi @VladimirAlexiev The current drafts for EPCIS 2.0 and CBV 2.0 are in the GS1 community room folder at https://xchange.gs1.org/cr/gsmp/mswg/gsmpepciscbvmswg/Pages/Home-wg.aspx and is currently only visible to members of the GS1 EPCIS/CBV 2.0 mission-specific work group who have signed the GS1 IP policy and joined the group, although we're working towards a community review (probably a full public review) in the near future.

I'm sorry that I don't remember whether you're already in the GS1 EPCIS/CBV 2.0 mission-specific work group but we would certainly welcome your participation. There is no financial barrier to participation in GS1 GSMP work groups, so you don't need to be a subscriber/member of a national GS1 member organisation. Further details on joining the group can be found at https://www.gs1.org/standards/development-work-groups#EPCISCBV

mgh128 commented 3 years ago

Hi @VladimirAlexiev We've been discussing the master data topic in the work group calls on the last two Tuesdays. The GS1 Core Business vocabulary added support for master data (including instance/lot master data) before the GS1 Web vocabulary was developed and also before the GS1 Digital Link standard was ratified.

Probably at least 70% of the master data properties in CBV have corresponding properties in the GS1 Web vocabulary but there are some gaps. CBV 1.2 was not particularly forward-looking in the sense that it used URNs for properties and also had a very clunky mechanism for expressing properties/attributes, which we're trying not to carry over into JSON/JSON-LD, though we'll not disrupt it in XML for the existing XML users.

It is now clear that the on-demand access to master data at any level of granularity (GTIN, GTIN+Lot, GTIN+Serial etc.) can be achieved via a combination of GS1 Digital Link (URI syntax + resolvers) combined with publishing master data online in Linked Data format, e.g. JSON-LD, using terms from the GS1 Web vocabulary, even if access to that data requires authentication and authorisation and is subject to access control by the publisher.

At the same time, at least in the XML data binding, we may still have a need to support embedded master data within EPCIS data when it is exchanged as documents rather than retrieved from repositories.

The work group needs to think about whether any master data / ILMD properties will appear under the Web URI namespace for CBV (planned to be at https://ns.gs1.org/cbv/ , development preview at https://ns.mh1.eu/cbv/ ) or whether we'll recommend that we use Web URIs from the GS1 Web vocabulary to express all master data / ILMD properties in the JSON/JSON-LD data binding for EPCIS/CBV and avoid defining any CBV Web URIs for master data properties. If so, we'll need to submit a work request to fill in some of the gaps in the GS1 Web vocabulary.

VladimirAlexiev commented 3 years ago

@mgh128: I've applied to join the workgroup.

I'm all for exposing as much Master Data as possible at permanent URLs and using the Semantic Web principles to facilitate the distribution and consumption of such data. I see @CraigRe says the same in #184, and I can see the hand of @philarcher in all this: both GS1 Voc as a bigger ontology for product properties, and Digital Links and resolvers as a way of getting to such data.

In fact I just gave these EPCIS2 ideas as a positive example in some notes intended to find like-minded souls for EU Horizon Europe research projects in industrial/logistics data:

Leveraging Linked Data and Semantic Web principles in industrial and manufacturing data

The Web Architecture and Linked Data principles offer significant benefits for cross-enterprise data integration scenarios. These have been leveraged in the Web of Things w3c groups and specifications: one can use URLs to access info about devices, read dynamic properties of devices, and interact with devices.

Unfortunately, none of these principles seem to be used in industrial data standards. Some of them have RDF renditions, but RDF is used just as "another data transport" standard. The standards do not rely on permanent URLs, on having master data at these URLs, and do not consider distributed storage and query federation across semantic storage systems. In other words, RDF is used only for "data in motion" but not for "data at rest" or master data. This leaves uncertainties as to "where is the latest version of this master data" and "do I have the latest version".

Two negative examples:

And a positive example:

However, EPCIS to date has been a message-exchange standard. Stakeholders are used to finding master data in EPCIS messages. Most stakeholders don't yet have the capacity to host their own master data: it'll take time to build this up, setup resolvers with GS1, etc. (Note: I don't know enough about the players and economy of EPCIS data pools, so this assessment may be wrong.)

So I think that you'll need some interim transition facility: use GS1 Voc to express master data, be able to expose it at permanent Digital Links, but also be able to transport it in messages.

VladimirAlexiev commented 3 years ago

2021_03_16c EPCIS 2.0 MasterData.pptx proposes the following: image

But is this a sufficient interim solution? It means people can't transmit master data about GTIN or GLN in JSON messages, and can only do it through Digital Links

RalphTro commented 3 years ago

Dear @VladimirAlexiev , Industry groups (e.g. the one maintaining the DSCSA guideline) will still have the option to define an extension in a JSON/JSON-LD file with similar/corresponding functionality as provided by the EPCIS Document Header in XML. Together with the ILMD section, this is the main area of application where EPCIS is used to convey master data. The EPCIS master data document as well as Simple Master Data Query practically was never used in production to our knowledge - this was the main reason why we do not see a reason to further support it - especially given that the actual purpose of EPCIS focusses on visibility event data, not master data. Hope that clarifies your question? After thorough discussions, the group arrived at a very clear consensus about this solution approach in the end. Kind regards, @RalphTro

VladimirAlexiev commented 3 years ago

@RalphTro thanks for the answer! This allays my concerns I'm just joining the group so please forgive me for not yet knowing the ropes :-)

The issue still shouldn't be closed because we need to define the RDF representation of ILMD, and give examples.

CraigRe commented 3 years ago

@VladimirAlexiev still open (and welcome to the group)! :-)

mgh128 commented 3 years ago

Agree to close this? Include in drafts a recommendation to use GS1 Digital Link + GS1 Web voc as forward-looking way to access master data at any level of granularity and for any GS1 ID key (GTIN, GLN etc.) ILMD remains in both data bindings for master data specified per LGTIN or per SGTIN. No machine-readable validation (e.g. XSD, JSON Schema or SHACL) within ILMD - beyond our current scope. Could consider writing a best-practice recommendation to any sector who defines their own extensions: 1 star - document at least in PDF or web page 2 stars - provide online definitions per term 3 stars - as Linked Data 4 stars - with validation files in XSD, JSON Schema. SHACL

VladimirAlexiev commented 3 years ago

Mark's gdoc: https://docs.google.com/spreadsheets/d/1Z0s7bvE3bExbezb-tdMLAVwHTAoeDAMzmJ_m17D-cek/edit

VladimirAlexiev commented 3 years ago

Would be nice to define a class epcis:ILMD for the node carrying the ILMD info. Edit: we have such class