Replies: 5 comments
-
|
Let's discuss this further after lab meeting today.
…On Tue, Aug 8, 2023 at 10:49 AM ptth222 ***@***.***> wrote:
I am trying to create conversion directives for ISA and I have run into a
problem. In ISA protocols they separate components (instrument name,
instrument type, etc.) and parameters (sample volume, standard volume,
etc.). Our protocols don't do this in a machine identifiable way. We just
have field names and values and you can tell what they are by the name as a
human. I'm not sure how we classify the fields on a protocol into
components and parameters. I don't see how it can be done without adding
tables to identify them or adding something to the field names. For
example, instead of "instrument_name" it could be
"component_instrument_name" or something. What do you think?
—
Reply to this email directly, view it on GitHub
<#32>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADEP7B66FJD4MJZX6OTD6STXUJGYNANCNFSM6AAAAAA3ITF44Y>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Hunter Moseley, Ph.D. -- Univ. of Kentucky
Professor, Dept. of Molec. & Cell. Biochemistry / Markey Cancer Center
/ Institute for Biomedical Informatics / UK Superfund Research Center
Not just a scientist, but a fencer as well.
My foil is sharp, but my mind sharper still.
---------------------------------------------------------------
Email: ***@***.*** (work) ***@***.***
(personal)
Phone: 859-218-2964 (office) 859-218-2965 (lab) 859-257-7715 (fax)
Web: http://bioinformatics.cesb.uky.edu/
Address: CC434 Roach Building, 800 Rose Street, Lexington, KY 40536-0093
|
Beta Was this translation helpful? Give feedback.
-
|
We discussed adding the needed information in a few possible ways, including adding attributes for each relevant field, adding lists of field names, and extending the PDS and supplying it to convert. There were trepidations for extending the PDS because it makes it do more than simply validate and would require delivering an additional file to convert. There were trepidations to adding attributes to each protocol because it is ISA specific. We talked it out enough and ended up with a solution to add fields, but in a more modular way. Instead of adding fields/attributes directly to a protocol in initial templates or automations we use #modify or #end-modify tags in the extract command to add the fields/attributes to the protocols. This allows us to have a workflow that creates a mwtab deposition and then add 1 additional file in the extraction step that will create an ISA extraction for an ISA workflow. Example
After getting to this solution we didn't decide whether adding attributes for each field or lists of fields would be better though. I have an example below to illustrate. It shows 2 lists, "isa_components" and "isa_parameters", vs adding an attribute "...%isa_fieldtype" for each relevant field. Something I did not mention is that the component object in ISA has an extra "type" field that the parameter object doesn't, so we can extend this solution to add a "isa_comptype" attribute as well. For this reason I prefer the attribute solution over the lists solution. |
Beta Was this translation helpful? Give feedback.
-
|
I have ran into another small related issue. I have coded in to get components and parameters using the attribute solution, but there is another issue due to protocol inheritance. By default, the MESSES JSON has "parent_id" allowed for every table. We only really utilize this for entities, but for other tables it isn't necessarily obvious what the inheritance would mean if a user used it. Specifically, for protocols there is an issue in the translation to ISA because ISA has no concept of protocols inheriting or deriving from each other. Should protocols that inherit from another automatically inherit the attributes from the parent? Should ICMS2 automatically have the other attributes from ICMS1 that aren't explicitly listed? This is important for ISA because the parameters and components have to be listed for each protocol, so I would have to propagate the attributes through to the children since there is no way in ISA to signal inheritance. Would this be the default for all tables? This kind of seems like "duh of course", but I want to be sure because I also need to update some parts of how things are validated I think. I'm pretty sure I always count on the object having everything it needs and not needing to propagate attributes from its ancestors. I also just realized we can add assays by just making them a study that inherits from another study. So basically, studies with a parent would be assays. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, inheritance should propagate the parameters and components.
Interesting about studies having inheritance.
Would like to talk more about this.
May provide some additional use-cases.
…On Thu, Nov 2, 2023 at 5:45 PM ptth222 ***@***.***> wrote:
I have ran into another small related issue. I have coded in to get
components and parameters using the attribute solution, but there is
another issue due to protocol inheritance. By default, the MESSES JSON has
"parent_id" allowed for every table. We only really utilize this for
entities, but for other tables it isn't necessarily obvious what the
inheritance would mean if a user used it. Specifically, for protocols there
is an issue in the translation to ISA because ISA has no concept of
protocols inheriting or deriving from each other.
Should protocols that inherit from another automatically inherit the
attributes from the parent?
For instance:
"ICMS1": {
"chromatography_description": "Targeted IC",
"chromatography_instrument_name": "Thermo Dionex ICS-5000+",
"chromatography_type": "Targeted IC",
"chromatography_type%isa_fieldtype": "parameter",
}
"ICMS2": {
"chromatography_instrument_name": "Some other instrument",
"parent_id": "ICMS1"
}
Should ICMS2 automatically have the other attributes from ICMS1 that
aren't explicitly listed? This is important for ISA because the parameters
and components have to be listed for each protocol, so I would have to
propagate the attributes through to the children since there is no way in
ISA to signal inheritance.
Would this be the default for all tables?
This kind of seems like "duh of course", but I want to be sure because I
also need to update some parts of how things are validated I think. I'm
pretty sure I always count on the object having everything it needs and not
needing to propagate attributes from its ancestors.
I also just realized we can add assays by just making them a study that
inherits from another study. So basically, studies with a parent would be
assays.
—
Reply to this email directly, view it on GitHub
<#32 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADEP7B4OVAJOA7SIGFRXSTLYCQIA3AVCNFSM6AAAAAA3ITF442VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TINRRGQ3DS>
.
You are receiving this because you commented.Message ID:
<MoseleyBioinformaticsLab/MESSES/repo-discussions/32/comments/7461469@
github.com>
--
Hunter Moseley, Ph.D. -- Univ. of Kentucky
Professor, Dept. of Molec. & Cell. Biochemistry / Markey Cancer Center
/ Institute for Biomedical Informatics / UK Superfund Research Center
Not just a scientist, but a fencer as well.
My foil is sharp, but my mind sharper still.
---------------------------------------------------------------
Email: ***@***.*** (work) ***@***.***
(personal)
Phone: 859-218-2964 (office) 859-218-2965 (lab) 859-257-7715 (fax)
Web: http://bioinformatics.cesb.uky.edu/
Address: CC434 Roach Building, 800 Rose Street, Lexington, KY 40536-0093
|
Beta Was this translation helpful? Give feedback.
-
|
We discussed the inheritance propagation some more and decided that doesn't really make sense. The inheritance concept doesn't make sense for all tables, so we will only utilize it on the ones that it makes sense for. The validation and documentation will be changed appropriately. |
Beta Was this translation helpful? Give feedback.
-
I am trying to create conversion directives for ISA and I have run into a problem. In ISA protocols they separate components (instrument name, instrument type, etc.) and parameters (sample volume, standard volume, etc.). Our protocols don't do this in a machine identifiable way. We just have field names and values and you can tell what they are by the name as a human. I'm not sure how we classify the fields on a protocol into components and parameters. I don't see how it can be done without adding tables to identify them or adding something to the field names. For example, instead of "instrument_name" it could be "component_instrument_name" or something. What do you think?
Beta Was this translation helpful? Give feedback.
All reactions