Showcase backlog

Version 279 by Marco Roos
on jul 25, 2012 18:51.

<< Changes from 278 to 279

compared with

Version 280 by Marco Roos
on jul 25, 2012 19:36.

Changes from 280 to 281 >>

Key

This line was removed.

This word was removed. This word was added.

This line was added.

Changes (13)

View Page History

...

{jiraissues:url=https://jira.man.poznan.pl/jira/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?jqlQuery=project+%3D+WFE+AND+issuetype+in+%28Story%2C+%22Technical+task%22%29+AND+%22Epic%2FTheme%22+%3D+WFE-238&tempMax=1000&os_username=wf4ever-reader&os_password=wF_iSSue\|columns=type,key,summary,assignee,priority,status,created,timeestimate}

...

h2. 3. Mining Decay from myExp (Stian)

...

Including various IMPACT workflow decays.

...

h2. IN PROGRESS \[SPRINT4-5\]. 9. Astro-Taverna wishlist (Susana)

*No dependencies*
* Providing additional functionality
* Presentation of workflow results in SAMP and VO Table
* Time-boxed development (implement what we can in the time).

Participants: *Susana*, Pique, Stian, Juande

Sprint: 2 (2012-03-13)

*{+}Prioritised and grouped list of the user stories belonging to this showcase{+}{*}*:*

*(1) Connection with the Virtual Observatory Services: Search and use VO services* *+(Accomplished in{+}* *+[SPRINT 2|http://www.wf4ever-project.org/wiki/display/docs/Showcase+catalogue#Showcasecatalogue-Showcase9.AstroTavernawishlistSprint2%28Susana%29]+* *{+}and in{+}* *+[SPRINT 3|http://www.wf4ever-project.org/wiki/display/docs/Showcase+catalogue#Showcasecatalogue-Showcase9.AstroTavernawishlistSprint3%28Susana%29]+{*}{*}+)+*
# [WFE-192|https://jira.man.poznan.pl/jira/browse/WFE-192]: As an astronomer user of Taverna I want to query the Virtual Observatory registry, so that I can know which services are suitable for my workflow
# [WFE-193|https://jira.man.poznan.pl/jira/browse/WFE-193]: As an astronomer user of Taverna I want to visualize the list of Virtual Observatory(VO) services fulfilling a query to the VO registry, so that I can choose the most suitable for my workflow
# [WFE-195|https://jira.man.poznan.pl/jira/browse/WFE-195]: As an astronomer user of Taverna I want to inspect information related each one of the VO services fulfilling a query to the VO registry, so that I can know how to use this service (e.g, the inputs needed)
# [WFE-196|https://jira.man.poznan.pl/jira/browse/WFE-196]: As an astronomer user of Taverna I want to add a chosen VO service to my workflow, so that I can use the data extracted from the VO service in my workflow.

*(2)VOTables management:*
# [WFE-203|https://jira.man.poznan.pl/jira/browse/WFE-203]: As an astronomer user of Taverna I want to send the VOTable obtained as a result of my workflow to Topcat, Aladin or other SAMP-VO software, so that I can perform advanced scientific analysis provided by specific VO software.
# [WFE-197|https://jira.man.poznan.pl/jira/browse/WFE-197]: As an astronomer user of Taverna I want to use local services for extracting columns, rows and/or one or several cells from VOTables, so that I can use pieces of a VOTable as inputs for components of my workflow.
# [WFE-198|https://jira.man.poznan.pl/jira/browse/WFE-198]: As an astronomer user of Taverna I want to extract the semantics (utypes) of VOTables columns, so that I can select and extract columns by their utypes
# [WFE-199|https://jira.man.poznan.pl/jira/browse/WFE-199]: As an astronomer user of Taverna I want to extract the description/metadata of VOTables, so that I can know some specific information about the data and so manage them properly
# [WFE-200|https://jira.man.poznan.pl/jira/browse/WFE-200]: As an astronomer user of Taverna I want to see the VOTable obtained by a Virtual Observatory service component of my workflow as a spreadsheet in the Results perspective of Taverna , so that I can visualize better the VOTable data.

Documentation: [docs:SAMP]

*(3)Database connection:*
# [WFE-202|https://jira.man.poznan.pl/jira/browse/WFE-202]: As an astronomer user of Taverna I want to have a direct connection to my database so that I can create, retrieve, update, and delete (CRUD) my own data records with a workflow.

...

*(4)Astro local services:*
# [WFE-201|https://jira.man.poznan.pl/jira/browse/WFE-201]: As an astronomer user of Taverna I want to have a local services providing standard functions for Astronomy (e.g. coordinates and physical properties transformations) so that I can avoid developing my own error-prone local services

h2. 10. Reviewing an RO (Graham)

This showcase concerns information quality through the use of research objects in the process of selecting and reviewing information from a body of ongoing work for publication, in the process undertaking a series of review and refinement steps that lead to a published RO or paper.  As such, it is concerned with the creation of a "Publication RO" from a "Live RO".

The project deliverables for M20 include "Design, implementation and deployment of Workflow Integrity and Authenticity Maintenance components", with a further deliverable under this description in M32. It is essentially about maintaining the quality of recorded and reported scientific research. A reasonable goal for the M20 deliverable is to have a working model and tools for assessment of quality. A common tool in quality management is the checklist: a list of items which need to be performed or reviewed for a product or service to be considered of acceptable quality. The RO review showcase is aimed at supporting the use of checklists, specifically in the process of preparing publication materials from researchers' day-to-day working notes and datasets. We are working towards modelling checklists as minimum information models, against which a Research Object can be evaluated. This work is closely based on an RO evolution, which itself defines a framework within RO provenance (meaning the provenance of an RO as a whole, rather than its individual components) may be expressed.

The entire showcase is quite large and will probably extend over several sprints, but there are a number of incremental steps which we think can each add some value for researchers.
* What does live, archived and published RO mean in a review process?
* See [http://wf4ever-project.org/wiki/display/docs/Review+and+publication+with+ROs] for scenario and discussion
* The preparatory planning has been continued at [https://www.pivotaltracker.com/projects/495929]

The showcase will involve or depend upon work in the following areas:
* RO model and RO construction tools
* Model and tools for structured annotations
* RO checklist/completeness evaluation
* RO model and tools supporting and managing RO evolution
* RO model visualization
* RO checklist visualization

Participants: *Graham*, Marco, Pique, Raúl, Oscar..?

JIRA: [WFE-183|https://jira.man.poznan.pl/jira/browse/WFE-183]

h2. 11. Training with an RO (Pique)

...

These models overlap in many cases. They should converge in the RO model and separated in different modules.

...

+[+http://www.wf4ever-project.org/wiki/display/docs/RO+Model+Outstanding+Issues+|http://www.wf4ever-project.org/wiki/display/docs/RO+Model+Outstanding+Issues]+

Members: Stian, Dani, Raul and Graham.

h2. 23. Integration with DataFlow

DataFlow: [http://www.dataflow.ox.ac.uk/] provides a two stage data management infrastructure. DataStage allows local data management, while DataBank is a repository allowing preservation and publication of assets. Communication between the two is via the SWORD protocol, using a data packaging format based on BagIt.

This showcase would provide integration between Wf4Ever and DataFlow through two routes:

# The adoption of SWORD(2) as the the Research Object Digital Library interface protocol
# The adoption of the Wf4Ever Research Object Model as an option (not necessarily a replacement) for submission of data packages to DataBank.

This would bring potential benefits to wf4ever including

* demonstration of interoperation with other systems
* impact
* use of "standards"
* more users

and benefits to DataFlow including

* interoperability
* impact
* richer metadata

Note that 2/ would require effort from DataFlow, so would need negotiation/agreement with external parties.

{color:#ff6600}Marco: LUMC is interested in this Showcase as user. At this time we have no opinion about DataFlow and/or DataVerse, because we know too little about them.{color}

h2. 24. In line RO Annotations (Marco)

{color:#000000}Make it possible to have people annotate scripts (or other 'unstructured workflows') inline, such that an RO manifest could be generated from that, similar to how JavaDocs are made. Motivation: \(i) some see a script as a workflow too, but if the script is a black box for supervisors/reviewers/readers than this is not good science, (ii) in practice, workflow languages will not replace specialized scripting languages in all cases, (iii) i{color}{color:#000000}f we can provide guidelines and tools for researchers to produce ROs from their own favourite tool, we save an effort to change habits.{color}

{color:#000000}Example scenario:{color} {color:#000000}{_}A bioinformatician who is very quick with R, a highly popular and powerful language/tool for statistics. Currently, we more-or-less force her to make Taverna workflows so that the underlying workflow becomes explicit and can be used beyond her own analysis, even if the method would be purely statistical. Instead of designing a workflow, she can also make a RO out of the R scripts by putting in annotations according to RO guidelines and a RO command line tool. The minimal recommended set of annotations helps her create snapshots for supervisors and reviewers (i.e. for publication). _{color}

h1. Recommender System Related Showcases

h2. 25. User Feedback Handling

As a researcher I want that the recommender system to take into account my feedbak so that it can provide better tailored recommendations for me.

Possible sprints:

\--User feedback representation and recommendation provenance representation

\--User representation and handling

\--Recommendation algorithms parameterization

h2. 27.B Scientific Content Recommender

As a researcher I want the recommender system to provide scientific resources so that I can be able to use  in my research and as .

As a researcher I want the recommender system to provide content-based recommendations based on the way that search and retrieving of scientific content is already performed by researchers, allowing search in fields such as authors, abstract, keywords, publication dates, etc.

Work description:
* Inclusion of new scientific content sources: More precisely:
* OAI-PHM sources
** Read and analyze “The Open Archives Initiative Protocol for Metadata Harvesting”
** Include the two first candidate sources:
*** CiteSeerX
*** Arxiv.org
* LinkedData sources •Nature
* Update of the current index:That includes:
** Update of the index structure
** Update of the indexing tools 
* Creation of the new recommender as an extension of the already existing WorkflowKeywordConteBased recommender

{jiraissues:url=https://jira.man.poznan.pl/jira/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?jqlQuery=project+%3D+WFE++AND+component%3D%22Recommender+service%22+AND+fixVersion%3D%22Sprint+3+%2804-2012%29%22&os_username=wf4ever-reader&os_password=wF_iSSue\|columns=type,key,summary,assignee,priority,status,created,timeestimate}

h2. 51. Collaboration Spheres Visualization (Esteban)

This showcase is the continuation of the showcase 45 and its main goal is to define the technical descriptions and implementation of that showcase. This technical study and implementation will allow the visualization of the relations between U-U, U-RO, RO-RO based on the recommendation API (recommendations of users or ROs) and the RODL API (users and ROs info) which provide the implicit and explicit data neeed for the visual metaphor described at showcase 45. 

The main outcomes of this showcase will be:
* Technical description of components to be used
* Iimplementation of the visualization component
* Description of the format to be used for description of the visualization
* Representation of the data obtained from the RODL and recommendation APIs

h2. 67. Integration Prerequisites Showcase

The objective of this showcase is to enable a better logging, debugging and interfacing infrastructures for the Recommender Service in order to enable its integration with myExperiment and the Collaboartion Spheres.

More precisely:
* Logging: Provide a significant logging mechanism (specially for the exchange of messages in the REST interface)
** Learn to use state of the art logging framework
** Implement the necessary logging code for the Recommender Service
* Debugging: Achieve graphical debugging using the Gephi environment
** Learn Gephi internal format
** Generate the Gephi representation
** Add operations to the interface to allow remote debugging
* Interfacing:
** Check myExperiment needs
** Check get the lastest updates in the myExperiment API 
** Check Collaboration Spheres needs
** Implement myExperiment requests
** Implement Collaboration Spheres requests

Participants: Rafa, Don (myExperiment), Esteban (iSOCO)

h1. Provenance showcases

These stories are proposed as the ones which make use of provenance information (there are many others but they are mostly different interpretations of these ones or with some small "minim" changes):

h2. 28. Workflow reuse

*Story*: As *a scientist I want to do a new research so I look for ideas in other authors work* and once I have found an interesting RO (it could be done by the recommender system) I want to (even if the workflow is not working anymore) understand how it used to work, *replay,* (provenance of the workflow results) and also uses the evolution of the RO (provenance of the RO) so I can adapt or reuse some parts of it for my new scientific experiment

h2. 29. User's view on provenance

*Story*: As a scientist (maybe a researcher, a supervisor, or a reviewer) who reviews some workflow-based science, I want to see details of and rationale for the methods and input datasets used, including provenance (where they came from, who and what produced it), why it was used, comments for readers, and any other relvant details, so that I can understand and evaluate the suitability of the procedures used and consequently the credibility of any results generated. *(This is related with the provenance of the resources of the RO)*

{color:#ff6600}See the table in {color}{color:#ff6600}[http://wf4ever-project.org/wiki/display/docs/User+view+on+Provenance|docs:User view on Provenance]{color}

*Validation*
    * How many items can we answer using wf4ever-compliant/recommended provenance?
    * How would users fill the missing gaps?
    * How much of this is represented in the RO quality checklists?  Should it be?

h2. 30. RO citation

* *Social credit and authorship:* as a scientist it is very valuable to have credit in the community keeping track of the access to the RO and also every citing in other places to our RO.
** As a *scientist*, I want my *ROs to be citable*, so that others can cite my ROs
** As a *scientist*, I want any *access to my ROs to be tracked*, so that I can gain credit in the community 
** As a *scientist*, I want any *citation to my ROs to be tracked*, so that I can gain credit in the community

h2. 31. Reproducibility

{color:#000000}{*}Story{*}{color}{color:#000000}: As{color} {color:#000000}{*}a scientist who want to reproduce{*}{color} {color:#000000}{*}some results{*}{color}{color:#000000}, but a different result was produced, I want to{color} {color:#000000}{*}have explanations about why this happened{*}{color} {color:#000000}(e.g. the re-execution happened on a different machine, bad curated services, ...),{color} {color:#000000}so that I can understand why I can no longer reproduce the results.{color}

h2. 38. Provenance interplay

It has been detected at provenance team discussions that provenance information crosses many different WPs and there is  a need to identify exactly how the provenance is related with them and at what specific points.

This story has as a main goal to find those relations and detect how the results of other WPs are involved into the provenance work which is being done.

Some related issues can be:
* Integrity and Authenticity criteria (at least completenes and stability )
* Workflow decay / Workflow Lifecycle
* Taxonomy of RO evolution
* Taxonomy of repair and diagnosis
* RO specs

h2. 74. PROVO export in Taverna

Provo is now stable, we need to be able to export PROVO compliant provenance from within Taverna.

h1. Other Showcases

h2. 33. Structuring research as Research Objects in a local organisation (Marco)

The motivation for this Showcase is to allow researchers to structure and annotate Live ROs and RO snapshots before it leaves the local organisation. Some institutes or researchers will or can not allow unpublished material to leave the local organisation, or may prefer to keep their own library 'in-house'. We suppose that this could be a straightforward copy of wf4ever (later myExperiment), but in theory organisations could extend it as they wish.

By this showcase we demonstrate reuse of wf4ever preservation tooling by third parties. In practice, organisations may choose to use a repository in the cloud, provided that it has the necessary access control. The strongest access control would be functionally equivalent to keeping it local. (NB keeping it local is not a goal in itself, access control and long-term maintenance of data are).

LUMC has developer support available for this Showcase in the second half of 2012.

h2. 34. Access control (Pique/Marco)

ROs and their parts have different access control settings, depending on its type (Live/Supervisor-Snapshot/Reviewer-Snapshot/Archived/Published) and the wishes of users and organisations. The access control model of myExperiment is a good starting point, but it lacks 'available upon request' and 'free to use, but not anonymous'. For paranoid scientists we should perhaps think of a 'unshare everything' option.

h2. 35. RO Guidelines / RO Primer for Users

Example 'instructions to authors' for researchers who wish to structure their work and prepare it for preservation and publication. I propose that we create technical descriptions (for organisations/researchers who wish to make their own digital ROs), and user descriptions (on how to use the tools, how to annotate, how to generate and use checklists, in general how to make a high quality object ready for peer review).

h2. 41. Understanding/guessing how scientists can/would can/would browse and query Research Objects

The objective of this showcase is to investigate mechanisms that can be used to potentially used to browse and query research objects.

The intension is not to identity the query language, e.g., SPARQL, that can be used for querying research objects. Rather, the focus is on investigating the means that can be used by scientists to browse, explore and identify the research objects of interest. This showcase include the following tasks:

\- Identify the literature (papers) that need to be examined.

\- Read the papers, this task will be shared among the members of the showcase.

\- Write a short survey on the outcome, which summarize existing mechanisms that are relevance, but also identify the problems that are not addressed by the state of the arts if any.
\\

Proposed team: Khalid, Dani, Jun, Pique, ...
\\

h2. 42. RO Scalability Issues

The objective of this showcase is to investigate scalability issues that may hinder the adoption of research objects. As the number of research objects increase, one would expect that we will run across scalability problems. In particular, the outcome would be a survey that show the means that researchers in the workflow, provenance and data management fields adopted to overcome scalability issues.

Tasks:

\- Identify RO scalability bottlenecks

\- Identify the papers that we need to read to learn more.

\- Write up of a survey and directions that can be adopted to address RO scalability problems.
\\

Proposed team: Khalid, Dani, Jun, Oscar,

h2. 43b. Follow-up Best Practices for developing workflows (43) - Mapping to wf4ever artefacts

(submitted by Kristina and Marco)

See [Showcase catalogue Nr 43|http://www.wf4ever-project.org/wiki/display/docs/Showcase+catalogue#Showcasecatalogue-Showcase43.BestPracticesfordevelopingworkflows%28Kristina%29] for the 10 best practices.

How does w4ever help users follow best practices?

Suggested mappings:

*   Decay taxonomy
*   Evolution of workflows
*   Provenance
*   _More?_

 NB For some wf4ever artefacts, the conclusion may be that the mapping is not useful.

(submitted by Kristina and Marco)

See [Showcase catalogue Nr 43|http://www.wf4ever-project.org/wiki/display/docs/Showcase+catalogue#Showcasecatalogue-Showcase43.BestPracticesfordevelopingworkflows%28Kristina%29] for the 10 best practices.

How does w4ever help users follow best practices?

Suggested mappings:

*   Decay taxonomy
*   Evolution of workflows
*   Provenance
*   _More?_

 NB For some wf4ever artefacts, the conclusion may be that the mapping is not useful.

h2. 44. Workflow processes recommender (Esteban)

As a researcher I want to be assisted, during the designing process, by previous designs and their statistical properties. This assistant recommends next processes based on historical built workflows information. The recommendation can be done for next step, or taking into account two, three, ... steps forwards.

h2. 46. Continuation of checklist evaluation work (Graham)

This is a continuation of work stated in showcase 37.

This is related , more or less,to the following showcases:

* 10 (reviewing with ROs)
* 22 (RO provenance querying)
* 32 (User view of provenance), and maybe others.
* 40 (Epigenetics and Huntington's Disease experiment RO)

Planning for this is at [https://www.pivotaltracker.com/projects/495929#] (see epic label ('checkro'))

Current goals for this showcase are:

* Checklist evaluation to support decay analysis ([https://www.pivotaltracker.com/story/show/27446779])
* Checklist evaluation involving multiple ROs ([https://www.pivotaltracker.com/story/show/28487405])
* Checklist evaluation for completeness of provenance information ([https://www.pivotaltracker.com/story/show/27444947])

Participants: Graham; for review/feedback: Jun and, as available, Marco, Kristina

Outcome: revised RO-manager software, checklists and ROs for testing

h2. 69. Video generation for demos (???)

*What:* Generate videos about demos, for external and internal consumption, and upload in Youtube Wf4Ever account or Vimeo account.

*Whom*: *Oscar*, Jose, Jun, Dave.

h2. 53. Nanopublications and Research Objects

(submitted by Marco)

Nanopublication is a mechanism to incentivise sharing (scientific) data. The motivation originally came from text mining, considering how silly it is to make a discovery, write about it in a wordy publication, and then use text mining again to extract the discovery. Nanopublications use a minimal Semantic Web model that captures a (scientific) assertion, the provenance of the nanopublication, and attribution to build one's reputation. Nanopublications focus on data or knowledge ('factoids'), whereas Research Objects focus on the method.

This showcase is to investigate the combination of Nanopublications and Research Objects, the mapping of the two Semantic Web models, and identification of how their combination would be mutually beneficial.

More information [here|docs:Showcase 53 Nanopublications meet Research Objects].

References:

[The Anatomy of a Nanopublication, Paul Groth and Andrew Gibson, Jan Velterop|http://iospress.metapress.com/content/ftkh21q50t521wm2/]

[The value of data, Barend Mons et al.|http://www.nature.com/ng/journal/v43/n4/abs/ng0411-281.html]

...

h2. 71. Categories upper layer for RO Model

...

Whom: Khalid, Julian, Dani, Stian, Piotr, Pique, Marco/Kristina

...

h2. 70. Workflow decay actions

Task 1. Collect examples and generate corresponding ROs for the RO testbed (José Manuel, Dani, Carole (from Biovel), Marco (maybe some))

Task 2. Mockup of how this is presented to users (think about which types of user roles - users, curators, etc.)

Task 3. Implementation of tests (check column). Identifying information/metadata that is needed. Identifying checks to be done. Identifying how these would relate to the user interface that has been mocked up

Task 4. Final integration that also shows the manual repair 

h2. 75 Deliverable D3.2 showcase

A showcase with all the activities related with the writing of deliverable D3.2.

Participants: Rafa, Raul, Esteban

h2. 76 Deliverable D1.4v1 showcase

A showcase with all the activities related with the writing of deliverable D1.4v1.

Participants: Raul, Piotr, ...

h2. 77 Deliverable D1.2v2 showcase

A showcase with all the activities related with the writing of deliverable D1.2v2.

Participants: Raul, Piotr, ...

h1. myExperiment Integration

h2. 20. myExperiment offer a RO API or export

*What*: export myExp packs into ROs. Part of the effort towards a million ROs\!

*Members*: ???

h2. 52. Initial integration of recommender subsystem with myExperiment

*What*:First pass integration of recommender subsystem directly into myExperiment (not via wf4ever architecture at first???)

*Members*: Rafa, Don, ???

h2. 59. Grounded RO-enabled myExperiment case studies from ADS, Galaxy and Biovel

These are three very specific projects using the RO-Enabled myExperiment. Using them as case studies will help us to understand better the kind of benefits and functionalists expected for an RO-enable myExperiment platform, for users. The outcome is intended to provide very grounded requirements to guide the RO-Enabled myExperiment activity.

h2. 60. RO-Enabled myExperiment hackathon

@@A F2F hackathon to take place in September??

Some aspects of this have previously been discussed (e.g. recommender integration, collab spheres as an interactive viz example) and today's non-PMB breakout fleshed out this list further and prioritised Taverna and the checklists.  Some of this can be done ahead of the hackathon as discussed towards the end of the afternoon.

h1. Application-oriented showcases, including exemplar ROs for M22

h2. 39. Annotation Notebooklett Component

(submitted by Marco)

I put this here as a reminder of the Y1 idea to make it easier for software developers to build in RO-aware annotation components. From the user point of view, these would surface as description fields in for instance Taverna. See these mock-ups:
* [http://www.wf4ever-project.org/wiki/display/docs/Semantic+Notebooklett+Component+%28RO+Annotation%29]
* [http://www.wf4ever-project.org/wiki/display/docs/Semantic+Notebooklett+in+Taverna+%28RO+Annotation%29]

If for instance the RO portal had a visualization of a wfdesc annotation, then that would be a nice place to do annotations

h2. 40. epigenetics and Huntington's Disease experiment RO (validation of wf4ever results)

(Submitted by Marco)

PhD student Eleni Mina needs to structure her materials and methods of her most recent experiment. She whishes to use the emerging Workfow forever guidelines and tools, in particular for specifying the relations beta name="Showcasebacklogs-28.WorkflowreuseShowcase"pp user="true" style="display:none"/35. RO Guidelines / RO Primer for Users) This showcase main goal is to integrate the work done related with Ip user="true" style="display:none"/p user="true" style="display:none"/ween the various components of her experiment.

This showcase minimally involves
* Structuring the materials in traditional folder structures (Eleni)
* Using the RO command tool or RO portal to annotate the materials and specify the relations between them.
* Following/validating/refining the best practices.

Optional (upon availability of tooling)
* Create additional views (e.g. a results view of workflow outputs) using the additional relations in the RO
* Validate wf4ever tools/guidelines
** RO checklists / decay taxonomy (are we preventing decay?)
** RO primer / ontology
** Provenance queries

Suggested participants: Eleni Mina, Marco, Kristina, Graham, Piotr
{gallery}

h2. 72 {color:#222222}First steps for a collaboration with related astro initiatives for an Astrotaverna enhancement{color}

(Submitted by Pique)

*Depends on 9. AstroTaverna*
* {color:#222222}[PDL|http://pdl.obspm.fr]{color}
* {color:#222222}[VAMDC |http://www.vamdc.org/]{color}{color:#222222}Plugins{color}
* {color:#222222}[Aladin |http://aladin.u-strasbg.fr/]{color}{color:#222222}tasks integration{color}

*Members*: Julian, Pique

h2. 73 {color:#222222}RO-fication of content from ADSLabs{color}

(Submitted by Pique)

{color:#222222}{*}What{*}{color}{color:#222222}: Extraction of content from ADSLabs \[1\] and import into RODL as ROs without workflows{color}

{color:#222222}{*}Members{*}{color}{color:#222222}: Julian, Pique{color}
{color:#222222}\[1\] {color}[http://labs.adsabs.harvard.edu/wiki/doku.php?id=home|http://labs.adsabs.harvard.edu/wiki/doku.php?id=home]

h2. 61 Astronomy Golden Exemplars

...

The behaviour and the characteristics of a galaxy are affected by the environment where the galaxy lives. The properties of a galaxy are different depending on whether the galaxy is in a dense environment with other nearby galaxies (companions), or otherwise it is isolated.

The goal of this experiment is twofold:

* a) {color:#222222}To determine the characteristics of the environment for each galaxy in an input list of target {color}{color:#222222}galaxies{color} (how many companions, how big, how close), and to apply selection criteria in order to obtain a final subsample of galaxies fulfilling those criteria.
* b) To determine structural properties of galaxies (extracted from CCD images) as the luminosity profile, among others, for a sample of galaxies

These two aims could be separated experiments, or combined in a single one. The combined scenario would be the selection of the sample using a) and extraction of the structural parameters of this sample using b.

Furthermore, a) could be used with different isolation criteria to obtain samples with different environmental characteristics, each studied using b) and comparing how these two different environments would determine the structure of galaxies.

The steps are:

a)
* Given a list of target galaxies as input (names, coordinates), to extract the potential neighbors from digital catalogues (NED and SDSS)
* Apply isolation criteria to refine and get a final sample with the most isolated galaxies (or different criteria to get galaxies in denser environments)

b)
* A FITS (binary) file with the image of the galaxy is needed to extract the radial luminosity profile, so the list of images corresponding to this sample need to be downloaded from public digital catalogues
* The luminosity profiles are calculated by the tools GALFIT and ELLIPSE applied to these images.
* GALFIT, as well, produces as well a modeled image (FITS file) of the galaxy, which can be processed by ELLIPSE
* A radial profile of the model may be obtained by ELLIPSE and can be compared with the profile of the original image to evaluate the quality of the results
* Since this list of isolated galaxies can be used by others experiments, it may be provided by Vizier Catalogue VO service when published in journal

Members: Susana, Pique, Lourdes, Julian and IAA friends.  

h2. 62 Genomics Golden Examplars

h3. 62a. The 'Anni' Exemplar Workflow (The BioSemantics Concept Profile Method for prediction novel biological relations)

(submitted by Marco)

*Background*

The interactive tool 'Anni' ([http://biosemantics.org/anni]) has become a valuable tool for many genomics researchers to predict new relations for biomolecular mechanisms or prioritise (order) lists of genes based on knowledge contained in biomedical abstracts (over 20 million in PubMed). The technology behind Anni has proven popular, but the monolithic tool is difficult to maintain. Therefore, we adopted an e-Science Approach based on \(i) Web Services for the common steps available in Anni*, (ii) workflows for the common procedures enacted by Anni, (iii) a workflow-to-Galaxy and workflow-to-web tool to leverage the advanced technology for (less technical) biologists**. We wish to preserve the most common Anni methods by means of workflows and additional preservation tools from wf4ever. It is implied in all genomics use cases.

The workflow takes a list of concepts as input (typically a list of differentially expressed genes), and returns an ordered list of candidate concepts (e.g. genes or diseases) for further study, plus the intermediate concepts that explain why these concepts were prioritised. See [van Haagen et al.|http://www.ncbi.nlm.nih.gov/pubmed/21280221] and [Jelier et al.|http://www.ncbi.nlm.nih.gov/pubmed/21183478] for details of the method.

*People involved*

Workflow: Kristina Hettne, Eleni Mina, Marco Roos, Reinout van Schouwen
ROification: Reinout van Schouwen, Kristina Hettne, wf4ever technical liaison

\* created in the context of wf4ever and the Centre for Medical Systems Biology, primarily by Reinout van Schouwen
\*\* created in the context wf4ever and a collaboration between the Netherlands BioInformatics Centre (NBIC) and myGrid.

h3. 62a. - part 2

(submitted by Kristina and Marco)

*Goals*
* Final tweaks and workflow validation (content-wise: validate with data from literature that the workflow performs the analysis it is supposed to do).
* ROification (using the RO manager and the RO portal)
* Provenance (using latest provenance export options in Taverna)
* Outline of a paper for the Journal for Biomedical Semantics paper, SWAT4LS issue. The paper will serve as the LUMC reference paper for wf4ever-related work.

*People involved*

Final tweaks and workflow validation: Kristina Hettne and Harish Dharuri

ROification: Reinout, Kristina, wf4ever technical liaison (Graham, Piotr?)

Provenance: Marco, Stian?

Paper outline: Kristina, Harish

h3. 62b. Examplar workflow for interpreting Genome Wide Association Data in the context of unravelling the genetic background of Metabolic Syndrome

(submitted by Marco and Kristina; primary showcase for WP6)

The workflows here are created in the context of ongoing projects in the Human Genetics Department.

*People involved*

Workflows: Harish Dharuri*, Kristina Hettne, Marco Roos (supervision), Peter-Bram 't Hoen\* (supervision)
ROification: Kristina Hettne, wf4ever technical liaison

Note: ROification of the workflows created by Harish Dharuri will follow their publication.

\* 'Friends of wf4ever'

h3. 62c. Examplar workflow for determining the role of GpG islands and associated epigenetic mechanisms in Huntington's Disease-affected brain regions

(submitted by Marco)

This workflow (under development) explores the role of CpG islands in Huntington's Disease. CpG islands are 'C' and 'G' rich regions in front of genes on the DNA. See showcase 40, which may have to be moved here. The workflows depend on R and is used to demonstrate the e-Science approach described in 62a. Here, we wish to use the preservation tooling to help organise the 'materials and methods' in preparation for a publication.

*People involved*

Workflows: Eleni Mina, Marco Roos (supervision), Willeke van Roon-Mom\* (biology expert), Peter-Bram 't Hoen\* (biology expert)
ROification: Marco Roos, wf4ever technical liaison

\* 'Friends of wf4ever'

h3. 62d. Concept Profile creation workflow

(to be submitted by Marco)

Kristina Hettne, BioSemantics Development team, wf4ever liaison for ROification

NB: we plan to start preparatory work will in our own research group soon.

h1. Project-wide Integration

(by Piotr)

The goals of the showcases for project-wide integration are:

* to integrate existing Wf4Ever services and clients in such way that users can verify in practice the benefit of using each service.
* to help develop an RO-enabled myExperiment, which means a myExperiment instance acting as a client of Wf4Ever services.

The deadline for achieving these goals is the October 2012 plenary.

The work will be done in June, July, August and potentially September sprints, plus at an integration hackaton in September. The sprints should be dedicated to stabilizing service definitions (APIs), implementing quick integration tasks (i.e. connecting services to Portal/myExperiment, whichever is easier), gathering user feedback and defining work that should be left for the hackaton. The summer sprints may be less effective due to holidays and deliverables. The hackaton will be the place to implement missing gaps and make sure that the overall user experience is good and cohesive.

h2. 5. UI: Connect Wf4Ever services to RODL (prev. Traffic lights and Stars) (Piotr)

* The main goal: demonstrate the appliance of existing Wf4Ever services (stability, completness) to Research Objects in RODL.
* Design how they should be used: triggered manually / automatically, need for notification, etc.
* Display services results in the Portal as "traffic lights and stars"

Participants: *Piotr* (RODL/Portal), Raul (architecture/APIs), Aleix (stability), Graham (completness), Kevin (architecture)

h2. 63. Integration of Collaboration Spheres, RODL data, and Recommendation services

(submitted by Esteban)

The main goal of this showcase is to implement the integration of the work done at different parts of the project related with the representation of collaborations between users. This showcase will integrate specifically the following work:

* Collaboration spheres visualization
* Recommendation services
* Access to data from RODL
* Representation of FOAF in wf4ever

The main outcome will be the collaboration spheres visualization using the recommended data provided by the recommender services which makes use of the  RODL data (ROs, users, meta-data, etc).

Members: Esteban, Rafa

h2. 64. Integration of the checklist service into the Wf4Ever portal 

(submitted by Esteban)

The main goal of this showcase is to implement into the project portal the I&A work done at showcase 47 which is mostly related with the evaluation of the I&A of a RO by using a checklist.

The main outcome will be the checklist I&A service integrated into the wf4ever portal.

h2. 65. Linking taxonomy of decay with minim models

The main goal of the showcase is to make a transfer from the taxonomy of decay (showcase 7) to the minim model structure which collects the I&A evaluation requirements to be applied.

The outcome will be the creation of new minim models including the taxonomy of decay information gathered at showcase 7

*Members*: Graham, Marco, Gema, Aleix, Oscar  (this list is obtained from those working in Manchester on this)

h2. 66. Integration of the stability service into the Wf4Ever portal

Depends on #64.

The main goal of the showcase is the integration of the stability evaluation into the wf4ever portal. It will include the next actions:

* Definition of stability APIs
* Access to different states of a RO (roevo snapshots, roevo live ros, etc)
* Evaluation adapted to the new roevo data
* Simple visualization of the stability in the portal

The main outcome will the simple visualization of the stability value into the wf4ever portal and a service providing the staiblity evaluation.

h2. 68. Improving the Wf4Ever APIs

The main goal of the showcase is to make sure that all Wf4Ever services have proper APIs, in terms of being RESTful and using Linked Data. This will be done by revisiting the existing or planned APIs, improving them where necessary, performing a quick or mockup implementation and finally documenting them. The APIs will be investigated in the following order:
# Evolution API (clarify required functionality)
# Workflow transformation API, based on current taverna->RO service
# Annotations API to allow myExperiment to add annotations to an RO in RODL
# User management API
# Stability API
# Recommender API
# RO aggregation API (adding new contents, etc.)

People involved: *Graham*, Piotr, Kevin, API authors.

h2. 69. Partial attribution of workflows impossible

This is coming from a list of features proposed by Carole by e-mail on July 23rd 2012 ([https://lists.isoco.net/pipermail/wf4ever/2012-July/003950.html])

h2. 70. How do you cite a workflow ?

This is coming from a list of features proposed by Carole by e-mail on July 23rd 2012 ([https://lists.isoco.net/pipermail/wf4ever/2012-July/003950.html])

h2. 71. Putting together a pack is really clumsy (and Pinar hates it)

This is coming from a list of features proposed by Carole by e-mail on July 23rd 2012 ([https://lists.isoco.net/pipermail/wf4ever/2012-July/003950.html])

h2. 78. RO-based annotation requires Protege and does not include human-oriented descriptions

Kristina is trying to structure her RO in the portal and is only provided with a few Dublin Core predicates for help. To annotate with RO artefacts she requires Protege. This should be integrated in upload and manage features of myExperiment. These should also ask for descriptions for \*every single annotation*, it is not enough to classify, humans need to be able to use it. The repair checklist can drive this; these require human descriptions of what components are doing in a RO.

Scenarios

Scenarios: see [docs:RO-enabled myExperiment user scenarios]

h2. 79. Provenance is in the RO as a file, there is no user view on it

...