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.

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

Container vs labware? #33

Open
photocyte opened this issue Apr 27, 2022 · 10 comments
Open

Container vs labware? #33

photocyte opened this issue Apr 27, 2022 · 10 comments

Comments

@photocyte
Copy link
Member

Is it too late to rename "container" used within the container-ontology to labware? It seems to be a point of confusion between the dry-lab containers (i.e. Docker / Singularity) & the wet-lab containers (i.e., plates).

"Labware" as a term is fairly distinctive, and a broader generalization that "container" as well (does everything the container-ontology seek to contain, always contain things? What about a microplate lid?)

@rpgoldman
Copy link
Collaborator

I don't believe it is too late, but probably what I should do is add Labware, and for now make Container be a synonym.

I think it would be helpful to have @danbryce @bbartley @jakebeal evaluate this suggestion, since I don't know what existing references might be made to Container (hence my suggestion that it be retained as a synonym).

Some related notes:

  1. I could also use some help with the distinction between "Microplate" and "Microwell Plate"
  2. The OBO ontology for the above terms seems weirdly flat. It looks like there are a ton of sibling classes for "Microplate", and little taxonomy between "Microplate" and the superclass "Diagnostic, Therapeutic, or Research Equipment". That's likely fine, but surprising to me, at least.

@photocyte
Copy link
Member Author

Hi Robert, colloquially, microplate, multiwell plate, microtitre plate, are all the same concept. Namely, SLAS/ANSI footprint labware. More specifically, multiwell plates seems a more generic term, as it would refer to things that don't just hold microliters per well, i.e. 24-deepwell plates, whereas it feels a little funny to refer to a 24-deepwell plate as a microplate, but I'm sure it wouldn't make someone blink twice if a 24-deepwell were classified under microplate in a protocol. "1-well" plates, or reservoirs, are a related concept.

And just to clarify, the rename I was thinking of, would be an all-level rename, i.e. this repository would become 'labware-ontology' & other "container" links / references would have to be tracked down...

@rpgoldman
Copy link
Collaborator

The reason I asked about "microplate" versus "microwell plate" is that these are two different entities in the NCIT ontology (see the links in my message).

According to the NCIT ontology, a "Microwell Plate" is a subclass of "Microplate," but I don't understand why.

Microwell plate definition: " Small volume multi-chambered plate (e.g. 96 well).; A flat dish type device with multiple wells for testing cellular material."

Microplate definition: "A flat dish with multiple individual wells that are arrayed in a standardized number, size, and arrangement."

I suppose according to this definition there are microplates that are not microwell plates because they are used for some other purpose. It would have been helpful to add at least one class of Microplates that is not a Microwell plate, but as far as I can tell they have not done so.

@photocyte
Copy link
Member Author

Hi Robert,

Indeed, I hadn't taken a look at those definitions & realized afterwards I didn't even include Microwell plate in my response!

I don't find the Microwell plate -> Microplate subclassing intuitive or sensible, either in terms of my day-to-day understanding of the usage of these plates in labs, nor in the given NCIT definition. The cellular material inclusion is especially curious - should plates be defined based on whether they are/can contain?

I suppose the question is, is this an "upstream issue"? Does NCIT need to be poked to update their ontology to maybe fold together Microplate into Microwell plate (better renamed as Multiwell plate)? Or live with it even if it isn't exactly "right"? Or separate from that ontology entirely?

@rpgoldman
Copy link
Collaborator

I suppose the question is, is this an "upstream issue"? Does NCIT need to be poked to update their ontology to maybe fold together Microplate into Microwell plate (better renamed as Multiwell plate)? Or live with it even if it isn't exactly "right"? Or separate from that ontology entirely?

Absolutely it's an upstream issue and I don't know that it's even an important one. For now, I just mark all the microplates as being Microwell Plate http://purl.obolibrary.org/obo/NCIT_C96142, just so that someone using the NCIT ontology would know that our plates are the same sort of thing as theirs. Probably anything more than that is overthinking it.

Let's talk about the main issue here (as opposed to my rabbit-hole) at the next PAML meeting and see if we can get to closure. The big issue, IMO, is how much pain this would cause others.

@photocyte
Copy link
Member Author

This just happened to show up when I mistakenly searched in the Bits in Bio Slack when trying to search for something else in an adjacent Slack tab: https://bitsinbio.slack.com/archives/C02RUPYKPHB/p1641204183259500. Seems relevant to the "Container Ontology" vs "Labware ontology" discussion.

@photocyte
Copy link
Member Author

photocyte commented Aug 30, 2022

@jcahill , pinging to continue discussion from weekly meeting. IMO, in the examples Bryan was showing, items were being included in the container-ontology that were a stretch to call a container in the narrow sense (i.e. aluminum blocks). Labware, would capture more types of objects, and "bless" this repo / ontology for being used to house a more general class of laboratory objects.

edit: CC @bbartley , in case you are interested

@rpgoldman
Copy link
Collaborator

@photocyte -- Just reviewing this discussion. Would it be possible for you to explicitly quote the posting from the bitsinbio Slack? I don't think that's a link that works persistently, and it has a number of other drawbacks.

Also, could you include a pointer to "the examples Bryan was showing"? We should make this discussion accessible to people who weren't at that meeting (including me!)

@photocyte
Copy link
Member Author

photocyte commented Sep 9, 2022

Hi Robert, no Slack thread to link to, this was a discussion that happened in the Zoom chat & discussions of the weekly meeting. I believe the weekly meeting mentioned above was this one:
https://docs.google.com/document/d/1B7CFXFKnQ9h7EQO7vKuD7ktW-k1j7rU2q3qqOlg2hfY/edit#heading=h.47fz4ugx1qlx

Unfortunately I don't think the recording for that meeting was preserved? At least I don't see it on the Google Drive.
https://drive.google.com/drive/folders/1YSzcheDaIRdrFyZl9oqhtrFZWcjsxiql @danbryce ?

@bbartley presented a Google Slides with his Opentrons progress. There was one slide with the objects added to the container ontology i.e. aluminum blocks that I recall. I'm not seeing that Google Slides deck via a search so I have to defer to @bbartley if he could provide a pointer to it.

edit: I now understand what you meant by explicitly quote the posting from the bitsinbio Slack , i.e. from this comment. #33 (comment) Unfortunately the linked thread seems to have gone past the messages older than 90 days window & is now hidden...

@rpgoldman
Copy link
Collaborator

I'd be happy to rename to labware-ontology, but let's do it deliberately and figure out how to do it with a minimum of pain (especially to @bbartley and @danbryce !).

I think we could allow the python package to be importable under two names, and raise a warning if the old one was used. I also think it's relatively easy to allow reference to the ontology RDF entries under different IRIs, but I'll have to check to ensure that the .ttl files have only relative names.

I'll look around and see if there are best practices for ontology renames.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants