ISA / LIMS

[Rutger Vos]

Hi all,

for an initiative I am involved in, we are exploring how to pass relevant metadata between:

- sample/specimen collections

- the wet lab

- bioinformatics

- the outside world & consortium partners

Some of these components are broadly fixed in place (we have a collection registration database). Some we are fairly but not entirely committed to (galaxy for bioinformatics). For the lab, we now have a web-based system of spreadsheets that tries to be a LIMS.

ISA-TAB seems like a sensible framework for organizing and serializing our metadata, so might consider making its support one of the requirements should we purchase a  LIMS. However, we're having a hard time figuring whether/which LIMS systems support it, ideally as a first-class citizen (rather than a bolted-on export or import).

Could you make any suggestions or recommendations for how we might design our ecosystem (esp. LIMS) if we want to build it around ISA?

Thank you very much for any input,

Rutger Vos

[Philippe]

Hi Rutger,

Thank you for reaching out. LIMS systems are quite demanding beasts.

In the old days, we worked with BASE system from Lund University (Jari Hakkinen's group). there was a java plugin that could produce ISA-Tab document and also load data from an ISA archive. That is pretty much the only 'LIMS' system I am aware of which 'connected with ISA'.

One of the requirement would be to be able to exchange ISA fragments (ie. a set of Sources, Samples, Assays) without having necessarily to create an Investigation and Study objects.

Those objects may only come handy later, should a user be interested in releasing/publishing work as an ISA Archive.

 The ISA-API could be used for the message generation but a persistance layer and a front end would need building.

We could organize a call to understand the needs, requirements, timelines.

Let us know

Best wishes

Philippe

--
--
--
 
You received this message because you are subscribed to the Google
Groups "ISAforum" group.
To post to this group, send email to isaf...@googlegroups.com
To unsubscribe from this group, send email to
isaforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/isaforum?hl=en-GB
 
Visit the ISA tools website at http://isa-tools.org and http://isacommons.org
---
You received this message because you are subscribed to the Google Groups "ISAforum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isaforum+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isaforum/12e1d003-02cb-49f8-897f-f31bb4e11f49n%40googlegroups.com.

[Rutger Vos]

Hi Philippe, 

One of the requirement would be to be able to exchange ISA fragments (ie. a set of Sources, Samples, Assays) without having necessarily to create an Investigation and Study objects.

Yes, exactly. We now conceptualize the architecture of our future system as one with different stations where (meta)data is enriched. The wet lab would be one of those stations, but specimen collections and bioinformatics would be others. So the LIMS shouldn't govern the whole thing, just interact with it. 

Those objects may only come handy later, should a user be interested in releasing/publishing work as an ISA Archive.

 The ISA-API could be used for the message generation but a persistance layer and a front end would need building.

I've been trying to get my head around whether the isaexplorer could be part of the components needed for such a persistance layer and front end but I'm getting the impression it's abandonware, is that correct? 

We could organize a call to understand the needs, requirements, timelines.

That's a very kind offer. I think we might. Right now the data architecture team is evaluating ISA as a data model that would give us basically a handrail to hold onto. So far we're rather interested so it's good to know you see this as a possibility. No doubt you're also drowning in zoom calls, though, so let's first find out where our internal deliberations lead us!

All the best,

Rutger

--

Met vriendelijke groet,

Dr. Rutger A. Vos

Researcher / Lecturer / Bioinformatician

_{+31717519600 - +31627085806}

_{rutge...@naturalis.nl - www.naturalis.nl}

_{Darwinweg 2, 2333 CR Leiden}

_{Postbus 9517, 2300 RA Leiden}

[David Johnson]

Hi Rutger!

Not sure if you remember me but I briefly worked in Mark Pagel's group at Reading when you were a MC fellow there.

I developed ISA API with Philippe's team, but I don't work in that team anymore. Although there aren't currently really any LIMS systems supported right now (that we know of), the aim of ISA API (a library written in Python for handling ISA metadata) is to hep people to build tools and systems to use ISA formats (ISA-Tab and the newer ISA-JSON).

Example systems that persist ISA metadata and use ISA API include EBI's Metabolights (https://www.ebi.ac.uk/metabolights/) and BBSRC's COPO (https://copo-project.org/), so building something for your requirements is certainly possible. Check out ISA API here https://github.com/ISA-tools/ISA-API and supporting documentation here https://isa-tools.org/isa-api/content/index.html

Best/David

[Philippe]

Hi Rutger

Yes, exactly. We now conceptualize the architecture of our future system as one with different stations where (meta)data is enriched. The wet lab would be one of those stations, but specimen collections and bioinformatics would be others. So the LIMS shouldn't govern the whole thing, just interact with it.

It would be interesting to understand the type of relations between 'specimens' and any material collected from them for analysis, as well as the various data acquisition events you'd have to perform and any standard compliance constraints you may have to abide by.

Those objects may only come handy later, should a user be interested in releasing/publishing work as an ISA Archive.

 The ISA-API could be used for the message generation but a persistance layer and a front end would need building.

I've been trying to get my head around whether the isaexplorer could be part of the components needed for such a persistance layer and front end but I'm getting the impression it's abandonware, is that correct?

The ISAexplorer is as a very thin layer for presentation and was developed simply to render an ISA-Tab document in a web browser. It works but  It is by no means a full blown UI with storage backend, edit functions or advanced search capabilities.  

As with all things, new development and feature expansions are contingent to 1/ user requests and 2/ funding.

We could organize a call to understand the needs, requirements, timelines.

That's a very kind offer. I think we might. Right now the data architecture team is evaluating ISA as a data model that would give us basically a handrail to hold onto. So far we're rather interested so it's good to know you see this as a possibility. No doubt you're also drowning in zoom calls, though, so let's first find out where our internal deliberations lead us!

As pointed out by David, ISA is not just ISA-Tab, a JSON serialization exists too and the API allows conversion between the 2 forms.

You know where to find us.

all the best

P

[Rutger Vos]

Hi both,

(I am responding to Philippe's message just now, but after having read David's reply as well. Nice to hear from you David, and thanks for the suggestions!)

It would be interesting to understand the type of relations between 'specimens' and any material collected from them for analysis, as well as the various data acquisition events you'd have to perform and any standard compliance constraints you may have to abide by.

Excellent question. The relationship is roughly as follows: our museum uses two systems for registering collection specimens. One is the CRS, our in-house developed database that holds most of our specimens, and Brahms, the system we use specifically for herbarium specimens. From these, we take bits of material to do various lab assays, and these bits of material are samples. At present we don't have a very good system for managing these because we hadn't really needed them yet: remaining materials from lab assays end up in our freezers in chronological order, and so far we've been able to find them again from sample sheets. No, that's not ideal. We assume that any LIMS will include a facility for sample tracking.

 

Those objects may only come handy later, should a user be interested in releasing/publishing work as an ISA Archive.

 The ISA-API could be used for the message generation but a persistance layer and a front end would need building.

I've been trying to get my head around whether the isaexplorer could be part of the components needed for such a persistance layer and front end but I'm getting the impression it's abandonware, is that correct?

The ISAexplorer is as a very thin layer for presentation and was developed simply to render an ISA-Tab document in a web browser. It works but  It is by no means a full blown UI with storage backend, edit functions or advanced search capabilities.  

As with all things, new development and feature expansions are contingent to 1/ user requests and 2/ funding.

Ok, clear. I sort of gathered that the ISAexplorer is basically a demonstrator after clicking around for a bit. Where we stand right now is basically at a point where we are taking inventory of what our ideal ecosystem of tools should look like. It is very clear that there won't be off-the-shelf tools available for any of this, so we expect to adopt open source APIs and tools that are close to what we want and that we will then develop and integrate for our needs. It is quite likely that the ISA-API will play a role in this, which means that a soft requirement for some of the tooling is that it either can be made to speak to JSON APIs and/or is itself written in python and could be ISA-ised if it isn't already.

 

We could organize a call to understand the needs, requirements, timelines.

That's a very kind offer. I think we might. Right now the data architecture team is evaluating ISA as a data model that would give us basically a handrail to hold onto. So far we're rather interested so it's good to know you see this as a possibility. No doubt you're also drowning in zoom calls, though, so let's first find out where our internal deliberations lead us!

As pointed out by David, ISA is not just ISA-Tab, a JSON serialization exists too and the API allows conversion between the 2 forms.

Yep, that's clear, and very good.

Cheers,

--

Met vriendelijke groet,

Rutger Vos

Researcher