mgh128
commented
4 years ago The fundamental issue is that depending on its structure, a GS1 Digital Link URI may refer to a class of things (e.g. all instances of a product sharing the same GTIN) or it may refer to a subclass (e.g. all instances of a product sharing the same GTIN and lot/batch number) or it may refer to a globally unique individual instance of only one thing (e.g. one single instance of a product having a GTIN and a serial number that is unique within that GTIN).
The query string of a GS1 Digital Link URI can be used to express data attributes (key=value pairs) where in many situations, the key is an all-numeric GS1 Application Identifier or the special keys 'exp' and 'expdt' which are respectively additional short name aliases to GS1 Application Identifiers 17 (expiration date) and 7003 (expiration date and time).
Within barcodes, such GS1 Application Identifiers are used to transmit additional data beyond the identification of the barcoded thing, such as an expiration date, best before date, net weight etc. As @philarcher already mentioned, these are intended to apply to the single physical object carrying a barcode and their value (e.g. the specific value of an expiration date) is understood to apply to that one physical object, whereas other physical objects sharing the same GTIN have a different barcode and may have a different value for expiration date etc.
So the first step is to determine whether the path information of a GS1 Digital Link URI identifies exactly one individual thing globally or whether it can identify more than one. If it identifies exactly one individual thing, then the GS1 Digital Link URI stripped of its query string can be the RDF Subject of various Linked Data RDF Subject-Property-Value triples that represent facts about that globally unique object. If instead the GS1 Digital Link URI stripped of its query string does not identify a single globally unique object, then we instead use a blank node as the RDF Subject of various Linked Data triples, in order to avoid making invalid assertions that would otherwise apply to all instances sharing the same GTIN (or GTIN + batch/lot number) or other primary GS1 identification key.
As @philarcher mentioned, the semantics chapter of draft spec v1.1 of GS1 Digital Link provides an algorithmic procedure for extracting the correct semantic interpretation of the data within a GS1 Digital Link URI. This is detailed in a number of flowcharts and required data tables.
Additionally, at https://github.com/gs1/GS1DigitalLinkCompressionPrototype/ we provide the following method to extract such data, returned as a JSON-LD data object:
analyseURIsemantics(gs1DigitalLinkURI)
While a resolver is expected to pass through (without redaction) the original URI query string to the target resource, there may be situations in which some resolvers support filtering based on specific query string parameters.
For example, when one brand owner acquires the rights to a product from another brand, there is no immediate need to change the GTIN. In this situation, there will be a period of time when products issued by the former brand owner are in circulation in parallel with products issued by the new brand owner, both sharing the same GTIN. It has been suggested that in such situations, it might be possible for the two brand owners to reach an agreement that products carrying a date of production or date of expiry later than a mutually agreed transition date shall be considered to be those issued by the new brand owner. In this situation, it may be helpful for some resolvers to consider the value of specific data attributes in the URI query string in order to determine whether to redirect a request to target resources specified by the previous brand owner or to target resources specified by the new brand owner.
These considerations are mentioned in draft spec 1.1 but are not fully defined in normative statements. We expect that they will be discussed and defined in greater detail in draft spec 1.2 which is expected to consider the ingestion (configuration) interface of a resolver in greater detail.
philarcher
This is actually a lot more complicated than it sounds. We need to be able to add in things like expiry dates and measured weight - i.e. attributes that go into the query string - when entering data. However, the resolver doesn't actually take any notice of query strings - it just passes them through untouched. We quickly get into the same issues we're dealing with around semantics.
https://id.gs1.org/gtin/09506000134352?exp=181225 does not mean that all instances of 09506000134352 expired on 25 December 2018, it means that one unidentified instance of it did.
Whereas https://id.gs1.org/gtin/09506000134352/ser/123456?exp=181225 does mean that that serialised instance expired on that date. This is why the semantics section of the draft spec 1.1 is marked as informative, not normative because it's a bit of a mess we've got ourselves into here.