Closed HLWeil closed 2 years ago
To implement the Protocol Type
column (ref), i need the Protocol Type
Term's accession id. Maybe someone could add the term?
How is this handled for the other ISA attributes Source Name
, Sample Name
, etc.?
I have initiated a list of terms that would live "under" Protocol Type
, but I'm a bit reserved to add it to the ontology for reasons.
They are handled differently. There is no reason to search through relationship directed terms of Source Name and Sample Name, as their intended usecase differs.
I only need the accession of Protocol Type to search through related terms.
[Term] id: NFDI4PSO:1000161 name: Protocol Type
https://github.com/nfdi4plants/nfdi4plants_ontology/commit/3a8e1865e91f0f00695e16b44bbfa57b64260de3
https://github.com/nfdi4plants/Swate/issues/212
Protocol REF
und Protocol Type
sind implementiert.
Originally posted by @Freymaurer in https://github.com/nfdi4plants/ISADotNet/issues/61#issuecomment-1190186478
The protocol types listed in BioTermSubTree.xlsx have been added to nfdi4pso.
Reasons for this addition
@Brilator , @Martin-Kuhl , @muehlhaus , @Freymaurer
The
protocol type
is a field supported by the ISA-Json model, and could have different practical uses.E.g. the
GEO file format
requires descriptions for specific protocols like theextract protocol
. There needs to be a mechanism to find the respective protocol in the assay. As users are free to choose the names of their sheets, just matching the name would not be the way to go.Therefore I propose we make use of the
protocol type
field. Unfortunately this is only defined inISA-Json
, but notISA-Tab
. But we could expand the standard by adding aProtocol Type
column to the assay sheet. This feature could be part ofSwate
too.It is important to make finding the proper protocol type convenient for the user and to restrain the possibilities in a way that makes matching the proper protocol by its type automatically manageable. Therefore it would be good to extend our ontology by a
protocol type ontology
.Swate
would be able to recommend these protocol type terms to the user when inserting the protocol type column. Additionally, we could define different, more fine grained kinds of protocol types that then get matched to more broader terms trough ais a
relationship.E.g. user specifies one protocol in his assay as a
filter based extraction protocol
by using Swate (which found him this term in the ontology). When exporting his arc to geo, theGeo-converter
tries to find theextraction protocol
and by again using the ontology can match it with thefilter based extraction protocol
. -> Profit