Tripal: Content Types for Tv3

[spficklin]

Before we make the next release of Tripal v3, I would like to specify which content types we should have available by default. With Tripal v2 each content type required a new module, but for Tv3 adding new content types adds very little code. Here's the list of content types that are currently created automatically with Tripal v3:

1) organism
2) analysis
3) project
4) map
5) publication
6) gene
7) mRNA
8) biological sample
9) phylogenetic tree

What additional content types would you like to see available out-of-the box on a fresh install of Tripal? With the redesign of Tripal v3 we can now support all of Chado. Here's a list of potential types:
1) Array
2) Array design
3) Protocol
4) cell line
5) contact (either generic "contact" or several specific ones such as "Person", "Organization", "Company", etc.
6) additional genomic features (SNPs, genetic marker, etc??)
7) add "Genetic Map" and "Physical Map", and keep the generic "Map"
8) add a generic "Library" but also add other: "BAC Library", "FOSMID Library", etc...
9) add types typically stored in the Chado stock table: "Germplasm", "Individual", others?
10) Stock Collection
11) Study
12) Treatment
13) Thoughts on phenotype specific content types?

We're hoping to get a new release of Tripal out by the end of June, and these content types are relatively easy to add. Please provide some suggestions on what you'd like to see, the interim Project Management Committee (PMC) for Tripal would then approve the final list.

[bradfordcondon]

My belief is that its very easy to create custom types as necessary with a little Chado knowledge.

The more content types we enable by default the messier the add content screen is.

So i'm really in favor of keeping the list very minimal and pushing a very beginner friendly "create custom types or types for chado tables that dont exist!" document. Link to it in the "create content type" instructions.

My list of "base" types:

• analysis
• organism
• map
• pub
• gene/mRNA (i like having 2 types to demonstrate you can have 2 types for one table)

Thats it. Argue with me that we need to include more!

Didnt make the cut:

• project -> we dont use this at HWG. should we? hahah
• phylo tree (i dont think everyone would want to use, plus manual tree creation doesnt make much sense to me...)
• array/protocol etc. our site makes heavy use of analysis_expression and we dont use these...
• cell line
• contact (only used in conjunction with tripal analysis expression which creates the contacts. we wouldnt want entities for our contacts).

Everything else :O

[mestato]

I like having default content types - they make demo'ing the power of the software much more straightforward and give new site developers a lot to work with as soon as they start (chado and drupal can be pretty intimidating!). So I guess my argument is exactly opposite of Bradford's - if they are super easy to set up and for developers to later modify, why not do them?

I would vote for contact - we keep touting FAIR, so we should probably make contact an obvious and easy to use content type to show how straightforward Tripal makes data attribution. (even though HWG doesn't really use contacts throughout as we should. i need to take my own advice :)

I would also vote for genetic maps and SNPs, as these seem to be very commonly needed. But is this encroaching too much on extension module territory? My argument for it would be that, if the content type makes it more clear how we as a community plan to store markers in chado and display the data, that's better for reducing confusion later on and hopefully making future extension modules interoperable.

What about CVs and CVterms as content types? With our new use of ontology-driven structure, these would be obvious content types to me (although admittedly many sites don't actually expose these as pages for users).

Other than those, nothing else on the second list is something we need and all seem pretty specialized, so I have no particular objection to making defaults or not.

[bradfordcondon]

The criteria I had in mind were

• Will this content type be used by the majority of tripal sites
• will admins want users to visit this entity on its own page
• will admins want to manually create entities

The first point is keeping with Tripal's general guidelines. The second two are really the point of having a content type.

I think Meg makes a really good point about considering types that promote FAIRness, even if developers wont necessarily make use of them. CVterms is an interesting idea too. right now one would create them in the admin->data loaders -> manage cvterms section, and view them in the /cv/lookup area. Making them entities would allow people to easily attach stuff providing stats/links to other entities using that term, for example.

So I guess my argument is exactly opposite of Bradford's - if they are super easy to set up and for developers to later modify, why not do them?

the two main arguments is a) if you are creating a lot of content, all those types gets really cluttered when selecting a content type to add at /admin/structure/bio_data b) Careless or uneducated admins might create lots of entities that they dont actually use/want, ie by publishing mrna when they actually only want genes to be a page visible to the user. Both of these cases are resolved if the admin deletes unwanted content types. I dont know if Tripal ever recreates them: I think not?

edit: i made some tables of the HWG types/terms

General modules

| label | chado mapping | term | type/prop? | notes |
|-------------------------|----------------|-----------------------|--------------|-----------------------------------------------------------------|
| organism | chado.organism | OBI:organism | | |
| analysis | chado.analysis | operation:2945 | | we only use this for an SSR prediction pipeline right now |
| project | | local:project | | |
| map | | data:1274 | | |
| publication | | TPUB:0000002 | | |
| mRNA/polypeptide | | SO:0000234 | typeid | adjusted label to reflect we dont have entities for polypeptide |
| Biological sample | | sep:00195 | | |
| mRNA contig/polypeptide | | SO:0001829 | typeid | for draft genome assemblies that dont have true predicted mRNAs |
| Genomic Library | | local:genomic_library | typeid | |
| BAC library | | tripal:bac_library | typeid | |
| Phylogenetic tree | | data:0872 | | |
| transcriptome assembly | | operation:3258 | analysisprop | |

Analysis subtypes (which will be added by their respective modules.)

| label | chado mapping | term | type/prop? | notes |
|-------------------------|---------------|--------------------|--------------|----------------------------------------------------|
| transcriptome assembly | | operation:3258 | analysisprop | |
| genome assembly | | operation:0525 | analysisprop | for transcriptomes (ie not full genome assemblies) |
| blast annotation | | eco:0000206 | analysisprop | analysis_blast |
| interproscan annotation | | eco:0000029 | analysisprop | for analysis_blast |
| gene expression profile | | opeartion:0314 | analysisprop | for analysis_interpro |
| KEGG results | | local:kegg_results | analysisprop | for analysis_kegg |

[laceysanderson]

Another thing to consider is that if Tripal provides the content types we stand a better chance of all sites using the same cvterms for their content, which would increase sharability.

My Minimal? List would be:
_(would increase if we go with suggestion below)_

General Tables:

• project
• analysis
• organism
• pub
• contact (included due to @mestato argument)

Genomics:

• gene
• genome assembly (stored as an analysis? or project?)
• sequence variant
• physical map

Genetics/Breeding:

• genetic map
• sequence variant
• genetic marker
• DNA Sample

That said, I like @bradfordcondon's the idea of not cluttering the add content page and promoting how easy it is to create content types. Maybe we add "+ Create Default Genomic Types" and "+ Create Default Genetic/Breeding Types" as links at the top of the Structure > Tripal Content Types page. When clicked these could add the default types for the section in bulk. This provides good defaults based on the type of site you are creating, highlights how flexible Tripal is and makes it easy to stay minimal. With this approach only the "General" section above would be available on install. Thoughts?

_Example from KnowPulse showing a link at the top ("+ Add KnowPulse Content Types") that creates all KnowPulse specific content types at once. Implemented in UofS-Pulse-Binfo/KP_Entities_

[spficklin]

I think we should try our best to support new users who don't know Chado that well and would have to undergo a major undertaking to figure out how to create new content types by first learning Chado and where everything should go. So for that reason I'm leaning towards having as many content types ready to go as possible. And @laceysanderson your argument about increased sharability by using the same terms is a good one.

What if we create some new modules: tripal_genomics_site, tripal_genetics_site, tripal_breeding_site and put content types in those. The "base" content types can stay in the tripal_chado module. I see multiple benefits to this:
1) We don't overload our content types page with a bunch of +Add xxxx Content Types
2) We have a home for everything related to these specific types of sites
3) We can easily assign "maintainer" roles over certain types of site configurations to one or more people.
4) We can provide as many content types as needed to help new users without clutering up the base install.
5) The Tripal rapid installer could easily install the right module for what the user wants to do.

We could create these modules now for Tv3 but revisit if those should remain in Tv4 in our discussions this fall.

[bradfordcondon]

Agreed, I'm totally on board with as many content types as possible now, some really good points i didnt think of.

[laceysanderson]

I like the idea of separate modules 👍

[spficklin]

One other thing I forgot to mentioned. Unlike previous versions of Tripal, I think it would be nice if we had a content type ready to go for every base table of Chado.

[laceysanderson]

If by "ready to go" you mean documented somewhere with chosen cvterms then I agree that would be something to strive for. If you mean automatically added in any way, I don't agree. I would find that extremely overwhelming and hard to navigate...

[spficklin]

Yes, I meant automatically added... but by way of the new module plan. For example, if you want to display transcriptomic data then perhaps we have a tripal_transcriptoimcs_site that adds content types for the expression/MAGE tables of Chado.

[laceysanderson]

I'm working on a speedsheet for content type specs :-) It's open to edit so please feel free to jump in!
https://docs.google.com/spreadsheets/d/1wJbekYwaw4qULHdjh4hapWwrj82-w9IqiHs_1flr3iM/edit?usp=sharing

[guignonv]

+stock
+stockcollection
+contact

[sookjc]

Hello,
I think having a good list of content is good as long as we think they will be used by most sites without a conflict.

I'm good with Stephen's current list with a few addition.
organism
analysis
project
map
publication
gene
mRNA
+genetic marker
+QTL

Not sure about SNP as a separate content type since we can store them as genetic marker. The sub type can be stored in featureprop. But we could make an exception for SNP if that's what all want.

I looked at Lacey's table and I'm not sure if we want to have various 'stock' content types as default - since every site can call these differently and there can be many more types of accession/stock other than listed.
germplasm accession
germplasm variety
recombinant inbred line

For example, we have three types for stocks with unique genotype and try to fit in all into these three.
cultivar
breeding/research material
wild/unimproved

And we also have population, clone and sample as stock.type
populations is mostly for mapping population, clone is the exact individual (when there is a data from multiple cultivar), sample is the 'observational unit' (when there is data from multiple cultivar and/or individual). I don't think we need to make a content type for clone or sample.

So when there is no obvious consensus (like gene, genetic marker, map) for a content type, we should probably leave it up to the site developer or try to come up with a very generic content type that most of us can agree on.

[laceysanderson]

Hi @sookjc , thanks for weighing in! I think it's even more important to come up with defaults for germplasm in order to increase the likelihood of being able to share data. Can you share the cvterms you use for each of your types?

_Note: Keep in mind that providing defaults doesn't mean any site is required to use them. Furthermore, additional Tripal Content Types pulling from the stock table can easily be added through the UI so we don't need an exhaustive list. Also, the germplasm-specific types would be added by enabling a Tripal Breeding module so genomic-based Tripal sites won't have these types._

Hi @guignonv, yes I agree wholeheartedly with providing Tripal Content Types for those tables. Can you weigh in on the terms I choose (see below)? Also, I would love to hear what cvterms you are using as the type in the stock table!

Type Label | Term
-- | --
Germplasm Accession | accession; CO_010:0000044
Breeding Cross | generated germplasm; CO_010:0000255
Germplasm Variety | cultivar; CO_010:0000029
Recombinant Inbred Line | CO_010:0000162
Germplasm Collection | germplasm; EFO:0007059?

[spficklin]

@sookjc @laceysanderson and @guignonv. The "breeding/genetics" portion of Tripal has, in the past, been a very "gray box". The genomics part is more solid because we have community derived data formats and data types, and rules for Chado... so it's much easier. But, if we could come up with a list of types for the stock table, and select from those as default content types (that they can choose to use or not) we at least encourage folks to follow similar method you all are using. We probably won't ever have 100% consensus, but with some default content types we can help move people into paths that you all have already blazed.

[laceysanderson]

PR Merged