Skip to end of metadata
Go to start of metadata

The goal

The purpose of the hackathon is to

(a) create nice, usable and consistent user experiences for using some of the Wf4Ever services together; and

(b) gather Wf4Ever developers and myExperiment developers and work closely together by using (a) as a common goal.

The long term goal is to use myExperiment as the primary client for Wf4Ever services, so it will be necessary to have the myExperiment team also participate in the hackathon to make quick integration tasks where adequate and have a good basis for further work with myExperiment.

If the integration team decides that there are quick wins with using other Wf4Ever clients (RO Portal or RO-manager), these will be used as well.

Where, when, who

The hackathon will take place 24th to 26th September 2012, before the October plenary meeting.

Meeting rooms:

  • Monday & Tuesday: Conference room
  • Wednesday until 1130: Access Grid Room
  • Wednesday from 1300: Conference Room (atrium available 1130-1300)

Wireless access: eduroam, or Graham, Jun, Piotr and Kevin have guest logins for OWL.

The preparations to the hackathon are led by Piotr.

People invited are Wf4Ever developers plus the myExperiment team representatives. That means:

  • from Wf4Ever: Graham, Stian, Piotr, Aleix, Rafa, Reinout, Julian (user representative)
  • from myExperiment: Don, Finn
  • from BioVel: Alan

Confirmed:

Who

Arrival time

Departure time

Comments

Piotr

Monday 11am

Thursday morning

 

Reinout

Sunday 21:00

Wednesday 19:00

 

Stian

Monday 10:30

Wednesday 17:00

 

Finn

 

 

 

Alan

Sunday afternoon?

Wednesday afternoon?

 

Graham

daily ~9:30

daily up to ~22:00

 

Julian

Sunday afternoon

Wednesday 17:00

 

Aleix

Sunday afternoon

Wednesday afternoon

 

Don #1

Monday morning

Monday afternoon

 

Don #2

Tuesday morning

Wednesday afternoon

 

Rafa

Monday 11am

Wednesday 17:00

 

The meeting place is Oxford eResearch Centre. See http://www.oxfordrooms.co.uk/ for accommodation (Keble college is directly across the road from OeRC).

The Doodle poll for choosing the date was http://doodle.com/vgxu8vbgqynvuss6.

The dates are set for  24-26.09.2012 (Mon-Wed).

Scope of work

The project is at a critical stage. The models, API's and services have their preliminary designs and implementations. Now they need to be integrated. However, integration has to be in the context of an integrating application. Otherwise it is integration for the sake of it, out of context.

Our primary application showcase for Wf4Ever is myExperiment. If myExperiment cannot use the services and models then we cannot expect other systems to do so. Moreover, myExperiment is the primary valorisation vehicle for the impact of the project in two major EU projects (BioVeL and SCAPE) and a publisher (BioMedCentral+BGI).

As a first step in a long (until the end of the project) path towards myExperiment 2.0 - the RO version  - we need to start incorporating myExperiment into the integration driver applications.

A pleasant and attractive user experience is not an icing on the cake. It is the cake as far as users are concerned, and out-flanks any amount of clever infrastructure. All hackathons and sprints from now on should refelct on their contribution to a user experience through myExperiment.

Requirements

The chapters below present the specific objectives that should come out of the Wf4Ever features that are offered to users. Note it is not necessary or desirable to force every service to be used in a scenario as seen by Kristina's experience.

Objectives

The objective of the hackathon is to implement selected user scenarios which describe how users work with an RO-enabled myExperiment. Scenarios 1-3 from ?RO-enabled myExperiment user scenarios have been selected. For each scenario, the key steps MUST be implemented. The other steps will be implemented if there is time. (Note: the key steps still need to be selected).

Scenarios 1-3 involve using the following Wf4Ever services:

  • Checklist evaluation service (Graham)
  • Workflow runner service (Stian)
  • Wf-RO transformation service (Stian, Piotr)
  • Recommendation service (Rafa)
  • Collaboration spheres service (Aleix)
  • RODL (Piotr)

It has been decided to create groups of developers for each user scenario that will meet on Skype to discuss the technical aspects of implementing each scenario and:

  • make sure that it is clear how this scenario will be implemented in the hackathon
  • identify work to be done before the hackathon

The groups are:
US1: Piotr (leading), Graham, Don, Raul, Stian (to be confirmed), Reinout
US2: Stian/Piotr (leading), Graham, Don, Finn, Raul, Reinout
US3: Rafa (leading), Aleix, Don

The result of each group's work should be put in the wiki with user scenarios, and it should be made clear if the proposed implementation decisions are final or not. Marco proposed to make a table with columns such as 'user scenario step', 'quick solution', 'final solution'.

Agenda / work methodology

 

User Scenario 1

User Scenario 3

Day 1

  • myExperiment shows ROs (steps 1-2) 
    • Don, Piotr, Graham, Finn
    • Issues: WFE-613, WFE-614
  • Wf-RO service converts Taverna annotations into RO annotations (step 3)  
    • Led by: Stian, Alan
    • Issues: WFE-616

Backend Integration

Day 2

  • Wf-RO service converts Taverna annotations into RO annotations (step 3) - continued
    • Led by: Stian, Alan
    • Issues: WFE-616 
  • myExperiment evaluates the RO resources (step 4)
    • Led by: Don, Graham
    • Issues: WFE-617, WFE-618

myExperiment integration

Day 3

  • myExperiment provides annotation interfaces (steps 5-17) 
    • Led by: Don, Graham, Stian
    • Issues: WFE-659
  • Improving the user experience for the implemented features (all)

Interface improval

Things to do before the hackaton:

type key summary assignee priority status created timeestimate

com.atlassian.sal.api.net.ResponseTransportException: Connection reset

View these issues in JIRA

Things planned for the hackaton:

type key summary assignee priority status created timeestimate

com.atlassian.sal.api.net.ResponseTransportException: Connection reset

View these issues in JIRA

As discussed in the Skype calls, a potential bottleneck may be the heavy dependency on myExperiment user interface (there are 6 services and 3 user scenarios but only 2 myExperiment developers). Different approaches have been discussed to avoid it, such as rendering simple web pages by mockup services, which may be integrated in myExperiment whenever convenient.

User Scenario 1

Steps 1-2

The solution for the hackathon

myExperiment will use RODL to store all research objects, their resources and annotations. It will communicate with RODL via ROSR API 6. The user will first create a new pack*, and myExperiment will call RODL to create a Research Object. The user will then upload a workflow, and myExperiment will call RODL to aggregate and store the workflow. RODL will generate initial metadata and an updated manifest will be retrieved by myExperiment. A refreshed pack page will be shown to the user.

(GK) we also discussed that when an RO is updated in RODL that myExperiment would be notified so that it could refresh its internal caches. (A quick-and-dirty implementation could be a manual "refresh" utility to trigger this process.) FWIW, I'm involved in ResourceSync project which will be looking at mechanisms for synchronizing OAI reposities, with change notifications.

(PH) Agreed. At the hackathon we'll have to rest on the quick-and-dirty mechanism.

RODL will use myExperiment's user base. myExperiment and all other clients will use myExperiment's access tokens to authorize requests for RODL. RODL will verify the tokens using myExperiment's WhoAmI service. RODL will perform no access control.

The longterm solution

The user experience will be similar. Another option for the users will be to upload a workflow and checking an option "create a pack" instead of having to create the pack before.

myExperiment and RODL may use HTTP cacheing mechanisms to optimise polling for updates. (GK) Per discussion, more (notification) is probably needed. See comments above.

myExperiment may offer an interface for generating RODL access tokens for offline clients, such as the RO manager. It will also share the access control policies, i.e. it will request permission from myExperiment to perform an action for a given user. The user and access control interfaces may use existing open APIs for added flexibility and to allow using with systems other than myExperiment. (GK) shouldn't this be conceived as a separate service?

Requirements for the hackathon

  • deploy an instance of RODL dedicated to myExperiment (on myExperiment servers) for performance and higher database capacity
  • implement ??User Management 2 in RODL, which is improved over the current version
  • in myExperiment, pack is a synonym for research object

Step 3

The solution for the hackathon

The annotations from Taverna will be mapped 1 to 1 to RO annotations, or 1 to many in case they are structured along a proposed convention. The tool which will do the transformation is yet to be decided:

  • myExperiment, which already does a 1 to 1 transformation of t2flow annotations
  • Wf-RO service, which can be reused by many clients and also used as a command line tool (seems a preferred option)

The longterm solution

The Scufl2 workflow format should follow the RO model closely and store the workflow annotations in an RO-friendly way.

Requirements for the hackathon

The annotations proposed by users as part of the ROification process should be analysed and mapped to the RO model.

Step 4

The solution for the hackathon

When an RO is viewed in myExperiment, myExperiment iterates over all aggregated resources. For each resource:

  • If it's an external resource, it will be rated.
  • If it's an internal or external workflow, myExperiment looks for its inputs and outputs using the wfdesc ontology, and all of them will be rated.

To rate a resource myExperiment makes a set of calls to the checklist evaluation service with predefined minim models and targets, the calls are made until the first fail, number of successes is displayed as number of stars for a resource.

The checks:

  1. If it's a web service, check if it's curated (in a registered list of DL or WS registries). For BioCatalogue, a lookup service can be used which takes the WSDL URI as a parameter.
  2. Do a HEAD on a resource and check it returns a 2xx or 3xx response. In case of web services, it should try to retrieve the WSDL or the root resource of a REST service.
  3. Check if it's annotated by the user in the RO.
  4. Check if it's used in other Research Objects.

The longterm solution.

There is an undetermined discussion about whether the resources used by workflows should be aggregated in the RO.

They should be because:

  • It is easy to list and catalog all resources used in the RO.
  • Some resources can be used by many workflows.

They shouldn't be because:

  • It may be difficult to maintain them after the workflow is modified.
  • It may not be scalable.

It is expected that this discussion will continue after the hackathon. See also ?To aggregate or not to aggregate?

Additionally, the evaluation results may be stored as RO/resource annotations for cache'ing.

Requirements for the hackathon

Prepare minim models for ROs with workflows with wfdesc descriptions.

Steps 5-17

The solution for the hackathon

For the hackathon, a basic interface for tagging resources will be implemented. This will allow users to define the role of a resource (step 5) as well as add keywords (step 11) and custom textual descriptions (step 10). When a user decides to put a tag, he may have some terms proposed based on existing values. Those terms that belong to formally defined vocabularies (i.e. the RO model) will be marked with a different colour. The tags and their allowed values will be described using SKOS.

The longterm solution

SKOS will be used to allow users to add their own vocabularies, which is particularly important when other software creates the annotations.

Additional UI widgets will facilitate defining specific annotations about resources, i.e. relations between resources aggregated within the same RO.

Requirements for the hackathon

User Scenario 3

Step 1 to Step3

Introduce of an interesting concept that could be part of the evaluation of the quality of the RO: discoverability (the recommendation strength indicator); and also we can consider an evaluation of the user profile. (Provide to the user useful tips so that the user gets more meaningful recommendations (like.... flickr, linkedin % of profile creation but more complex and with more guidance))
The question is... is this part of a recommender service or should be included as a discoverable property and evaluated by (I guess) the checklist evaluator?
Longterm solution (after the hackathon): Include the discoverability as part of the qualities that we measure of an RO providing the necessary algorithms + software to do so

Step 4:

ok.

Solution for the hackathon

  • Add a button to myExperiment pack description page (or homepage) that points to the recommender webpage

The longterm solution

  • The recommendations provided by the Recommender Service could be integrated in myExperiment in the same form as the Updated Item, Latest comments, etc. that are now in the user's Home myExperiment webpage.

Step 5:

Very nice. We can show a simple webpage with recommendations based on users profile and previous activities; and what the (pack/RO) that the user is currently handling:

Solution for the hackathon

  • Create simple web page that shows the results of the recommender and that can be easily integrated later on into myExperiment. Both are offered clearly separated manner, offering the user to change the considered pack for getting the recommendations.
    • User previous activities and profile description.
    • What the user is currently doing (i.e. "recommendations based in your pack/RO") That implies the creation of a new recommender, that given a pack/RO id recommends new resources
  • Add a button that allows the user accessing to the advanced recommendations webpage (i.e. the Collaboration Spheres webpage)

The longterm solution

  • IMPORTANT ISSUE: The integration with myExperiment should be made directly to its back-end or myExperiment should provide some publish-subscribe mechanism for propagating the changes made by the last user updates. Otherwise there will always be a delay between the data used to tailor the recommendations and the latest version of the myExperiment data
  • Introduce access mechanisms to restrict the access to the Collaboration Spheres webpage to anybody but the user.

Step 6,7,8

Good idea! In such way we separate the "simple" list based interface that the recommender provides with little or no interaction mechanisms from the advanced visualization mechanisms provided by collaboration spheres

Solution for the hackathon

  • Create a separate webpage for the Collaboration Spheres
  • Improve the tooltips and help of the Collaboration Spheres
  • Deploy the new Collaboration Spheres webpage in the wf4ever sandbox
  • The Collaboration Spheres use the SPARQL endpoint + myExperiment API for accessing to the different entities that (workflows, files, packs, users, etc.)
  • Improve the integration between the Collaboration Spheres and Recommender Service (tighter interactions between both components). The necessity of having the recommendations tailored by the Collaboration Sphere added to the user Recommendations Set creates the necessity of further integration between both components
    • The Recommender Service should provide mechanisms to store the context of the recommendations
    • Update Recommender Service REST API interface accordingly
    • Creation of the first version the item-group/aggregation based algorithm

The longterm solution

  • Integrate the Collaboration Spheres webpage in the myExperiment portal, not as a separated webpage (or at least mimicking its look & feel).
  • As in the case of the Recommender Service, in the longterm it should be closer to the myExperiment backend/DDBB
  • Optimization of the item-group/aggregation based recommender. As these recommendations are created on-the-fly, the process for making them should be as optimized as possible
  • No labels