Intranet or Internet

Intranet solution (Data-centric local store)

Stian: I am picturing an Intranet portal to be like a myExperimentInaBox, you download a CD and boot up a random computer with some disk space, and there you go. Taverna says "Do you want to connect to your local myExperiment store?". After this, any workflows made are stored automatically on the local portal, together with logging of everything happening while running workflows (provenance). On the intranet, other local users can check out which workflows have been added by whome, and click a button to open it in Taverna to re-run it or edit it.

When people build on each-others workflow, the repository will recognize those links when a derived workflow is (automatically) submitted. The original author can then see that his workflow is used. Workflow authors who combine lots of other people's workflow will no longer have to remember who made each part, the portal can find out those things for him. He can tag his and other people's workflows according to his own topics, and browse by the tags used by himself and others.

Since this box is locally, there should be no trouble (except for arranging for backups) in storing produced data here. You can still do groups and access control, by default everyone is in the same workgroup. By using this solution, users don't have to store their workflows and input/output-data on their local machines or servers, don't have to walk around with memory sticks or sending workflows in emails.

With a "Publish to internet" button, selected workflows (already locally tagged) can be submitted to the global myExperiment.org, which can be a similar portal.

The challenge here is:

1. Will people actually press that publish button, or will everyone be happy with their local stores?
2. intranet portals would mainly attract people who already have Taverna, and not help grow the community

Antoon:

Suppose we do both the Internet and Intranet version. If the installation CD allows for easy integration with the mothership Internet version, the two versions would blend as far as a user is concerned. In response to the challenges put:

1. If people get benefit from the global store, they'll be more willing to contribute back.
2. Perhaps Intranet portals would attract more people from the same group/organisation if it proves an easy/fast collaboration tool for data sharing. Fast and data sharing is not something you'd get from the global version probably.

your reply here

Internet (Workflow-centric global store)

Stian: An Internet portal would help build a community of workflow builders and users. People will be a bit more reluctant to putting all their data here, and we will probably not have the resources to store it either. However, this would be more workflow-centric than the intranet solution, and could include forums, discussions, comments, faq-s and documentations, golden standards and how-to-use-stuff.

Dirk: I think it is important to decide which user group you want to address mainly with the portal. My idea about myExperiment was to make workflows more accessible for Biologists. In this case it has to be internet because downloading and installing an application is a serious hurdle which will detract many possible users who are not 100% tech-savvy.

Rob and Alex: There are two pre-requisites for sharing and re-using workflows. First, on the supply side, sufficient incentives must exist for authors to share them with others. Second, on the consumer side, enactors must have sufficient grounds to trust in the quality of a workflow: that it works as claimed, has been tested thoroughly, and is free of (significant) errors.

On these criteria, there seem to us to be three arguments for developing the intranet version first. These are based on the argument that the local setting offers the best chance that sharing will happen, at least initially:

1. Within the local setting, the so-called ‘compulsion of proximity’, group and organisational obligations are ready and powerful sources of incentives for sharing while, at the same time, the effort required to do it adequately is minimised by the way the local setting affords easy exchange of information. In particular, workflow documentation and quality standards are likely to be lower precisely because the author is on hand to provide information, and to learn about and to fix problems if and when they arise.

2. Often, and for obvious reasons, trust in an artefact relies on (possibly a series of) proxies for first-hand evidence which are founded on trust in other people. In rough order of strength: someone we trust created the artefact; someone we trust has used the artefact and recommends it; someone we trust knows the person who created the artefact and is prepared to recommend it; someone we trust knows someone who has used the artefact and is prepared to recommend it. Trust in artefacts is, therefore, socially achieved and it is these social mechanisms which we must pay attention to mobilising for the portal. For various reasons, these mechanisms are stronger in local and, especially, co-located social networks. This point is reinforced in one of the post workshop wiki discussions.

3. We have an opportunity to learn from the local sharing of workflows and to figure out how to make this work on a bigger and wider scale. If we are correct, then some of the barriers relating to, for example, content seeding would be resolved.

In contrast, there seem to us to be two technical and pragmatic arguments and one community development argument for developing the Internet version first:

1. It is important to provide core functionality relatively quickly that would allow people to engage with the project and start using its outcomes without having to install anything on their (individual or local) machines.

2. The second reason is an entirely pragmatic one: the timelines for developing a shrink-wrapped product are quite long and it is much easier to provide a centrally hosted service initially.

3. Intranet portals will only attract people who already have Taverna and not contribute to growing the community.