Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add a digital link field to products and organizations (possibly other types). #3475

Open
MatthiasWiesmann opened this issue Mar 4, 2024 · 37 comments
Open

Add a digital link field to products and organizations (possibly other types). #3475

MatthiasWiesmann opened this issue Mar 4, 2024 · 37 comments

Comments

@MatthiasWiesmann
Copy link
Contributor

MatthiasWiesmann commented Mar 4, 2024 •
edited

Problem

GS1's digital link (DL) is presented as the successor to the linear encoding of various identifiers like GTIN. Digital links are typically encoded in QR-codes printed on products or their packaging.

An example of a digital link is https://gs1.appareldemo.com/01/09506000164908/10/ABC123

The path contains the following AI (Application Idenfitiers)

  • 01 – GTIN 09506000164908
  • 10 – Lot number ABC123

The digital link solves some long standing issues with GTIN, in particular they allow to encode the Consumer Product Variants (CPV) field, which allows to distinguish products which share a GTIN, because they don't need to be distinguished in retail. Often they need to be distinguished in online commerce.

Technically, DLs could be represented in multiple ways:

  • Inside the [identifier](https://schema.org/identifier) field. Pros: no change needed. Cons, identifier is the grab-bag for identifiers, so this makes validation and reporting complicated.
  • Inside the url field. Pros: no change needed. Cons, url is pretty vague, agains this makes validation and reporting vague.
  • Inside a dedicated attribute like hasDigitalLink. Pros: role and parsing rules are clear . Cons, new attribute needed.

Level and AI culling

One problem that will require some documentation is the fact that different AIs are only applicable at certain levels.

  • A DL that contains a serial number (AI 21) should only be present on instances of IndividualProduct
  • A DL that contains a lot number (AI 10) could make sense at the product level (if the seller only sells products from that lot), but more probably it should be a the IndividualProduct level.
  • A DL that contains a global model number (AI 8013) or an NSN but no GTIN could be attached to a Product or a ProductModel.
@alex-jansen
Copy link
Contributor

Adding @philarcher and @mgh128 from GS1

@mgh128
Copy link

mgh128 commented Mar 10, 2024

Thanks for considering GS1 Digital Link - though I'm not convinced that it needs a dedicated schema.org property when the GS1 Digital Link URI itself can be the RDF Subject / @id in JSON-LD of various triples / factual claims about a Product, Organization, Place etc.

GS1 Digital Link URI Syntax is a modern Web-friendly alternative to the plain syntax or element string syntax that GS1 uses for expressing its identifiers such as GTIN, SSCC, GLN, GRAI, GIAI etc.

GS1 Digital Link URI Syntax provides a way for GS1 identifiers to be expressed as URIs, as first-class citizens in Linked Data and on the Web, rather than mere string attributes that don't easily link to other information.

GS1 Digital Link URIs support multiple levels of granularity including GTIN+CPV, GTIN+Batch/Lot, GTIN+Serial etc.
This also means that when GS1 Digital Link URIs are used as the RDF Subject (or sometimes the RDF Object) in Linked Data, we can be very precise about which facts are specific to the GTIN (and common to all instances of that GTIN value) versus other facts that are specific to a product batch (GTIN+Batch/Lot) or those that are specific to an individual product instance (GTIN+Serial).

GS1 Digital Link URIs look like structured URLs and can behave like URLs - and through the use of link types and GS1-conformant resolvers, a GS1 Digital Link URI encoded in a QR Code or other suitable data carrier can act like a multi-functional URL, redirecting to multiple kinds of information or services related to the thing it identifies, simply by specifying the desired link type via the URI query string at the time of making the Web request; to have maximum flexibility, it is not recommended to hard-code the link type within the data carrier (e.g. QR Code). Dedicated apps might make use of specific link types for just accessing the master data or information about allergens or nutrition, whereas generic scanning apps will typically be redirected to whichever target URL is specified for the default link for that specific GS1 Digital Link URI.

For example, https://gs1.appareldemo.com/01/09506000164908/10/ABC123?linkType=gs1:certificationInfo could provide information about certifications for that product batch, whereas
https://gs1.appareldemo.com/01/09506000164908/10/ABC123?linkType=gs1:sustainabilityInfo could provide information about sustainability and recycling

A full set of current defined link types can be found at https://www.gs1.org/voc/?show=linktypes

GS1 Digital Link URIs can be used as the RDF Subject in any Linked Data about the thing they represent. You can see an example of this in the block of JSON-LD embedded in the product information page for https://gs1.appareldemo.com/01/09506000164908/10/ABC123

You'll see that the thing whose @type is both schema:Product and gs1:Clothing is not a blank node (as in the three examples shown in the HTML documentation page for https://schema.org/Product ). Instead, you'll see that there's an "@id": "https://gs1.appareldemo.com/01/09506000164908" that asserts that https://gs1.appareldemo.com/01/09506000164908 is the RDF Subject of the various properties defined within that JSON object.

The schema:gtin property is still present in that example but because we expect that a GS1 Digital Link URI would typically appear as the RDF Subject of triples, expressed using @id in JSON-LD, I'm not convinced that we then need an additional field or property within schema.org to express schema:gs1digitallink or anything like that.

@MatthiasWiesmann notes that the type of thing identified by a GS1 Digital Link URI depends on the GS1 Application Identifiers that appear within the URI path information.

GS1 Digital Link URIs that include /01/ followed by a GTIN expressed as 14 digits will correspond to a schema:Product or gs1:Product or one of its descendent subclasses such as gs1:Clothing or gs1:FruitsVegetables.

However, it's also possible that it corresponds to a schema:Offer for a product because a retailer might construct a GS1 Digital Link URI for each of the GTINs it sells. The retailer would not encode those GS1 Digital Link URIs in QR Codes and re-sticker all the products. However, the retailer might configure their in-store self-scan terminals or their mobile retail app to substitute the retailer's GS1 Digital Link URI for the manufacturer's GS1 Digital Link URI that was scanned, in order to be able to show details that correspond to the retailer's schema:Offer for the product, including details about pricing, promotions, availability etc.

GS1 Digital Link URIs that include /01/ followed by a GTIN and also include /21/ followed by a serial number will correspond to a schema:IndividualProduct

GS1 Digital Link URIs that include /414/ followed by a 13-digit physical location GLN will correspond to a schema:Place

GS1 Digital Link URIs that include /417/ followed by a 13-digit party GLN will correspond to a schema:Organization

In the semantics chapter of https://ref.gs1.org/standards/digital-link/ we began work on how to extract the meaning from GS1 Digital Link URIs (including query string data) to output this information as Linked Data. @philarcher and @mgh128 are currently revising and extending this work in preparation for a new GS1 standard addressing the semantics of GS1 Application Identifiers generally, whether they are expressed in GS1 Digital Link URIs or element strings.

@MatthiasWiesmann
Copy link
Contributor Author

MatthiasWiesmann commented Mar 11, 2024 via email

@mgh128
Copy link

mgh128 commented Mar 11, 2024

Hi Matthias,

Thanks for your further detailed explanation about why the search engine crawlers need clues about whether or not a URI is intended to be a GS1 Digital Link URI.

It might be that we need something in schema.org to express that intent, although I would still expect the GS1 Digital Link URI to often appear as the RDF Subject in triples / value of @id in { } objects in JSON-LD. Maybe we could consider a schema.org property such as hypothetically schema:isGS1DigitalLink with a value of true so that when a crawler sees a block like this:

  {
        "@context": {
            "gs1": "http://gs1.org/voc/",
            "schema": "https://schema.org/",
            "xsd": "http://www.w3.org/2001/XMLSchema#"
        },
        "@type": [
            "gs1:Clothing",
            "schema:Product"
        ],
        "@id": "https://gs1.appareldemo.com/01/09506000164908",
        "schema:isGS1DigitalLink": true,
        "schema:name": [
            {
                "@value": "White t-shirt",
                "@language": "en"
            }
        ],
        "schema:gtin": "09506000164908",
        "schema:brand": {
            "@id": "GS1"
        }
    }

there is an explicit assertion that https://gs1.appareldemo.com/01/09506000164908 is intended to be a GS1 Digital Link URI, while still being able to state that its @type is schema:Product and gs1:Clothing

However, being a GS1 Digital Link URI does not require that the corresponding brand owner must embed Linked Data in the corresponding product information page, so perhaps instead of something like "schema:isGS1DigitalLink": true we should be considering something like "schema:hasLinkedMasterData": true or maybe even a dedicated field in the Resolver Description File (see below).

In the meantime, GS1 Digital Link URI Syntax standard indicates how GS1 recommends checking for plausibility and that a Web URI is intended to be a GS1 Digital Link URI :

In section 6.1 of GS1 Digital Link URI Syntax standard, "Recognising a GS1 Digital Link URI", regular expressions are provided to check whether a Web URI plausibly conforms to GS1 Digital Link URI syntax for uncompressed, partially compressed or fully compressed GS1 Digital Link URIs.

Section 2 of GS1 Digital Link URI Syntax standard mentions about testing for the presence of a Resolver Description File at a Well-Known RFC 8615 location at /.well-known/gs1resolver
This is explained in much more detail in section 3 of the new GS1-Conformant Resolver Standard. We'll need to update the reference in section 2 of GS1 Digital Link URI Syntax standard to point here, now that the GS1-Conformant Resolver Standard is published as a separate standard.

Checking for the presence of a Resolver Description File at /.well-known/gs1resolver is probably as close as we go in our current GS1 best practice recommendations to indicate that a URI is intended to be a GS1 Digital Link URI and resolves to some information resources online, though it does not currently indicate whether master data is likely to be available as Linked Data for all URIs sharing that customURIstem / value of the resolverRoot field in the Resolver Description File, though that might be something that could be supported as an optional field within the Resolver Description File in a future version.

Admittedly, the regular expressions in section 6.1 of GS1 Digital Link URI Syntax standard are not sufficiently precise to do a full syntax validation, so Section 4 of GS1 Digital Link URI Syntax standard provides a formal ABNF grammar for all syntactically valid GS1 Digital Link URIs.

Digimarc have very helpfully extracted the ABNF grammar and used this in an open source tool they contributed at https://github.com/gs1/digital-link.js in order to build a validator capability.
Of course, @philarcher and I should ensure that GS1 also publishes the formal ABNF grammar rules for GS1 Digital Link URI Syntax standard as standalone machine-readable files, rather than relying on the goodwill of open source developers to extract those from a PDF document! We're also looking into ways to automate the generation of the ABNF grammar rules from the data in the GS1 Authoritative Table of Application Identifiers (ATA) dataset (see below for further info about that)

However, syntax validation can go even beyond the ABNF grammar and make use of tools such as the GS1 Barcode Syntax Resource (BSR) to check that the value of each GS1 Application Identifier is valid and that mandatory associations of GS1 Application Identifiers are observed, as well as no invalid pairings of GS1 Application Identifiers are present within the same element string or GS1 Digital Link URI.

The GS1 BSR Dictionary is provided in a very compact text format that is optimised for file size for use within embedded devices such as barcode printers and scanners. Within the GS1 BSR Dictionary are references to a number of GS1 Barcode Syntax Tests (linters) that perform specialised syntax validation checks, including checking that the GS1 Check Digit or GS1 Check Characters are calculated correctly for the value of that GS1 Application Identifier or one of the components within its value.

Much of the information in GS1 BSR Dictionary is also provided as a JSON-LD dataset in the new GS1 Authoritative Table of Application Identifiers (ATA) dataset, which is used to drive the new browser tool for GS1 Application Identifiers

I hope that the information above provides some useful pointers to existing notes in the GS1 standards about validation checks that can be done to test whether a Web URI is plausibly a GS1 Digital Link URI with valid syntax and that the information about /.well-known/gs1resolver provides a way to check whether a URI is intended to be a GS1 Digital Link URI that also resolves to some online information or services, even if the Resolver Description File does not currently indicate if any online master data is likely to be present for URIs sharing the customURIstem indicated by the resolverRoot field. Maybe we can extend the Resolver Description File to support that. We already have a dedicated link type for requesting master data (gs1:masterData) that can be expressed in the URI query string when making a Web request, though there is currently no requirement that the master data must be Linked Data. Hopefully many of these tests could be performed by crawlers on a periodic basis and the results or verdict cached in between periodic checks but I'm sure you and your colleagues know better than I do about the scalability concerns and computational costs and whether a simple assertion in schema.org is a simpler approach to meet the most urgent needs of crawlers.

We do encourage the use of the GS1 Web Vocabulary for making master data available on-demand at any granularity of identification (GTIN, GTIN+Lot/Batch, GTIN+Serial etc.) but probably need to make a stronger effort to communicate that message across the community about how GS1 Digital Link URIs and schema.org and the GS1 Web Vocabulary can work together. Many years ago I even developed this GS1 Web Markup Tool to help users make that connection and gain familiarity with using the GS1 Web Vocabulary and schema.org. It clearly needs some modernisation and an update, now that the GS1 Web Vocabulary has expanded to also add many useful relationships between and within the Organization and Place classes but hopefully this kind of tool (in a modernised version) can also be helpful to support efforts on Digital Product Passports to ensure that DPP data can be exchanged in a machine-interpretable format. In turn, such initiatives may help to promote the provision of more detailed master data on the Web as publicly available Linked Data.

Thanks for continuing the discussion,

Mark

@MatthiasWiesmann
Copy link
Contributor Author

MatthiasWiesmann commented Mar 11, 2024 via email

@Tiggerito
Copy link

Is this conversation about how GS1 implementers write structured data or how the average Joe connects to it from their website? If the former, ignore me.

I'll approach this from the perspective of a website owner who sells products. CMSs or plugins would already have established how the product's structured data is built, including the @id system they use.

Common best practice is to set the @id to the product page's canonical URL plus a fragment to identify which entity on the page it represents. In shorthand, it often looks like this:

"@id": "#product",

This @id system is often used to link to the product from intra-page entities (e.g. Review) and inter-page entities (e.g. Product Carousel).

GS1 using the digital link for their @id makes sense. But usurping the @id used by others will cause them unnecessary problems to solve.

Would this also mean that every website that sells a specific product is sharing one massive entity due to the common @id? I think it would make sense for a website to say; this is my product with my @id; you can find out more about it via this digital link. It's shared common data about the product (can we still say master data?).

I also agree that having a dedicated property would make it easier for crawlers or verifiers to deal with it correctly — like how we have Organization.iso6523Code, which Google already supports.

@mgh128
Copy link

mgh128 commented Mar 12, 2024

Hi Tony / @Tiggerito

Historically, you would have been correct about many content management systems generating their own IDs and using a hash fragment identifier.

There is certainly no intent to disrupt or cause any problems for anyone who is happy to continue using a URI with a hash fragment identifier to point to a specific product appearing in an online catalog or product page or the corresponding facts asserted about that.

However, manufacturers are already making preparations to move to 2D barcodes, typically encoding GS1 Digital Link URIs. See for example https://www.gs1us.org/industries-and-insights/by-topic/sunrise-2027 , https://www.thepackagingobserver.com/from-upc-to-gs1-digital-link-the-future-of-barcodes-with-gs1s-sunrise-2027/ and other articles.

Much of this is motivated by a desire to identify product instances (products as individual tangible objects) at finer granularity than using the current GTIN / UPC alone, such as including a batch/lot identifier or a serial number/identifier. Another major motivation is to improve online interaction with consumers, to strengthen brand loyalty, provide useful/convenient information and services, including warranty registration, access to instruction manuals etc. Of course some brand owners will also be considering opportunities for promotions, cross-selling of accessories etc., depending on the type of product.

So all of that is coming to a store and a product near you soon. You can already find some products with QR Codes or Data Matrix symbols encoding GS1 Digital Link URIs and that number is expected to increase significantly by 2027.

If your customer is already interacting with your online catalogue or product information page, that's fine for what it does and the discussion in this thread so far represents no threat to that whatsoever.

GS1 Digital Link URIs provide an additional way to connect the physical product you hold in your hand to online information and services, typically by scanning a 2D barcode (often a QR Code) with a smartphone, while that same 2D barcode goes beep at the checkout and still provides the Global Trade Item Number (GTIN) or Universal Product Code (UPC) to the checkout system, so that the correct price can be charged.
[ Note that every UPC can be treated as a 12-digit GTIN ; the GS1 global GTIN system uses 14 digits to identify a product class, so a 12-digit UPC is simply prefixed with '00' to construct the equivalent GTIN as 14 digits. Likewise, the 13-digit numbers appearing on product barcodes today are prefixed with '0' to construct the equivalent GTIN as 14 digits. ]

You probably won't achieve the same effect in open supply chains and retail stores if you just encode within a QR code the URL of your product catalog page with a hash identifier to a specific product, because for consumer goods, the GTIN / UPC still plays such a major role in looks of price, product category, checking whether a product has customer age restrictions for purchasing etc.

I suspect that it's very unlikely that the point of sale system of any major retailer will try to do a real-time Web lookup of a Web URI in general and try to determine price from some Linked Data appearing in a product catalogue page. They currently rely on rapid access to the GTIN / UPC and if they can extract that directly from the URI structure (e.g. 14 digits appearing after /01/ in the URI path information) and the structure is syntactically valid, they those retail systems can use that even without a Web lookup, though their retail Point of Sale systems may well do an in-store Local Area Network (LAN) lookup to check the current price and promotion info from the retailer's own IT system (if it's not already cached locally in the retail POS system) and to check that this GTIN / UPC is within the retail store's inventory and a product that they are allowed to sell.
GS1 Digital Link URIs are also able to encode an expiration date, to ensure that expired products cannot be sold. Many retailers use dynamic pricing to offer significant discounts for products that are nearing their sell-by date or expiration date. Instead of retail staff needing to manually apply additional stickers with special barcodes for the discounted prices, the retail systems will be able to perform those discounts automatically if the GS1 Digital Link URI encoded in the 2D barcode includes the sell-by date or expiration date. While browsing in store or when the consumer takes their product home, they will be able to scan that same 2D barcode with their phone and access various kinds of information. This page at https://www.gs1.org/voc/?show=linktypes gives you an idea of some of the possibilities. Don't expect recipe info when you scan the 2D barcode on a pair of socks!

Obviously these depend on the type of product and may also depend on the type of smartphone app you're using. Apps to help people suffering from allergies will be able to access facts about allergens in the ingredients and raise an alert if the product contains an allergen that might be harmful, depending on what the consumer has already configured in their app, depending on their allergies and dietary intolerances. This could help blind or partially sighted people (or tourists travelling in countries where they don't read or speak the local language appearing on the product packaging and the alert could be an audible beep / ding (OK) vs a buzz (not OK), a big green tick vs a red cross or whatever is most appropriate to alert the consumer.

Not sure why you perceive it as any form of 'usurping' of @id. I was pointing out that GS1 Digital Link URIs (as Web URIs having GS1 identifiers within their URI path information) can be used (like any other Web URIs) to write factual claims in Linked Data, as well as to retrieve information and services, e.g. by scanning a QR Code that encodes such a GS1 Digital Link URI.

@id is a JSON-LD keyword defined in the W3C JSON-LD technical recommendation.
Open technical standards exist to be used widely. If you view that as 'usurping' a feature defined in an open technical standard, then you are of course entitled to your view. I was not proposing any inappropriate misuse of @id as it is defined in the JSON-LD standard.

@id can be used to indicate that a string value should be treated as a IRI / URI - see https://www.w3.org/TR/json-ld11/#example-3-sample-json-ld-document-using-full-iris-instead-of-terms.

@id can also be used within a { } JSON/JSON-LD object to indicate which IRI / URI value is considered to be the RDF Subject, such that other property : value pairs within the same object, at the same hierarchical level as the "@id" : are considered to express properties and values about the thing identified by the URI appearing after "@id" : - see https://www.w3.org/TR/json-ld11/#node-identifiers

P.S. I hope this helps. If you already knew some or all of this, I didn't intend to offend you. I don't think we've met and I don't know your background. I try to write replies or comments in a way that can be helpful for anyone reading the thread now or in the future, in the hope that it provides some useful info for them too, whatever their existing level of background knowledge.

@Tiggerito
Copy link

There is a lot to take in. My knowledge is limited, as it is based on a video of the recent conference. I do think GS1 adds some great stuff, and I am keen to learn how it relates to online stores.

By usurp, I was talking about the @ids used by online store owners. I was getting the feeling that saying the @id is used to define the Digital Link means they can no longer use their own id system. If they can use their own id system, how would they indicate that their product relates to a Digital Link?

Can store owners create Digital Links specific to their own version of the product? For example, can they create a link that inherits all the GS1 manufacturer information about the product but is also connected to their store, product URL, prices, variants on offer, stock, shipping, returns policy, etc.? This is stuff that they can currently add as structured data on the product page.

@mgh128
Copy link

mgh128 commented Mar 12, 2024

Hi Tony

One Web URI can be redirected to any other Web URI or URL. Popular webservers such as Apache, IIS, nginx etc. support URL rewriting rules so that you can configure redirections for any URLs based on domain names you have registered.

A GS1 Digital Link URI can also be redirected to another Web URI or URL, such as the URL of a product information page. You might like to read about GS1-Conformant Resolvers. Essentially they're doing that kind of redirection in a very structured way, depending on the values of the GS1 identifiers (such as GTIN, Batch/Lot identifier, Serial Number etc.) within the structured URI path information of a GS1 Digital Link URI, as well as the specific value of link type that was specified via the URI query string at the time of making a Web request. GS1 operates GS1-Conformant resolvers at a global level and also through some of the national GS1 member organisations. Brand owners can also operate their own resolvers. Retailers can also do so, not only for their own-brand / white-label products but potentially also to support their in-store scanning terminals or the retailer's mobile app on consumer smartphones. GS1 also freely offers an open source community edition closely aligned to its operational resolver that anyone can install themselves.

The GS1-conformant resolver operated by GS1 Global Office also acts as a 'resolver of last resort' so that even if the 2D barcode didn't include a domain name - e.g. just encoded GS1 element strings, this special resolver might still be able to redirect to relevant information and services. This resolver has a policy of allowing the licensee of the respective GS1 identifier (typically the brand owner or manufacturer of a product) to configure how they would like to do the various redirections, depending on the link type selected and whether the redirection should be for all products with that GTIN/UPC or only for those with that GTIN and a specific Batch/Lot identifier or that GTIN and a Consumer Product Variant identifier or that GTIN and a specific Serial Number. I think most of the GS1-conformant resolvers operated by national GS1 member organisations will align with the same policy but retailers and brand owners and anyone else operating a resolver can set their own policies about who they allow to configure redirections (linkset data) within their own resolvers.

A brand owner will often configure a default link (the default redirection in situations where someone just scans the 2D barcode and doesn't use a specialised app that selects a specific link type). Often that default link will be to a product information page, such as might appear in an online product catalogue.

So suppose your brand is 'Dal Giardino' and you encode this GS1 Digital Link URI in a QR Code: https://dalgiardino.com/01/09506000134369

You'll get a QR Code such as this (OK, hopefully not quite as big as this ;-) ):

QR-https___dalgiardino_com_01_09506000134369_ec_M

Someone scans that and in this case, the brand owner, dalgiardino.com has configured the resolver that they operate at dalgiardino.com to rewrite https://dalgiardino.com/01/09506000134369 into https://dalgiardino.com/extra-virgin-olive-oil/ but it would also have worked if instead of a clean human-friendly URL, the target URL to redirect to looked more like https://example.com/products#237 or https://example.com/products/237 . That's all doable. Everything you have currently configured for something like https://example.com/products#237 or https://example.com/products/237 continues to work.

Effectively, the GS1 Digital Link URI just provides an additional entry mechanism to the same product page, typically triggered by a person scanning a 2D barcode.
Currently the customer might have found the online product page via a Web search engine, looking for specific keywords.
Or a social media post or advert might have linked to it. Now there's a further way to be taken to that same product page.

When GS1 Digital Link URIs are encoded in 2D barcodes and a person scans it with their phone, that GS1 Digital Link URI can be redirected to the existing online product information page about that specific product, at its existing URL - and resolvers help to make that redirection happen and also to keep it flexible and reconfigurable for brand owners etc., so that if the brand owner later changes their content management system or overhauls their website URLs, resolvers can be easily configured to still ensure that when someone scans the unchanged 2D barcode, they're still redirected to the product information page (or other information and services requested via the link type) at their new / current URLs, even if those change over time.

I mentioned that retailers might operate their own resolvers - e.g. to support portable in-store self-scan devices or their mobile apps. You're correct that they might want to blend the authoritative static data from the brand owner / manufacturer with their own information about pricing, promotions, availability of spare parts and consumables etc. One way that could work is that when a retailer's app or portable in-store self-scan device (portable scanner with a display) scans the 2D barcode that encodes the GS1 Digital Link URI created by the brand owner, the retailer's device or app could strip off the retailer's domain name and everything before the /01/ that indicates the product GTIN, then simply append the remaining /01/ plus GTIN etc. to a URI stem based on their own domain name and the retailer configures their own resolver to redirect to their existing retailer-specific product information pages, including their information about pricing.

One of the really good things about GS1 Digital Link URIs is that they have this well-defined structure for GS1 identifiers in a way that lets you do this trick of splicing the URL and effectively taking the structured part created by the brand owner but appending it to your own domain name, where you can control what it redirects to. Furthermore, back to the @id discussion, if you're a retailer, you could create a URL / Web URI such as https://tonysdeli.example/01/09506000134369 that corresponds to a schema:Offer for that product, so a minimal block of JSON-LD could look like this:

{
    "@context": {
        "schema": "https://schema.org/"
    },
    "@id": "https://tonysdeli.example/01/09506000134369",
    "@type": "schema:Offer",
    "schema:priceSpecification": {
        "schema:priceCurrency": "USD",
        "schema:price": 19.95
    },
    "schema:itemOffered": {
        "@id": "https://dalgiardino.com/01/09506000134369",
        "@type": "schema:Product",
        "schema:name": "Dal Giardino Extra Virgin Olive Oil Exclusive Selection 1L"
    }
}

This enables the retailer to use the same structured part of the GS1 Digital Link URI (e.g. /01/09506000134369 ) as the RDF Subject of its schema:Offer information about price, promotions etc. while that schema:Offer refers via schema:itemOffered to the product that has the same structured part (/01/09506000134369 in this example).

Now of course you could have done all that using https://tonysdeli.example/products#237 instead of https://tonysdeli.example/01/09506000134369 but I hope that you can see that if your retailer / deli has its own mobile app, this approach makes it much easier for that app to 'partially hijack' the GS1 Digital Link URIs that were already encoded by the brand owner in the 2D barcode, so that when the customer walks into your deli and uses your retailer app to scan the 2D barcode, they can see info about price, promotions etc. easily blended with data from the brand owner or manufacturer.

That's probably enough detail for now - but the bottom line is that you can think of GS1 Digital Link URIs as enabling a new world of 'physical hyperlinks' from real-world product instances and other objects, locations, assets etc. to a variety of relevant related online information and services, all through a scan of a smartphone app - and GS1 Digital Link URIs can just be a new form of inward link to your existing product page if you can use the 'partial hijack' trick outlined above via a domain name and app or self-scan device that you as retailer control and can configure as you wish.

@philarcher
Copy link

Sorry for being slow to join the discussion, here's some input from me.

In our Global Migration to 2D programme, I spend a lot of time urging anyone who'll listen that the GS1 Digital Link URI should not be the URL of any Web page. That is, however you do it, you should redirect from the DL-URI to wherever you're heading. See the relevant best practice 3 in our Best Practices Guide. This is not just the interminable HTTP Range-14 argument (although that's sort of in the background). It's because GTINs are managed according to a set of defined rules and Web pages will always be managed according to whatever marketing requires. They're different and need to be managed differently.

Using a resolver is one option. It's a way to operationalize redirection from one ID to multiple sources of related info. But it's not the only one and we shouldn't plan here for it to be the one and only expected behaviour. The presence/absence of a ./well-known/gs1resolver is useful if you want to start throwing queries at it for specific types of info but that's all. (Incidentally, this concept is also included in ISO/IEC DIS 18975)

Whether or not a resolver is used, redirection should be the norm. This is of direct relevance here in that no Web page's URL is the ID of a product class or instance. But it might well be the subject of a block of markup. Therefore, in the context of schema.org I can see @MatthiasWiesmann's argument for a separate property for a DL URI. But, of course, @mgh128 is also correct that a design principle for GS1 Digital Link is that those URIs can be the subject of a graph. Furthermore, it's possible to infer relatively rich semantics from a DL URI. I know, I know, URIs are dumb strings - except that Linked Data is just one activity that drives a coach and horses through that!

@Tiggerito
Copy link

That all makes sense.

I imagine as a first step is that an online store (say store.com) would want to indicate where more information about a product can be found. Like, say, information from the brand or manufacturer. The standardised URL structure would make that easier. e.g. the store's structured data could somehow reference:

https://brand.com/01/09506000134369
https://manufacturer.com/01/09506000134369

If later, the store wanted to integrate more with GS1, it would then provide its own standardised URL:

https://store.com/01/09506000134369

All of these URLs may redirect to non-standard URLs.

So how would the store's product detail page reference the related Digitial Links? The @id could only be used to reference its own Digital Link.

I think @MatthiasWiesmann and Google would be interested in the related Digital Links to learn more about a product sold by a store.

Does GS1 come with a central location that can be quizzed. e.g. what is the manufacturer's Digital link for /01/09506000134369

@philarcher
Copy link

Does GS1 come with a central location that can be quizzed. e.g. what is the manufacturer's Digital link for /01/09506000134369

Yes and no. We operate a resolver at id.gs1.org so that, in this example you'll find https://id.gs1.org/01/09506000134369 works and redirects to the target. If you want the list of all available links you can go to https://id.gs1.org/01/09506000134369?linkType=all, the source code for which includes the linkset as per RFC9264 (set your accept header to application/linkset+json to get the pure JSON, in which case the linkType param is not needed).

That's the 'yes' part.

The 'no' part is that the number of links in the resolver today is so close to zero as to be of not much use. There's a whole programme of adding links to the system and all the rest of it but that's in its infancy. What's also of relevance is that we will, very happily, redirect to other resolvers. For example, all GTINs beginning with 76 get redirected to a resolver service operated by GS1 Switzerland. 40 redirects to Germany and so on. We also redirect a bunch of prefixes to a brand owner's own resolver. So the vision is for a network of resolvers, but id.gs1.org is the place you go if you don't have a better option to start with.

If this sort of thing is of interest @Tiggerito, we can have a chat offline.

@Tiggerito
Copy link

That sounds like a great potential. With a GTIN, it could be possible to obtain information from multiple sources.

It's 11pm here (Adelaide, Australia), so time to sleep on all this.

My main interest is how it can add value to online stores, such as by indicating to crawlers like Google if there are Digital Links for a product. I guess the manufacturers need to build the Digital Links before the suppliers can reference them. By then, how it all will work will be clearer.

@jvandriel
Copy link

jvandriel commented Mar 12, 2024 •
edited

If you don't mind, let me play the devil's advocate for a moment and sketch a very common and everyday scenario for many of the webshops out there - one that is extremely messy (for an enormous percentile of the shops out there)...

Nowadays, the average shop rolls out either a WooCommerce or Shopify website. CMS systems that do not allow one to properly define product variants because out-of-the-box these platforms do not come with sufficient product attributes to facilitate this.

And so those shops will need a bunch of custom programming work to get this done, or - in most cases - install some plugins to help them resolve this; plugins that don't exist yet, and the ones that do handle some of it, aren't able to provide all that is needed - because the CMS systems they operate on don't offer the required functionality and/or database fields.

Now those same shops often also make use of plugins (like Yoast), which handle some of the structured data markup (often not all of it), while also handling redirects. Redirect features that need to be built to be able to handle URIs like @Tiggerito illustrated. Although, this is a very hopeful scenario as many sites run all kinds of separate plugins, none of which communicate with any of the other plugins, all doing their own thing in isolation from each other.

Now I could go on for hours about how the reality of the-average-webshop vs that of standards do not align, and likely never will because the CMS systems they've been built on do not offer the means to do so - because they have been built with the idea of creating 'simple' shops for the everyday person - and not full-blown, commerce standards following, ERP/PIM/CMS/etc systems - which even many well-educated people struggle to deal with.

All this to say that I believe that if we don't come up with a simple property (like isGS1DigitalLink), for which the average shop can simply provide a URL (schema.org's context can handle the rest and help it be a URI) we won't see any adoption by any of the average-webshops out there.

Sorry if it sounds harsh, but if - in its simplest form - we don't make this idiot-proof - I don't believe we'll get very far.

It's awesome that big e-commerce players and manufacturers can do very cool stuff with this, but the average website needs a less ambitious solution (for starters).

@mgh128
Copy link

mgh128 commented Mar 12, 2024

Hi Jarno,

Thanks for chiming in. I agree with those concerns.
If a simple property is helpful. I'd actually suggest hasGS1DigitalLink rather than isGS1DigitalLink if it points to a GS1 Digital Link URI rather than expecting a true/false boolean value.

If I understand it correctly, hasGS1DigitalLink could be used to connect existing Linked Data markup using a potentially CMS-generated URL to one or more known GS1 Digital Link URIs that the webshop owner may have discovered by scanning QR Codes on the products in their inventory.

If that's what @MatthiasWiesmann is asking for, your post has helped me understand his perspective better. Thank you!

Regarding the gs1:gtin / schema:gtin property, I expect that even when GS1 Digital Link URIs in 2D barcodes really take off around 2027, those properties should still be populated. The GTIN doesn't go away - it just becomes more widely available within a structured Web URI syntax (GS1 Digital Link URIs) rather than being a dumb 14-digit string that links to nothing, even if it's still useful for correlating data from multiple sources.

@MatthiasWiesmann
Copy link
Contributor Author

MatthiasWiesmann commented Mar 12, 2024 via email

@mfhepp
Copy link
Contributor

mfhepp commented Mar 12, 2024 •
edited

Just for widening the space of options considered: What about defining and registering a URI scheme prefix for GS1 digital links, like gs1: - this would allow using GS1 digital link URIs in many different places; it would all be valid URIs; the client could decide what to do with it etc.

One could even allow (maybe with some escaping, but afair you would have control over the value space after the prefix) https URIs as the content, like so

gs1:https://id.acme.org/9780596510049/other/stuff

@MatthiasWiesmann
Copy link
Contributor Author

MatthiasWiesmann commented Mar 12, 2024 via email

@philarcher
Copy link

The design criteria for GS1 Digital Link are:

  1. It carries GS1 identifiers in a syntax that can be parsed and used by scanners without needing to make any online lookup.
  2. It is a URL that can be used by any existing Web client.
    We discussed but, for those reasons, decided against creating a new URI scheme.

Btw @mfhepp, you can add anything you like before the /01/ (or whatever the primary key's application identifier is) but not at the end of the paths. However, you can add anything you like to the query string (as long as the names aren't all numeric). So your example can be https://examole.com/any/other/stuff/01/09780596510049/21/ABC123 (serial number ABC123 of GTIN 09780596510049).

@MatthiasWiesmann - you could say has18975 if you prefer. But can we wait until it's completed its journey through ISO (prob Jan 2025). Also, it's only a framework. So GS1 Digital Link is conformant to ISO/IEC 18975 but you'd have to code for an arbitrary number of other schemes that might also be conformant to it.

@MatthiasWiesmann
Copy link
Contributor Author

MatthiasWiesmann commented Mar 12, 2024 via email

@philarcher
Copy link

Is there any plan to add a logo into the digital link QR-code to help identify them?

THIRD RAIL ALERT!!!

This is a very sensitive subject at GS1 with a lot of strong opinions. Forgive me, but the topic is being dealt with way above my pay grade.

@mgh128
Copy link

mgh128 commented Mar 12, 2024

Discussions are happening about some kind of logo for consumer-recognition purposes. We can't comment until GS1 announces what that group has been working on - I'm not directly involved. I don't know whether the logo would be inside the QR Code or outside. My preference would be that it's outside because I'm concerned that putting it inside will require a higher level of error correction to compensate for the area obscured / 'damaged' by any internal logo.

@Tiggerito
Copy link

Would the brand/merchant want the opportunity to have their logo on QR codes on their products? But then it does make sense to tell people that this is the fancy GS1 QR code.

Is the hasGS1DigitalLink about defining that this entity provides information about a specific Digital Link? i.e. removing the need for the @id to be the digital link? Would gs1DigitalLink be more consistent? To me, 'has' and 'is' are both boolean.

In my scenario, I'm thinking of sites that have yet to generate their own Digital Links but want to indicate that their structured data relates to existing Digital Links. Or is that not required if they specify a GTIN?

Would it help if they specified an array of relatedGS1DigitalLink listing the links they know of, such as the manufacturer, brand, or, ideally, the id.gs1.com link?

@ziodave
Copy link

ziodave commented Mar 13, 2024

Generally speaking I would be in favor of using GS1's Digital Link as @id but I have the some concerns.

Some principles about entity @id are:

  1. An entity @id should ensure uniqueness: an IRI should uniquely identify a specific entity within the Linked Data ecosystem. This avoids confusion and ensures data can be accurately linked and queried
  2. Multiple IRIs can lead to confusion and make it harder to definitively identify the intended entity.

The definition of GS1 Digital Link is:

GS1 Digital Link provides a syntax for expressing GS1 identifier keys, key qualifiers and data
attributes in a format that can be used on the Web in an intuitive manner (via a straightforward
HTTP request) to enable consumers and others to directly access relevant information and services
about products, assets, locations, etc

That is, its role is not confined to expressing one ID, but to express many as well as other attributes. So that a GS1 Digital Link about the same product may assume different forms according to what information are conveyed within (from the specs, these are GS1 Digital Link for the same product):

/01/09520123456788/22/2A/10/ABC123/21/12345XYZ
/01/09520123456788/10/ABC123/
/01/09520123456788/10/ABC123/21/12345XYZ
/01/09520123456788/21/12345XYZ

Which one should be used as @id ?

Moreover the GS1 Digital Link may include additional attributes like pricing (correct me if I misunderstood) that may change with time, which goes against the Linked Data ID principles that the ID should be permanent.

It seems that these concerns are shared in the specs when introducing the GS1 Canonical Link "[...] in some contexts (e.g., to support carriers that cannot embed a Web URI) it is necessary to identify a single well-known or default version of the GS1 Digital Link URI". However such canonical URI must point to id.gs1.org per definition "[...] the domain name SHALL be id.gs1.org" which defies the purpose stated before "to ensure brands can remain in control of the domains they use".

In short, as much as I would love to use GS1 Digital Link as @id, I think that it should be defined what such URI should look like when used as an @id, addressing the initial concerns, similarly to what has been defined for the GS1 Canonical Link, but allowing the use of a 3rd party domain (and possibly allowing for a dataset name after the domain which is a common practice, this has been already address by @philarcher at #3475 (comment)).

Until then I think using the schema:identifier property along with the regular expressions defined in "Recognising a GS1 Digital Link URI" is the best choice or, if we think that the regex may match things that are not GS1 Digital Links, probably hasGS1DigitalLink with the value of the GS1 Digital Link(s) would be the best choice.

Reference: https://ref.gs1.org/standards/digital-link/uri-syntax/

@mgh128
Copy link

mgh128 commented Mar 13, 2024

Hi David / @ziodave

You asked:

/01/09520123456788/22/2A/10/ABC123/21/12345XYZ
/01/09520123456788/10/ABC123
/01/09520123456788/10/ABC123/21/12345XYZ
/01/09520123456788/21/12345XYZ

Which one should be used as @id ? It depends what you're using it for and at what level of identification granularity the facts apply.

The first specifies a Product GTIN of 09520123456788, a Consumer Product Variant of '2A', a Batch/Lot identifier of 'ABC123' and a Serial Number '12345XYZ'.

The combination of GTIN + Serial Number should always identify at most one physical instance globally. So, the fourth option is actually sufficient to uniquely identify that individual product instance.

The second option only identifies the Product GTIN + Batch/Lot Identifier, which is useful for some purposes, although GTIN + Serial Number is far more useful for fine-grained traceability.

If you are writing facts / RDF triples that apply to every instance of that product GTIN, you'd use something like

/01/09520123456788

If you are writing facts / RDF triples that apply only to every instance of that product GTIN and a specific batch/lot, you'd use something like

/01/09520123456788/10/ABC123

If you are writing facts / RDF triples that apply only to one specific unique instance of that product GTIN and a specific serial number, you'd use something like:

/01/09520123456788/21/12345XYZ

Regarding pricing and other data attributes that may appear in the URI query string, GS1 Digital Link URIs are designed to put only the identifier in the URI path information and any data attributes in the URI query string, so that when you are writing Linked Data you can simply drop the query string entirely and still be identifying the product / product variant / product batch / product instance. The ability to encode data attributes in the URI query string is primarily so that they can be encoded in a 2D barcode (e.g. QR Code) as part of a GS1 Digital Link URI and so that some applications that need to extract such data attributes can do so by offline extraction from the URI query string parameters without needing to do a Web request for that GS1 Digital Link URI. Currently, such data attributes are supported in (non-Web URI) element strings within 2D barcodes such as GS1 DataMatrix, so it's important that this capability is not lost for those users when migrating to GS1 Digital Link URI, typically in a QR Code. However, when writing Linked Data using GS1 Digital Link URIs, please just drop the URI query string entirely.

Regarding canonical URIs, these are very much the exception rather than the rule and we would typically expect and prefer that brand owners use GS1 Digital Link URIs constructed using their own domain name, as stated in section 4.12 of https://ref.gs1.org/standards/digital-link/uri-syntax/ :

A GS1 Digital Link URI can be constructed in any domain name, may contain additional key=value
pairs in the query string and so on. This flexibility is a deliberate feature of the standard to support
its use in as many scenarios as possible and to ensure brands can remain in control of the domains
they use.  

However, in some contexts (e.g., to support carriers that cannot embed a Web URI) it is necessary
to identify a single well-known or default version of the GS1 Digital Link URI. This is defined in [RFC
6596] as the canonical URI.

So for example, if you encounter a GS1 DataMatrix code, it encodes an element string consisting of a set of GS1 Application Identifiers and their values. Typically, this provides no indication of the corresponding domain name of the brand owner - the encoded data are just 2-4 digit GS1 AI keys and some values.

A canonical URI can be thought of as a 'GS1 Digital Link URI' of last resort - one that can be constructed when you don't even know what the URI stem should be. That's why GS1 offers https://id.gs1.org/ as a URI stem to construct such canonical URIs and also provides and operates a GS1-Conformant Resolver at that hostname, so that if GS1 holds information from the respective licensee / brand owner, anyone can still construct at least the canonical GS1 Digital Link URI using https://id.gs1.org/ as the URI stem then make a Web request for that. The GS1 resolver at id.gs1.org can therefore be considered to be a resolver of last resort that particularly supports a forward migration from element strings to GS1 Digital Link URIs and from non-WebURI-encoded 2D barcodes such as GS1 DataMatrix to WebURI-encoded barcodes such as QR Codes.

However, most brand owners are encouraged to use their own domain names to construct their GS1 Digital Link URIs and to perform their own internal redirection accordingly - or operate their own resolver. GS1 offers a free open source community edition of its resolver at https://github.com/gs1/GS1_DigitalLink_Resolver_CE

@VladimirAlexiev
Copy link

Hi folks!
This discussion is TL;DR for me today, so I want to point out just a couple of things:

The GS1 resolver at id.gs1.org can therefore be considered to be a resolver of last resort

But Mark, when a reader sees a QR code, how would it know which company namespace to prepend?

  • IMHO the GS1 resolver should keep an authoritative resolver from GS1 company prefix to company namespace.
  • Whereas company infrastructure should resolve AIs to concrete pages within that namespace.

The table EPCIS classes, props, mapping of TDS identifiers maps between GS1 identifiers and gs1: classes (eg gs1:IndividualProduct) and props needed for that identifier (eg gs1:gtin, gs1:hasSerialNumber for SGTIN).

  • The classes were proposed as part of the EPCIS 2.0 ontology, but I don't think they were added to GS1 WebVoc (@mgh128 , @philarcher ?)
  • I see above s:IndividualProduct: yes, it's better if GS1 WebVoc directly reuses Schema classes/props rather than declaring equivalences

@philarcher
Copy link

  • IMHO the GS1 resolver should keep an authoritative resolver from GS1 company prefix to company namespace.

That's something I hope we will indeed do @VladimirAlexiev. That is, publish the redirect table so that, for example, you would know without asking that everything beginning 76* will be redirected to id.gs1.ch and everything beginning 8888049 will redirect to elabel.jnj.com. But note that we do promote the idea that brands should use their own domain name in their DL URIs. That may redirect to a resolver (which might be ours) or something else that isn't a resolver.

@mgh128
Copy link

mgh128 commented Mar 14, 2024

Hi @VladimirAlexiev

Thanks for joining the discussion.

Regarding your first remark, "IMHO the DL URL should not be the subject @id because there can be any number of DL URLs that mean exactly the same thing.", are you talking about the GS1 Digital Link URI or the target URL to which it redirects?

I would argue that they are not actually 'exactly the same thing' and that there is value in a GS1 Digital Link URI appearing in Linked Data directly, as the subject or object of triples, where appropriate, so that the brand owner/manufacturer can make their authoritative factual claims about their product, while a retailer selling their product can make its own factual claims about their retail offer for that product, including pricing, availability, promotions etc., which are specific to that retailer and should not be merged automatically with factual claims created by a competing retailer selling the same product, for which pricing, promotions and availability may clearly be different and unsuitable for merging..

I can also envisage situations where one block of JSON-LD could include details about the schema:Offer specified by the retailer, possibly using a GS1 Digital Link URI created using the retailer's domain name and /01/ followed by the GTIN (in 14 digits) of the Product involved in that Offer, while the same data block also includes (via the schema:itemOffered property) a set of factual claims created by the brand owner or manufacturer - and I think it would be perfectly reasonable for the brand owner or manufacturer to create a GS1 Digital Link URI using their domain name and /01/ followed by the GTIN (in 14 digits) of the product and to use it as the subject of its authoritative triples that express factual claims about the product itself.

The fact that both https://brandowner.example/01/09520123456788 and https://retailer.example/01/0952012345678 share some common URI path information and even a common canonical GS1 Digital Link URI at https://id.gs1.org/01/0952012345678 does not imply any kind of owl:sameAs relationship between these - so no automatic merging of triples. What can be said is that both or all three conform to GS1 Digital Link URI Syntax and all three share the same GTIN, which suggests that they are all concerned with the same product or service identified by those 14 digits - but not that the GS1 Digital Link URIs are identical or that the corresponding RDF triples can be merged without much careful consideration.

@VladimirAlexiev you asked me "But Mark, when a reader sees a QR code, how would it know which company namespace to prepend?

Firstly, if the QR Code already encodes a URL or a GS1 Digital Link URI (which is always a Web URI containing a domain name) then what is the issue? We typically expect the brand owner to construct their GS1 Digital Link URIs using their own domain name and to handle whatever redirections they need to do internally, with or without using a resolver that they host.

You asked the question apparently in response to my statement "The GS1 resolver at id.gs1.org can therefore be considered to be a resolver of last resort", by which I meant (and explained with examples earlier in this thread at #3475 (comment) ) that there are many 2D barcodes in use today that use GS1 DataMatrix symbols in which element strings are encoded, but no indication of the corresponding domain name to use when constructing the corresponding GS1 Digital Link URI. In this situation, a canonical GS1 Digital Link URI can be constructed at id.gs1.org from such element strings and the GS1 'resolver of last resort' at id.gs1.org should be capable of redirecting those to whichever target URLs were configured by the licensee of the respective GTIN or GS1 Company Prefix, also considering which link types were specified in the URI query string by whoever made the Web request for such GS1 Digital Link URIs.

@VladimirAlexiev wrote:

  • IMHO the GS1 resolver should keep an authoritative resolver from GS1 company prefix (GCP) to company namespace.

On this point we almost agree in the sense that the GS1 resolver is considered to hold authoritative records that were configured by the respective licensee of the GTIN or any other licensed GS1 identification key or of the GS1 Company Prefix that was fully licensed by the licensee and used to create the GTIN.

If by company namespace you mean a mapping from a GCP to a domain name, that is supported by the gs1:handledBy link type in the linkset response, in situations where the brand owner / licensee would like all requests for all GS1 Digital Link URIs that were constructed using their GCP to be handled by a resolver at their domain name - see section 2.8 of https://ref.gs1.org/standards/resolver/ as well as conformance statement 26 in section 5 of the same standard.
However, GS1-Conformant Resolvers are not required or expected to support a bare GCP to domain name lookup without the query client specifying a valid GS1 Digital Link URI in full.
GS1-Conformant Resolvers also support the return of linkset data in response to a Web request for a specific GS1 Digital Link URI (and link types if a specific link type was specified in the Web request or if linkType=linkset was specified). An earlier version of the standard used linkType=all instead of linkType=linkset so this may still be supported for reasons of backward compatibility.

Regarding your perspective,
Whereas company infrastructure should resolve AIs to concrete pages within that namespace.

I think we're broadly aligned but I would still phrase it somwhat differently as follows, to allow for the distinct possibility that some target resources might be hosted outside of their registered domain name:

'whereas company infrastructure should resolve GS1 Digital Link URIs within their registered domain name to corresponding target resources (information and services) that they consider relevant, noting that these may be hosted using their own domain name or at external sites, an example of which would be a redirection to a relevant record within a centralised repository of electronic patient information leaflets for pharmaceuticals, where that centralised repository is managed by a government agency such as a department for health'.

Regarding the helpful table EPCIS classes, props, mapping of TDS identifiers, this is a useful input to work which is currently being reactivated on semantics of GS1 Application Identifiers, which @philarcher and I are picking up. @philarcher has a similar table and I have also prepared some recent notes on some of the challenges (fortunately not insurmountable) of mapping some of our GS1 Application Identifiers and their values to a semantic interpretation as Linked Data, using existing or future properties in the GS1 Web Vocabulary. So we need to merge these inputs and this still needs to go through the GS1 GSMP standards management process for review but will result in corresponding updates to the GS1 Web Vocabulary. We'll certainly keep you informed when that community review process starts and if you'd like to be more actively involved before then, please let @philarcher and me know. Thanks again for your previous input on this and for continuing to be involved in this discussion.

Hi David / @ziodave

You asked:

/01/09520123456788/22/2A/10/ABC123/21/12345XYZ /01/09520123456788/10/ABC123 /01/09520123456788/10/ABC123/21/12345XYZ /01/09520123456788/21/12345XYZ

Which one should be used as @id ? It depends what you're using it for and at what level of identification granularity the facts apply.

The first specifies a Product GTIN of 09520123456788, a Consumer Product Variant of '2A', a Batch/Lot identifier of 'ABC123' and a Serial Number '12345XYZ'.

The combination of GTIN + Serial Number should always identify at most one physical instance globally. So, the fourth option is actually sufficient to uniquely identify that individual product instance.

The second option only identifies the Product GTIN + Batch/Lot Identifier, which is useful for some purposes, although GTIN + Serial Number is far more useful for fine-grained traceability.

If you are writing facts / RDF triples that apply to every instance of that product GTIN, you'd use something like

/01/09520123456788

If you are writing facts / RDF triples that apply only to every instance of that product GTIN and a specific batch/lot, you'd use something like

/01/09520123456788/10/ABC123

If you are writing facts / RDF triples that apply only to one specific unique instance of that product GTIN and a specific serial number, you'd use something like:

/01/09520123456788/21/12345XYZ

Regarding pricing and other data attributes that may appear in the URI query string, GS1 Digital Link URIs are designed to put only the identifier in the URI path information and any data attributes in the URI query string, so that when you are writing Linked Data you can simply drop the query string entirely and still be identifying the product / product variant / product batch / product instance. The ability to encode data attributes in the URI query string is primarily so that they can be encoded in a 2D barcode (e.g. QR Code) as part of a GS1 Digital Link URI and so that some applications that need to extract such data attributes can do so by offline extraction from the URI query string parameters without needing to do a Web request for that GS1 Digital Link URI. Currently, such data attributes are supported in (non-Web URI) element strings within 2D barcodes such as GS1 DataMatrix, so it's important that this capability is not lost for those users when migrating to GS1 Digital Link URI, typically in a QR Code. However, when writing Linked Data using GS1 Digital Link URIs, please just drop the URI query string entirely.

Regarding canonical URIs, these are very much the exception rather than the rule and we would typically expect and prefer that brand owners use GS1 Digital Link URIs constructed using their own domain name, as stated in section 4.12 of https://ref.gs1.org/standards/digital-link/uri-syntax/ :

A GS1 Digital Link URI can be constructed in any domain name, may contain additional key=value
pairs in the query string and so on. This flexibility is a deliberate feature of the standard to support
its use in as many scenarios as possible and to ensure brands can remain in control of the domains
they use.  

However, in some contexts (e.g., to support carriers that cannot embed a Web URI) it is necessary
to identify a single well-known or default version of the GS1 Digital Link URI. This is defined in [RFC
6596] as the canonical URI.

So for example, if you encounter a GS1 DataMatrix code, it encodes an element string consisting of a set of GS1 Application Identifiers and their values. Typically, this provides no indication of the corresponding domain name of the brand owner - the encoded data are just 2-4 digit GS1 AI keys and some values.

A canonical URI can be thought of as a 'GS1 Digital Link URI' of last resort - one that can be constructed when you don't even know what the URI stem should be. That's why GS1 offers https://id.gs1.org/ as a URI stem to construct such canonical URIs and also provides and operates a GS1-Conformant Resolver at that hostname, so that if GS1 holds information from the respective licensee / brand owner, anyone can still construct at least the canonical GS1 Digital Link URI using https://id.gs1.org/ as the URI stem then make a Web request for that. The GS1 resolver at id.gs1.org can therefore be considered to be a resolver of last resort that particularly supports a forward migration from element strings to GS1 Digital Link URIs and from non-WebURI-encoded 2D barcodes such as GS1 DataMatrix to WebURI-encoded barcodes such as QR Codes.

However, most brand owners are encouraged to use their own domain names to construct their GS1 Digital Link URIs and to perform their own internal redirection accordingly - or operate their own resolver. GS1 offers a free open source community edition of its resolver at https://github.com/gs1/GS1_DigitalLink_Resolver_CE

@ziodave
Copy link

ziodave commented Mar 15, 2024

Hi Mark / @mgh128

The first specifies a Product GTIN of 09520123456788, a Consumer Product Variant of '2A', a Batch/Lot identifier of 'ABC123' and a Serial Number '12345XYZ'.

This makes sense. We've been using the gtin in the past for @id, e.g. https://data.example.org/dataset/0123456789. I'll look into expanding this to fully support the GS1 Digital Link.

@MatthiasWiesmann
Copy link
Contributor Author

I created a test instance with a proposal here: https://digitallink-dot-schemadotorg1.ew.r.appspot.com/Product

@philarcher
Copy link

Thanks @MatthiasWiesmann. Really good to see this. I think the domain could be extended. We have IDs for documents, assets, services ad service users (not people IDs as such but IDs of people who use a service). I'd say the domain could be any of Organization, Product, Place, Intangible, Creative Work, Medical Entity which, I acknowledge, is kinda close to just making it Thing.

The awkwardness you have described in the definition might be made easier by defining two properties. hasGS1DigitalLinkClass and hasGS1DigitalLinkInstance ? Instance identifiers - of which we have several - would take care of shipping units, documents, assets, returnable assets etc. It's really only GTINs that can be a class or instance identifier depending on the presence/absence of additional identifiers. GLNs are a bit more of a mess. They can be class or instance just depending on how they're used.

We can help with rules that state whether class or instance is appropriate.

@MatthiasWiesmann
Copy link
Contributor Author

MatthiasWiesmann commented Mar 18, 2024 via email

@mfhepp
Copy link
Contributor

mfhepp commented Mar 18, 2024

Problem

GS1's digital link (DL) is presented as the successor to the linear encoding of various identifiers like GTIN. Digital links are typically encoded in QR-codes printed on products or their packaging.

An example of a digital link is https://gs1.appareldemo.com/01/09506000164908/10/ABC123

The path contains the following AI (Application Idenfitiers)

  • 01 – GTIN 09506000164908
  • 10 – Lot number ABC123

The digital link solves some long standing issues with GTIN, in particular they allow to encode the Consumer Product Variants (CPV) field, which allows to distinguish products which share a GTIN, because they don't need to be distinguished in retail. Often they need to be distinguished in online commerce.

Technically, DLs could be represented in multiple ways:

  • Inside the [identifier](https://schema.org/identifier) field. Pros: no change needed. Cons, identifier is the grab-bag for identifiers, so this makes validation and reporting complicated.
  • Inside the url field. Pros: no change needed. Cons, url is pretty vague, agains this makes validation and reporting vague.
  • Inside a dedicated attribute like hasDigitalLink. Pros: role and parsing rules are clear . Cons, new attribute needed.

Level and AI culling

One problem that will require some documentation is the fact that different AIs are only applicable at certain levels.

  • A DL that contains a serial number (AI 21) should only be present on instances of IndividualProduct
  • A DL that contains a lot number (AI 10) could make sense at the product level (if the seller only sells products from that lot), but more probably it should be a the IndividualProduct level.
  • A DL that contains a global model number (AI 8013) or an NSN but no GTIN could be attached to a Product or a ProductModel.

Apologies that I don't have the time to dig into this fully right now, but a few pointers:

  1. There is https://schema.org/SomeProducts for similiar scenarios (it is gr:SomeItems in GoodRelations): The identity is not that of a singular product, but of a "bag of products" for which a certain set of characteristics hold. This could work well for product lots / batches or even for a larger sales unit.
  2. The motivation for this approach in the initial GoodRelations model was very similar: I wanted to keep the model (as a blueprint, abstract entity) distinct from the individual product, but also needed a way to implement this when the individidual products have no public identity and identifier (as typical in the sales of new products).

Some background is here: http://wiki.goodrelations-vocabulary.org/Documentation/Product_or_Service

See also Section "3.3.3 Anonymous Instances and Existential Quantification" in the original GoodRelations TR from 2008 (p. 29).

Maybe these are still useful 16 years later ;-).

@mgh128
Copy link

mgh128 commented Mar 18, 2024

Hi @MatthiasWiesmann , Thanks for preparing this and including an additional example 4.
Regarding that example, the GS1 Digital Link URI should not have a trailing slash - it should be
https://gs1.appareldemo.com/01/09506000164908 rather than https://gs1.appareldemo.com/01/09506000164908/

Section 4.12 of https://ref.gs1.org/standards/digital-link/uri-syntax/ includes the following statement regarding the trailing slash not being conformant:

Elsewhere in the GS1 Digital Link standards it is stated that a trailing slash, while not conformant, should be tolerated by resolvers. That is, a resolver should tolerate
https://example.com/8003/{grai}/ even though that final / character is not allowed by the
formal ABNF. A canonical GS1 Digital Link URI SHALL NOT include a trailing slash.

I agree with Phil that the rdfs:domain of schema:hasGS1DigitalLink should include schema:Product, schema:IndividualProduct , schema:Organization, schema:Place as well as documents, assets, logistic units etc. for which schema.org appears not to have corresponding classes defined. It therefore should probably appear as a property of schema:Thing and as such, the definition might need to be adjusted slightly.

Regarding Phil's point about GLN, a GLN is actually always an instance identifier - there is no GLN class.

https://example.com/414/9521141123454 is an instance identifier for a physical location (something of type schema:Place)
https://example.com/414/9521141123454/254/32a%2Fb is an instance identifier for a physical location, in which the GLN Extension (254) merely provides additional capacity and may only be used in combination with GS1 AI (414), not with GS1 AI (417) for an organization.

https://example.com/417/9521141123454` is an instance identifier for an organization (something of type schema:Organization), which could also identify a specific department or other sub-organization within an organization.

In reply to the latest comment from @MatthiasWiesmann while I was writing this,
/01/xxxxxxxxxxxxxx/7001/yyyyyyyyyyyyy would not be valid GS1 Digital Link URI syntax because 7001 is not defined as a permitted 'key qualifier' of GTIN (01), so AI (7001) and its value would need to be specified via the URI query string, e.g., /01/xxxxxxxxxxxxxx?7001=yyyyyyyyyyyyy . Just pointing this out so that anyone else reading this thread doesn't assume that any combination of AIs in the URI path information would be valid GS1 Digital Link URI syntax.

@VladimirAlexiev
Copy link

@mgh128

by scanning a QR Code that encodes such a GS1 Digital Link URI.

Ok, I now see you guys have discussed such QR codes a lot above.
Then my question is confusing: when a RFID or barcode reader sees a SGTIN, how would it know what is the Digital Link URL? Especially if it doesn't have internet access?

there is value in a GS1 Digital Link URI appearing in Linked Data directly, as the subject or object of triples,

Yes! But I suggest it should be in s:url not in @id. You must have the @id to fetch any data about the product. And one of this data (fields) should be the DL URL.

@mgh128
Copy link

mgh128 commented Mar 18, 2024

Hi @VladimirAlexiev ,

I've provided some replies inline below. I hope they're helpful.

by scanning a QR Code that encodes such a GS1 Digital Link URI.

Ok, I now see you guys have discussed such QR codes a lot above. Then my question is confusing: when a RFID or barcode reader sees a SGTIN, how would it know what is the Digital Link URL? Especially if it doesn't have internet access?

Unless it's an NFC reader, an RFID reader sees a binary or hexadecimal string representing an EPC. EPC schemes corresponding to SGTIN include SGTIN-96, SGTIN-198, SGTIN+ and DSGTIN+ . The binary/hexadecimal string can be translated to element string format or to a GS1 Digital Link URI using the rules and formats defined in the GS1 Tag Data Standard (TDS) (which are authoritative on this matter as far as encoding/decoding of GS1 identifiers in Gen2 RFID tags is concerned) or making use of the supporting machine-readable artefacts provided via the GS1 Tag Data Translation Standard (TDT).

In the EPC schemes SGTIN-96, SGTIN-198, SGTIN+ and DSGTIN+ , there is no mechanism to encode a URI stem with a custom domain name, so translation to GS1 Digital Link URI typically assumes that the canonical format will be used, in which the URI stem is https://id.gs1.org before the /01/{gtin}/21/{serialNumber} structure in the URI path information.

If a barcode reader sees a GS1 DataMatrix symbol that encodes (01) and (21) as element strings, then again, there is no expression of the custom URI stem to use, so https://id.gs1.org can be assumed by default.

If a barcode reader sees a Data Matrix or QR Code encoding what appears to be a URL or Web URI beginning with https:// or http://, then it can simply treat it as a URL and make a Web request. If that URL / Web URI conforms to the formal syntax defined in https://ref.gs1.org/standards/digital-link/uri-syntax/ then there is a high probability that it is intended to be a GS1 Digital Link URI and that it may be possible to extract GS1 Application Identifiers such as (01) for GTIN and (21) for serial number by parsing of the URI syntax, even in an offline situation. A valid GS1 Check Digit for the extracted GTIN value also gives further confidence that the 14-digit value after /01/ is intended to be a GTIN, since there is only a 10% chance of using the correct digit by chance.

If internet access is available, software could also look for the presence of a Resolver Description File at /.well-known/gs1resolver for the corresponding URI stem. For the GS1 Global Office resolver at id.gs1.org, the resolver description file can be found at https://id.gs1.org/.well-known/gs1resolver . According to section 4 of https://ref.gs1.org/standards/resolver/ ,
Furthermore, all GS1-
Conformant Resolvers SHALL publish a Resolver Description File at /.well-known/gs1resolver that
asserts its independent control of its URI space. The presence or absence of this file can be used to
determine whether or not the URI points to a service conformant to this standard. The Resolver
Description File includes information about whether the resolver handles all or only a subset of the
GS1 identifier system, support for any extensions, the supported value space(s), if any, for the
context keyword and more.

there is value in a GS1 Digital Link URI appearing in Linked Data directly, as the subject or object of triples,

Yes! But I suggest it should be in s:url not in @id. You must have the @id to fetch any data about the product. And one of this data (fields) should be the DL URL.

I'm not sure whether you're viewing this from an HTTP Range 14 perspective. Section 9.5 of https://ref.gs1.org/standards/digital-link/ provides some commentary about that, including the following statement:

GS1 Digital Link URIs also identify physical things, not information resources that describe them

So although you can use a GS1 Digital Link URI to retrieve an information resource about a physical thing, that information resource can use a GS1 Digital Link URI to write factual claims / RDF triples.
Referring to https://www.w3.org/TR/json-ld11/ it's therefore valid for an object or class in JSON-LD to directly use @id with a value equal to the GS1 Digital Link URI if the thing identified by that GS1 Digital Link URI is considered to be the RDF Subject within that node enclosed by curly brackets, analogous to what appears at https://www.w3.org/TR/json-ld11/#example-13-identifying-a-node . However, I accept that where there is a preference to identify a node by a Web URI or URL that is not a GS1 Digital Link URI or to use a blank node, then it is may be helpful to use another property such as schema:hasGS1DigitalLink to signal that it's not just any URI but that there is intentionally a GS1 Digital Link URI with a well-defined structure rather than another URI whose structure can be assumed to be opaque.

Even so, in example 4 of https://digitallink-dot-schemadotorg1.ew.r.appspot.com/Product I still don't think it would actually be wrong for that block of JSON-LD to additionally use @id to express the GS1 Digital Link URI, like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@id": "https://gs1.appareldemo.com/01/09506000164908",
  "@type": "Product",
  "title": "Crew neck white t-shirt",
  "description": "White t-shirt  made of soft and lightweight cotton jersey, ensuring comfort, a refined mélange texture adds sporty appeal.",
  "hasGS1DigitalLink": "https://gs1.appareldemo.com/01/09506000164908",
  "gtin": "09506000164908"
}
</script>

rather than just leave it as a blank node.
https://gs1.appareldemo.com/01/09506000164908 redirects by default to a product information page at https://ref.gs1.org/tools/demo/2024retail/ , which contains an embedded block of JSON-LD, in which the GS1 Digital Link URI does indeed appear as the value of the @id of a node in which various other properties are expressed, including the schema:name, schema:description, gs1:gpcCategoryCode etc.

Thanks to @MatthiasWiesmann for adjusting the details for the preview at https://digitallink-dot-schemadotorg1.ew.r.appspot.com/hasGS1DigitalLink to take into account the feedback provided today by @philarcher @mfhepp and by me.

@MatthiasWiesmann
Copy link
Contributor Author

MatthiasWiesmann commented Mar 19, 2024 via email

@MatthiasWiesmann MatthiasWiesmann mentioned this issue Apr 3, 2024
Merged
@alex-jansen alex-jansen mentioned this issue Apr 3, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@ziodave @VladimirAlexiev @mfhepp @Tiggerito @philarcher @mgh128 @jvandriel @alex-jansen @MatthiasWiesmann