search

gs1 / EPCIS

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

Supporting SimpleMasterDataQuery in GS1 Digital Link Master Data Query #331

Closed JaewookByun closed 3 years ago

JaewookByun commented 3 years ago

Dear all,

In the last meeting, I have got to know GS1 Digital Link Master Data Query could be supported instead of previously supported SimpleMasterDataQuery. Thus, our team have analyzed GS1 Digital Link Master Data Query and shared our analysis.

SimpleMasterDataQuery has previously a capability of

Also, there are 10 user vocabularies types in v2.0 such as

Optimally, we thought it is better for GS1 Digital Link Master Data Query to support whole capabilities of SimpleMasterDataQuery and user vocabularies defined in v2.0. In the analysis, we found there are some issues. For example, /414/:gln should return the vocabularies of 'Party' as well as ReadPoint, BusinessLocation, SourceDest, Location.

We built an education client for 'REST Master Data Query' and enable to learn and use our basic idea of how to embed GS1 Digital Link Master Data Query in REST Query Service in Oliot EPCIS X prototype. http://dfpl.sejong.ac.kr/epcis/home/restMDQuery.html (UI enhanced by Haifa Gaza, Master Student, Auto-ID Labs, Korea)

Users can set one of 6 supported REST endpoints and use URL parameters supported in SimpleMasterDataQuery. /01/:gtin /01/:gtin/10/:lot /414/:gln /414/:gln/254/:ext /253/:gdti /vocabularies

Best Regards, Jaewook Byun Ph.D., Assistant Professor, Department of Software, Sejong University, Republic of Korea Associate Director, Auto-ID Labs, Korea jwbyun@sejong.ac.kr , bjw0829@kaist.ac.kr https://github.com/JaewookByun/epcis (v2.0 prototype is now hidden) https://sites.google.com/view/jack-dfpl/home https://www.youtube.com/channel/UC988e-Y8nto0LXVae0aqaOQ

mgh128 commented 3 years ago

Dear Jaewook,

Thanks for looking into this in further detail. Although AI (417) is the relatively new official GS1 Application Identifier for party GLN, before it was introduced, some organisations had been using AI (414) physical location GLN to identify a party, particularly in the source / destination fields. We encourage users to use (417) for new applications or updates but don't want to put those who were historically using (414) out of compliance, because they did so before (417) was introduced into the GS1 General Specifications.

Many thanks to you and Haifa Gaza for enhancing the OLIOT open source EPCIS project to support the GS1 Digital Link approach to master data. It appears to be working correctly. My only comment is that although it is certainly allowed to express any additional key=value pairs via the URI query string, it's entirely up to the online resource to decide whether to process these or ignore these. This means that although you might express constraints about vocabularyName, HASATTR etc., the online target resource is not required to understand EPCIS SimpleMasterDataQuery and its parameters and that it is perfectly acceptable for it to simply return all the master data it has (or decides to provide) for the thing identified using the GS1 Digital Link URI. This could be in JSON-LD format (but potentially XML or other formats) and it might use terms from the GS1 Web vocabulary, schema.org or potentially attributes from CBV v1.2 MDA / ILMD (at least until all of those are expressible via the GS1 Web vocabulary - we're aware that there are still some gaps in coverage before the GS1 Web vocabulary is a complete replacement for CBV MDA and ILMD properties )

JaewookByun commented 3 years ago

Dear Mark Harrison,

Thanks for your comment. -1- After thinking twice with your comment, I realized for GS1 Digital Link Master Data Query (i.e., 01, 10, 414, 254, 253) does not require URI parameters like SimpleMasterDataQuery because it already successfully specifies the target resource. So, we would remove URI parameter support for GS1 Digital Link Master Data Query and support /vocabularies? and URI parameters for SimpleMasterDataQuery as out-of-scope of the standard.

-2- thanks for your information on (417). probably, I have missed it.

-3- If there is a JSON-LD format for master data in consensus, we could return the data in JSON-LD as well as XML. However, I heard in the last meeting that , as a draft, JSON/JSON-LD would omit header of EPCIS Document as well as EPCIS Master Data Document. Is there still master data syntax in JSON schema?

-4- supporting ILMD for GS1 Digital Link Master Data Query looks interesting topic.

Thanks again.

mgh128 commented 3 years ago

Dear @JaewookByun You're correct that a Web request for a GS1 Digital Link URI with linkType=gs1:masterData already specifies the subject for which the master data should be returned. Although parameters from SimpleMasterDataQuery could be expressed in the URI query string of a GS1 Digital Link URI, there is no requirement for the responding target resource to understand these or to process the result differently, depending on the parameter values specified. It would also be acceptable for the target resource to be a static JSON-LD file with master data about a particular product class, location, organization etc.

Regarding a consensus format in JSON-LD for master data, we expect that the data may make typically use of properties, classes and code lists / code values defined within the GS1 Web vocabulary ( https://gs1.org/voc ) and/or schema.org As far as I'm aware, GS1 has not indicated any preference about whether JSON-LD should be expanded, compacted or framed in a particular way. Regarding master data syntax in JSON Schema, looking at https://github.com/gs1/EPCIS/pull/298/files I see ilmd being specified as a non-empty JSON object with URI strings as keys. I don't see any detailed syntax validation rules for cbv mda.

Regarding (4) supporting ILMD for GS1 Digital Link Master Data Query, there are some known gaps / mismatches between what can be expressed in ILMD vs the GS1 Web vocabulary. I noted some of these in a white paper I shared with the group. However, we have not yet prepared a work request to address the gaps, nor have we formally defined the mappings in a machine-interpretable way.