Open ml-evs opened 1 month ago
All good points.
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:
I think each approach has pros and cons, but would be curious to hear other's thoughts.
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.
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.
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:
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.
then either:
Open questions
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:
datalab.ly/concat:refcode
, then a simple server at datalab.ly resolves thatconcat:
currently exists atdatalab.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
Barcode scanning in datalab itself