Create GO-CAM v1.0 landing page for end users

[cmungall]

We need a landing page for GO-CAM, that is designed for users (not curators) to access and download the production GO-CAM models. This would be distinct from the curator landing page at noctua.geneontology.org. This would be on the main GO website (drupal).

v1

by May meeting

• decide on top level URL. page/cam or page/go-cam/ or /page/GO-CAM/
• introductory high level blurb @thomaspd @cmungall
• one sentence on Noctua, with a link to Noctua and to http://wiki.geneontology.org/index.php/Noctua (but emphasize this is curator tool)
• Access
  • SPARQL endpoint (needs example queries, @dougli1sqrd; can recruit @vanaukenk and others to help )
  • API access (v1.1?)
  • Blazegraph dump
• Downloads + docs
  • (non-lossy) OWL, using ttl serialization (all production models combined? use owlzip?)
  • (lossy) cytoscape entity-centric
  • (lossy) cytoscape entities + occurrents (harder to work with but less lossy)
  • (lossy) causaltab - Adding contact info for aruk #413

v1.1

• link for users to browse models in amigo (currently alpha)
• export: biopax? @bgood
• export: openbel
• export: CX

Dependencies

@kltm should we couple to main pipeline or have this be its own stream? We have a separate ticket for the jobs required:

#169

Additional notes

• should we actively push lossy CX graphs to repos like NDex?
• there is a large impedance mismatch going to biopax. My choice would be to target openbel
• I didn't place this in the Noctua1.0 project, but placed in 2018-05 GOC meeting milestone. But perhaps this could all go into a new project?

[kltm]

@cmungall I'm not sure why we'd want it out of the main pipeline, unless we need cycles faster that a day or so. As it stands, mostly of the things needed should be or will be part of the pipeline (expect, of cource, TBD formats, etc.).

[goodb]

As we consider how best to provide end users access, I'd like to suggest thinking about a portion of the Web app driven directly from SPARQL query. This would allow for a flexible UI that really can take advantage of the network structure being assembled both within and across linked go-cams. I think this pattern will likely be of use in Noctua itself as well.

This concept is coming from thinking through how to provide curators access to the knowledge in the Reactome-generated GO-CAMs. In looking at them in Noctua-dev and discussing how curators would want to use them with @vanaukenk , it is apparent that something else that is more flexible and more user-request driven is needed. These models are large and interconnected. The large models don't work well in the editor and its hard to know where exactly one should stop and another one should begin (which makes a lot of sense from the biology standpoint..). As an example, @thomaspd was looking at the mapping of reactome for Wnt signaling - specifically 'TCF-dependent signaling in response to Wnt' go-cam, reactome. He immediately wanted to see the subpathways involved (e.g. WNT mediated activation of DVL in the same graphical context but they are divided up right now into independent, unlinked models, making navigation via Noctua difficult.

Given access to the graph of all models, the UI could grow out from the point of interest as requested by the user. This could be captured graphically in a Noctua-like network view or via other more tabular paradigms. The key is that the user sees as much as they want to see, of what and from where at any given time and no arbitrary lines are drawn around subsections of the knowledge base.

[lpalbou]

If that's ok, I will start working on a mockup of the landing page, just to be clear on what we want (resp. don't want) and how to display it.

Proposed Plan:

• Let's say for this week, it will only be a graphical mockup accessible through the web so that everyone can give its opinions and say what to change / add / remove.
• For the week after, I do agree with Ben that many fields (or even sub-components) from the landing page should be driven by some actual SPARQL query. It would also facilitate the transitioning to a future framework (#399). @goodb @dougli1sqrd can I bother you some time this week and next week about some "statistics" SPARQL queries ?
• See where to go from here, perhaps send this more dynamic mockup page to some friends / colleagues to gather their feedbacks ? To discuss and coordinate with @thomaspd

PS1: @cmungall URL: I would choose /cam since www.geneontology.org is already stating the "go". Also, I would add to the to-do list a "Statistics" section (how many models, what species, how many "annoton" / model, how many relation used for each type, etc)

PS2: @goodb your note on a more interactive / connected graph is quite true and is linked to this issue: #519 . I have worked with D3 in the past so I could come up with some more interactive graph with collapsible nodes (D3 example)... But depending of other projects, It would probably not be for the 1.0 release

[kltm]

@lpalbou The future framework for geneontology/noctua#399 is about reusable components within the world of Noctua, AmiGO, and other places where we want to have separation and components written once and reused. This should definitely not preclude the use of other frameworks other places for unique or one-off page/apps, like possibly a new landing page.

[balhoff]

I agree with @goodb that it would be quite cool for a user to be able to build up a sort of "knowledge graph" that looks across multiple models. One thing to consider is how to represent links across class instances that live in different models. Probably fine at the general knowledge graph level, but as you traverse some class from one model to another, the context may be quite different and so the relationships wouldn't have the same meaning as within an OWL ontology.

[goodb]

@lpalbou two thoughts here. Unless you are very good/fast at web dev is might be faster / more productive to first build a mockup for the design in a tool like https://balsamiq.com versus making something 'real'. Really depends on you and are your skill set, but for me, that has worked very well in the past. Regarding graph view implementations, I'd definitely urge a look at higher level libs e.g. cytoscape.js before making the call to go directly to d3. There is a lot there to take advantage of that you might end up having to re-write in d3. It does have its own problems, but something to look at that we've built for the translator project that does the graph explorer thing with a combo of cytoscape.js on the front end and neo4j on the back is up at https://tkbio.ncats.io/ (its going very very slow today.. but still can work if you are patient). There is code there that might be useful.

@balhoff regarding explorer (maybe but not necessarily graph..) views, its not just the ability to see connections between different models, its control over the that parts of models that you see at one point in time. Loading up more than 7 things at once into a view is very rarely a good idea and happens almost immediately when people get their hands on graph layout tools ;).. For complex things like this interactive, user-centered expansion/contraction is very important to produce one way or another.

[cmungall]

Sorry I should have scoped this ticket a bit better. Let's take ideas for v1.1 (post-May) over to #561 and keep this on what we're doing for May

[lpalbou]

@goodb thanks for the link, I did not know balsamiq, but coding a mockup with angular will not take me long (1-3 hours top). Most of the time is really more on what to show and how, and can we retrieve the data or not.

[lpalbou]

Here is a first graphical mockup: GO-CAM mockup

[cmungall]

Nice!

[thomaspd]

Thanks! This looks great. My main suggestion at this point is to make the download section/links really prominent, maybe by moving toward the top. Also, it would be nice to have a thumbnail of a GO-CAM image in the top box. For the statistics, we should also track the number of triples in the repository.

[pgaudet]

I like it !!!
Just a couple of things:

• What do you think if the link to RO would go to the READme rather than to the repo? It would be more welcoming https://github.com/oborel/obo-relations/blob/master/README.md
• I thought we had decided at the Documentation meeting to call "GO-CAMs" just "GO-CAMs" , not "GO-CAM models" (just to make sure we use the same phrasing everywhere.

Thanks !

Pascale

[cmungall]

Note from hack day:

• don't do pie chart by group; do it by goslim etc

[goodb]

Idea. Show running list of most recently created/modified models, perhaps showing what references were used in the CAM. Users like to read 'the news' and it makes the site feel alive. (like or perhaps even driven by a twitter update feed widget)

[lpalbou]

Thanks for the comments and useful suggestions. I will integrate them in the next mockup, as well as a few others from this morning hack day meeting.

Good news also: when we have reached a sufficiently stable version, Julie M. and Suzanna L. have agreed to show the site to a few biologists that are new to these concepts in order to gather their feedbacks.

[lpalbou]

OK, sorry for the lack of update, but here is the New Mockup Version

Notes:

• Figures will change and/or be completed
• Most of the buttons are functional, although for the moment, you can only download the TTL and JNL archives of GO-CAMs
• The Recent Models section is created from a sparql query to rdf.geneontology.org. Clicking the eye will open the noctua graph version of this model
• New feedback form on the header navigation bar
• New search icon on the header navigation bar to browse the current models (for the mockup, only load a few models)
• The statistics has not been changed yet. Probably to slow to obtain live statistics from the SPARQL endpoint

Additional Notes:

• As this is hosted on https and the sparql endpoint is not in https, the sparql query is actually forwarded through a https endpoint that I have
• I am working on some kind of preview for the models, to highlight what are the species, GPs and BPs involved

[goodb]

@lpalbou looking really good. Some thoughts:

1. I like the image for the GO-CAM Principle except for the bottom part about gp being part of a cellular component. I'm not sure thats the right semantics? e.g. I think generally we want one of the gp-mf boxes to occur_in some CC. But regardless of that, I'd take it out and add in the concept of a BP instead. For me, the essence of a GO-CAM is a set of MFs chained together to enact a BP. If you take your figure and indicate also that gp1->bp1, gp2->bp1, and gp3->bp1 in the left 'disconnected' section, and then add part_of connections from the gp-mf boxes to a new bp box in the middle of the white space that might help complete the mental picture. This is also more inline with the other nice examples for NEDD4 and DLK-1
2. I suspect that @kltm would argue against your direct link to the Noctua editor interface from the recent models collection. His view (if I may) is that the editor isn't optimized for viewing and would thus rather send non-editors to a view that is - e.g. a static pathway view like this one. From there, they can access the edit button that would bring them into the Noctua interface (if they are allowed to enter). I think that once the static view(s) are ready this makes a lot of sense. Basically like sending people to the rendered Wikipedia article rather than directly into the Wikitext editor.
3. "Documentations" -> Documentation, "Feedbacks" -> "Feedback"
4. I didn't see the feedback form until I went searching specifically for it. If its a priority to get some responses from users that would need to be more prominent. Probably also need to guide them about what specifically you are interesting in hearing from them about. If its just a general comment box I might leave it under a Contact menu.
5. I'd mention that they are constructed in OWL somewhere. (I'd also like to say that since they are OWL they could be downloaded and then loaded into Protege or other OWL capable tools.. but until the neo import statement is removed or somehow fixed that isn't really true for most people...)
6. Previous comments hold about the content in the statistics box being more driven by the semantic content then contribution counts. I might even just take that box out for now as there isn't a lot of real content yet.

[cmungall]

I'd mention that they are constructed in OWL somewhere. (I'd also like to say that since they are OWL they could be downloaded and then loaded into Protege or other OWL capable tools.. but until the neo import statement is removed or somehow fixed that isn't really true for most people...)

I think there are multiple approaches to this depending on the use case.

We can provide a pre-generated combined OWL file with an import module merged in, that would allow for cross-model exploration.

For people who want to look at individual models in Protege, we can provide a docker container that makes a module and writes a catalog file. But really Protege needs better dynamic module creation abilities.

[lpalbou]

@goodb Thanks for the comments !

A few answers/comments:

• Figure & partOf: in GAF (left part) you only know that GP2 is located in CC2 and in the GO-CAM you could use either partOf or occurs_in, but occurs_in is reserved when we know the activity (a specific MF) occurs_in that CC2.. which I don't think we can infer from those GAF statements ?

• Figure & BP: totally right ! I think in my mind I was already seeing the GO-CAM as a BP or sub-BP, but this is not explicit

• @kltm can we link to this view even though it's still considered alpha ? there is also this other view that was discussed with @thomaspd . Anyhow, I also plan on experimenting with other representations (cf graph representation discussion go-site#561)

• feedback: yep, I put it there for the tests but it's not quite noticeable.. My guess is to include similar "feedback button" on specific views (like when browsing, viewing or editing a model) to either send a feedback, a suggestion on a model or why not, ask for further information regarding the model ?

• OWL: it will be in the documentation but I would also like to have some notes/references on it in the introduction or statistics section.

• statistics: yep I did not touch this part, however I do think there are a few useful stats that we can provide & keep track, both on the ontologies (GO & RO) and on the biological statements (e.g. total GO-CAM triples, triples / model, etc).

[kltm]

@lpalbou Go ahead and like "that view". I will update it a little bit so that it is a little less dumpster fiery and pull in the pathwayview.

[kltm]

@lpalbou To clarify for future historians: I am referring to the tomodachi URL. That is a temporary "dev" URL until AmiGO production is transferred to Berkeley, at which point we would change it.

[lpalbou]

@kltm OK, however I just tried the tomadachi URL and for the moment most production models are not accessible through this pathway view: ex 1, ex 2, ex 3. Anyhow, I have a shared service to handle these URL, so it will be easy to change.

[kltm]

That is correct--this is an issue with the loader: owlcollab/owltools#212 that @yy20716 is currently looking at, mentioned yesterday.

[cmungall]

Let's come up with another name than "that view".

We can subdivide graphical views into 3 categories based on their content

• complete GO-CAM (ie Noctua "canvas"/GE). Shows everything
• entity-centric (i.e. Noctua "Pathway view"). Has GPs, no activities/processes
• occurrent-centric (i.e. "that view" currently in amigo/model). No GPs.

This is not exhaustive as novel combinations are possible.

We can also have a separate orthogonal partition based on jsplumb vs cytoscapejs etc; whether nesting is employed etc.

Different views serve different purposes (although I'm not sure there is a use case for an occurrent-centric view, I would move to deprecate this).

Entity-centric views are very familiar and will give people the warm fuzzies, as they will think of every other interaction display they have ever seen. This view will obviously scale better to multiple models or large models. But these are problematic if the goal is to demonstrate clearly what a GO-CAM is, because it excludes the GO terms. We run the risk of confusing people and having them think we are building Yet Another interaction database.

For pedagogic purposes I would argue for having some form of complete view as primary while we are still in the process of rolling out the concept to the community, when showing an individual model. Of course, we will soon want to show combined models in which case some form of reduction at the zoomed out level will be required.

We used to have a complete view rendered using graphviz in amigo, I rather liked that, not sure what happened to that.

[goodb]

I think that as a first priority we need a stable URL for each model that resolves to a page with multiple ways to view that model including one that is the editor (including access control of course). Perhaps before (or while) digging into building the various views and arguing over which one shows up as the default it would be good to get the URL patterns in place and stable so that links could start being dependable. Then we can iterate indefinitely on the specific views shown - including linked-data views 'shown' to RDF-aware software and content shown to search engines.

(although I'm not sure there is a use case for an occurrent-centric view, I would move to deprecate this).

I actually found this the most helpful view for understanding the go-cam model style. It helped break me free from the inclination to see entity-centric interaction maps. In separate discussions with Huaiyu he pointed me to http://sbgn.github.io/sbgn/ and suggested that their Activity Flow pattern was the best match to the go-cam modeling paradigm. And activity flow is pretty much what I see in "that view". So anyway I wouldn't drop it from the list of possible views just yet.

[lpalbou]

Hi, this is the most recent update of the GO-CAM site:
http://www.geneontology.cloud/

Notes

• I have reserved geneontology.cloud
• the files are now deployed on S3 instead of firebase (easily changed)
• I have started to make the site responsive, to work also on mobiles & tablets
• You can browse models and have a preview of the BPs and MFs
  note: I am facing possibly some data model inconsistency on the SPARQL endpoint such as #185, hence some fields are missing
• You can also access a user page with some information about the users
  e.g.: # models, # processes & ifs covered, etc
• Social sharing links are now active

WIP

• Browsing Models Issues: BPs, MFs not always showing
• User Page: some models and/or BPs/MFs not shown (cf triple store & SPARQL)
• Group Page: will be the same logic as for User Page
• Having a div with checkboxes to select which fields to display in the table
• Multiple ways of viewing a model (e.g. graph, pathview, etc)

Additional Note

There will also be an "expert page" for each biological process. The idea is to give access to the list of experts (both curators and authors from articles) working on each specific biological process.

[balhoff]

@lpalbou looks great! I would replace "downloaded (as ttl)" with "downloaded (as RDF Turtle)".

[ukemi]

This looks nice. I am going to modify the Dlk1 example. I notice that it does not include the asserted regulatory processes.

[balhoff]

What is included in the 20 MB GO-CAMs.ttl in the Archive downloads? Are they just mixed together? It might be nice to replace that with an N-Quads file which can maintain the graph separation. Or, use rdfs:isDefinedBy to connect individuals and/or axioms to the ontology nodes.

[balhoff]

You can browse models and have a preview of the BPs and MFs
note: I am facing possibly some data model inconsistency on the SPARQL endpoint such as #185, hence some fields are missing

@lpalbou can you explain how #185 is impacting what you're doing?

[goodb]

@lpalbou it looks good. Probably a good time to circle back with @jmcmurry about getting it in front of some real users. Would be helpful for those tests to write down the specific use cases the design is intended to support to direct and quantify the user evaluation. (e.g. bio-user: 'find a model with a particular gene in it', info-user:'download sif file', etc.)

[vanaukenk]

@lpalbou Yes, this looks really nice.

I have a few questions about the NEDD4 example.
There are differences between the NEDD4 example shown on the landing page and the corresponding NEDD4 example shown in Noctua:

http://noctua.berkeleybop.org/editor/graph/gomodel:5323da1800000002

For example, the relationship between NEDD4 ligase activity and the ubiquitin-dependent protein catabolic process is different and the example uses the has_substrate relation rather than has_input.

What is the source of the example model?

@thomaspd - should I update the NEDD4 example in Noctua and add appropriate evidence?

[thomaspd]

Thanks, updating the example would be very helpful! The source is https://www.ncbi.nlm.nih.gov/pubmed/17996703

The has_substrate relation is, I think, not the official name, but it will be more meaningful to users.

[vanaukenk]

Thanks @thomaspd - I will align the landing page and graph editor NEDD4 models and let you know if I have any questions.

Wrt the 'has substrate' relation, I agree that it is more meaningful to users, but note that it is neither in RO nor gorel as a name or id, respectively. In gorel, 'has substrate' is a narrow synonym of 'has direct input', and in RO there is a comment under 'has direct input' that the term may be obsoleted and replaced with 'has substrate'.

http://www.ontobee.org/ontology/RO?iri=http://purl.obolibrary.org/obo/RO_0002400

http://viewvc.geneontology.org/viewvc/GO-SVN/trunk/ontology/extensions/gorel.obo?revision=37194&view=markup

I raise the issue because I have gotten feedback from curators that it is difficult to know which relations are the right ones to use and so I think we need to be consistent with what is used in Noctua vs what is displayed vs what is in the GPAD output, etc.

What is more meaningful to users is probably more meaningful to curators, too!

[cmungall]

DavidOS and I worked on this proposal for has-substrate
https://docs.google.com/document/d/1QMhs9J-P_q3o_rDh-IX4ZEnz0PnXrzLRVkI3vvz8NEQ/edit

oborel/obo-relations#230

[lpalbou]

Thanks for the feedbacks 👍

Some answers

@balhoff:

• RDF Turtle changed ok.
• TTL: I extracted the production models from (https://github.com/geneontology/noctua-models) and merged them using the Apache Jena/Riot tool, let's discuss this on Gitter.
• Changes to annotation files submitted by GOA #185 (of minerva, not go-site): let's discuss this on Gitter, but a same query on different models does not gave me access to the same type of information

@ukemi let me know when the model is updated, and I'll change the example on the main page

@goodb yes, but before showing to real users, I would prefer to correct a few things first (e.g. missing BPs, MFs, update the REST endpoint, create the SPARQL example page, update some documentations). Let's give us one week to discuss and implement the changes we want before.

@vanaukenk @thomaspd thanks for the feedbacks on NEDD4. Indeed has_substrate is more meaningful to users but has_input is the true relation and it's already difficult for curators to select the right relations. Let me know which you prefer or what modification you would like.

GO-CAMs Carousel

It would be great if the community could select 2-3 additional GO-CAMs or create new schemas / animations to:

• explain the main differences with standard GO annotations
• highlight GO-CAMs on some high-impact processes

Usage Scenarios

I know some of you have been working on scenario of usages, could you share the link(s) with your findings here, so I can highlight these usages on the main page ?

[ukemi]

The model is updated.

[vanaukenk]

@lpalbou @thomaspd

I've updated and fully referenced the NEDD4 model:
http://noctua.berkeleybop.org/editor/graph/gomodel:5323da1800000002

I made some slight changes to the model based on the data in the paper, but overall I think it still reflects the biology as intended. I also added supporting evidence statements to each edge for reference.

Paul, we should go over the model together to make sure you're okay with the final version. Thx.

[lpalbou]

Hi, a few updates:

• new version online, still at geneontology.cloud. You should now be able to search any BP or MF in all current production models through the browsing page (using the filter)

• Next, I'll add the same feature for GPs and possibly some icons to depict the species represented in each model. I still have to correct the User page (some data missing) and do the Group page too.

• After that, I'll start making an intuitive and interactive page to learn about our data model and SPARQL (how to interrogate our data). This will be useful for reusability throughout the MODs (AGR)

• @ukemi I have updated the model on the main page

• @vanaukenk @thomaspd do I change the model on the main page to use the same exact vocabulary as the noctua model ? or since this is a schema, do we stick with simpler terms ?

Also, since we are able to display 6 models in the main page carousel, I thought it may be interesting to start with one model from each MOD, what do you think ? If you agree, perhaps each MOD could select a specific model to be presented on this carousel ?

Thanks

[lpalbou]

Live on geneontology.org/gocam

[Edit]

Known Current Bugs

• User Page GPs: my SPARQL UserMeta query which uses enabled_by also retrieve some GO-terms
• User Page GPs: when clicking on a mouse GPs, due to the duplication MGI:MGI in the triple store, does not point to a valid URL. Temporary fix on the GO-CAM site code to remove the duplicate (will correct that later in the day)
• Number of GO-CAMs are not quite the same between the User Page and the Browse Page with User filter
• Browse Page - Users: in the case of S.Toro, her name is sometime displayed twice, seems to be due to the fact the model was credited to 2 affiliations (using providedBy). The SPARL query used

Furthermore, some queries can further be optimized, in particular the GroupMeta SPARQL Query.

I also have to update the swagger documentation of the current REST API

[lpalbou]

New version online, including some design updates to highlight the browsing capabilities and make the site more interactive.

Technical Update

• Fixed a few bugs, started to clean up the CSS and will make a necessary transition to SCSS.
• Should now be fully responsive (tested on android and iphone, 1 android tablet)
• Browser compatibility (2 osx versions with chrome, Firefox, safari); win10/msedge + win8+win7/IE11 thanks to polyfills). Does not work win win7/IE10.

The site is also now fully https (distributed through CloudFront with SSL certificate)

Note: pages are served using the following REST API https://api.geneontology.cloud (e.g. https://api.geneontology.cloud/models)

[jmcmurry]

what is the plan for getting this in front of users?

[kltm]

We're currently trying to work out things like harmonization and deployment, started here:
https://github.com/orgs/geneontology/projects/22

[lpalbou]

Well, it's still unclear to me what you would want for harmonization (we have no particular reason to rewrite the gocam site in vue2; we can harmonize the styling but with what ? do we want amigo styling everywhere ? gocam styling everywhere ? or something else to use also on the future go site ?) and deployment (the site is hosted on S3 + Cloudfront with SSL certificate from geneontology.cloud while waiting for a full transition to geneontology.org/cam or /gocam and the data is fetch directly from the production rdf endpoint, so any time there is a new GO release, the site is automatically updated).

Not to say there is nothing to improve: for instance the documentation on the wiki is still a problem, I could fetch the data from BioLink once my API is transferred and deployed there, we could create additional views, as suggested by Pascale, more biologically oriented, to present users with large and common families of processes, as another way to explore the current gocams, etc. But the gocam site is up and running since the NYC meeting and got a few improvements since (multiple different ways to search, also showing PMIDs, MF, CC, GPs, etc).

[goodb]

By “get in front of users” I believe she was referring to user testing, not deployment or implementation details. Julie, please correct me if I’m wrong.

…

On Aug 9, 2018, at 6:11 AM, lpalbou ***@***.***> wrote: Well, it's still unclear to me what you would want for harmonization (we have no particular reason to rewrite the gocam site in vue2; we can harmonize the styling but with what ? do we want amigo styling everywhere ? gocam styling everywhere ? or something else to use also on the future go site ?) and deployment (the site is hosted on S3 + Cloudfront with SSL certificate from geneontology.cloud while waiting for a full transition to geneontology.org/cam or /gocam and the data is fetch directly from the production rdf endpoint, so any time there is a new GO release, the site is automatically updated). Not to say there is nothing to improve: for instance the documentation on the wiki is still a problem, I could fetch the data from BioLink once my API is transferred and deployed there, we could create additional views, as suggested by Pascale, more biologically oriented, to present users with large and common families of processes, as another way to explore the current gocams, etc. But the gocam site is up and running since the NYC meeting and got a few improvements since (multiple different ways to search, also showing PMIDs, MF, CC, GPs, etc). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[lpalbou]

@goodb yes, sorry, I was more answering Seth than Julie.

The site is here and works. I have gathered feedbacks and improvement requests from curators, but it's indeed not sufficient and does not cover all usages. Do you think you could help, Julie, in gathering some additional user feedbacks about what they like / don't like / what they would want or expect ?

I do think we may need the additional page suggested by Pascale, to browse models based on common families of processes (e.g. transcription, etc).

[kltm]

Aged out