QR codes and barcodes for samples

[ml-evs]

cc @PeterKraus @jdbocarsly (and maybe @MJCliffe?)

We have often discussed labelling physical samples with QR codes/bar codes. This issue can be used to outline the work needed and then potential extensions.

• Resolve sample pages by refcode in the API and UI

then either:

• We add a configurable "labelling" block that allows you to choose QR code size, style etc. for printing, and any extra info you want to be on the label
• or, we hardcode the label style at the level of the server, and always show that label on the item page. How it prints at different scales will be up to the user.

Open questions

• How should permissions work in this case? We could embed a read-only token for the QR code, so if someone can scan your samples, then they should at least be able to see what it is/was.

Extensions

Link resolvers

How long do these barcodes need to last, and what info should we try to encode in them in case the datalab is gone/dead? I think there are two options:

• Stuff as much of the JSON data into the QR code itself, e.g., formula, hazards and so on, so that it at least can be resolved by a smart QR code scanner if datalab is dead. I don't know how smart a normal mobile browser scanner is, so this would need some experimenting.
• Devise a "datalab federation" link resolver, so that the QR code only points to e.g., datalab.ly/concat:refcode, then a simple server at datalab.ly resolves that concat: currently exists at datalab.concatlab.eu. This could allow us to have an interesting "off-ramp" where we statically host an entire datalab's JSON response to allow this resolution to work "forever".

Printing labels from datalab

• Attach label printer to the datalab server itself (via tunnels or whatever), so that a "print label" button always goes to a printer in the lab, with some predefined sizes.
• I think @jdbocarsly was interested in the reverse, where the act of printing a label actually creates the stub datalab page and reserves the ID.

Barcode scanning in datalab itself

• Given the read-only permissions above, it would be nice to use QR codes to also ingest data into datalab. e.g., you exchange samples with a collaborator, they can scan the QR code via the datalab browser (either uploading the image, or using the camera functionality), and then datalab can make the API call to the other person's datalab and ingest it, maintaining various backlinks. In this case, it could be very nice to even communicate to the "remote" datalab that the sample has been "received" and that it is now locked for editing until they rescan the QR code at original end (or alternatively, until they rescan it, any changes made remotely must be pushed back to the local datalab).

[PeterKraus]

All good points.

• I think per-server labels would be more straightforward.
• The "permissions" discussion can be potentially quite complicated. I think "Name", "Chemical Formula", "Creation Date" and maybe the "Hazard Statements" (if they will be also applicable to samples) should be viewable by anyone who has the item in their hand, but perhaps not without some encoded api key (to prevent crawling by Sam Altman).
• "Rich data" in the QR codes might make them quite big and inconvenient to use.
• Federation is a great idea.
• I think having a label printer reserve a sample ID is also a great idea. Not sure if we'd use it in our lab, but it sounds like an obviously smart thing to do, if you have the culture for that.
• Having a predefined label printer for a server might get in the way, especially as our stuff is behind our stupid VPN. I think system dialog might be the low hanging fruit here. Maybe the same tool that creates new datalab samples on button press could also listen for print jobs, but that might be overengineering it.
• Sharing samples via barcode - great idea. Maybe something for MADIC3S?

[jdbocarsly]

I agree that encoding information about the sample in the qrcode may be getting too complicated. Our thinking is that the QRcode should simply encode a URL because that allows us to point our smartphone cameras at the label and go to the datalab page (instead of needing to open an app or website and then scan, which is annoying). The label itself, however, should have (configurarable) text on it that labels this information.

I also agree with Peter that some basic information about composition and safety and owner should be available to anyone who can scan the QR code. If I have a sample in my hand, then I should be able to find that information out for safety reasons.

I also like the idea of having a federation-wide URL resolver if it isn't too much work, since that gives flexibility. For example, the UH datalab will probably change domains at some point in the near future, and it would be really nice not to have to regenerate labels at that point.

We (@KusalvinD) have thought about (and made a tiny bit of progress towards) the label printing in the lab. The goal is to have a button on the datalab sample page that says "print label" with some options and simply prints the label (I don't actually think we need the reverse case). We have two ways we are thinking about making this work:

1. Connect wifi label printers to the datalab server by IP.
2. Have a lightweight server or computer in the lab that is connected to the printers. The datalab server would send authenticated http requests to this server to print (and potentially do other tasks in the lab).

I think each approach has pros and cons, but would be curious to hear other's thoughts.

[jdbocarsly]

I will add -- all we've done so far is learn how to generate labels with QR codes and text on them and print them to a Brother QL-810W label printer from python. We haven't worked on integration into datalab yet.

[ml-evs]

Quick update on the status of #808, datalab can now generate QR codes with whatever prefix link you like, and provides a dialog for printing them (will need to see how this works with a label printer).

The only remaining thing to do here is see if we can visually embed the refcode into the label (optionally), either as part of the QRCode or just below it.

I've also added a QR scanner component for labs that want to have a machine running datalab persistently.

Currently the prefix of the link is configurable but defaults to the non-existent "qr.datalab-org.io", which needs to be built. I'm imaging this as a simple nginx-only server that receives e.g., refcode "test:ABCDEF" and redirects to https://datalab.test.com/items/ABCDEF, though it may be helpful to also have a non-redirect mode that just returns the correct URL (so that e.g., a client can scan a code and check whether it exists on their own datalab or another).

The built-in QRCode scanner component itself can be more flexible, however. It can simply scan the code, extract the refcode from the URL and directly check if it matches its own implementation, without the need of the link resolver.

So we should see basically what the user story for this is, i.e., whether people will mostly be scanning with native QR code scanners on phones or if they could easily use a webcam in the lab.

[ml-evs]

Another update after some hacking on this today, https://github.com/datalab-org/datalab-federation has its first entry (no instructions yet), which builds a Docker container to be pulled by https://github.com/datalab-org/datalab-purl, which builds another Docker container with generated nginx configs that do the appropriate redirects. I've stuck this at https://purl.datalab-org.io and the demo ID demonstrates the process: http://purl.datalab-org.io/demo:ODYPNF (though the URL with 404 after redirect as there's no QR codes on that deployment yet, plus its on an old version that cannot resolve refcodes itself).

Other stuff to-do:

• Embed tokens in QR code links to allow access to a safe subset of the data