Developer:Entities
myExperiment Entities
By Don Cruickshank, 4th August 2008
The basic design of the myExperiment model revolves around two major concepts: Users and Contributions. The contributions are the digital objects that users can add or upload to myExperiment.
Users
The data model for users is split into two main sections: Their private information and publicly visible information. The private information kept about users includes their login details to myExperiment and the email they used to register with.
The public profile for users contain their avatar, email address (not necessarily the one they used to register with myExperiment), country, website, a description of themselves, their role in their institution and contact details.
Users can create friendships with other users. Once the friendship is confirmed by the other user, the friendship is visible on the profile page of those users.
Users may also send private messages to each other.
Contributions
The contribution model supports a number of features.
1. Attributions – A contribution can be attributed to other contributions.
2. Creditations – A contribution can credit a list of users. By default, the uploader is listed as a creditor during upload.
3. Favourites – Users can mark out their favourite contributions. The list of favourites is visible to other users.
4. Ratings – A simple 5 star rating system.
5. Reviews – Ratings can be augmented with reasoning for the given rating.
6. Citations – Citations can be added to workflows.
7. Comments – A simple comment system can be added to contributions. This will be replaced by a more flexible discussion thread system.
8. Tags – Contributions can be tagged.
9. Versioning – Users can upload multiple versions of a workflow, each with a revision comment.
10. Policies – see below for Ownership, Sharing and Permissions.
Contribution types
Workflows
Workflows are the contribution type in myExperiment for workflow files from Taverna, and soon for other types such as Triana and Kepler. Each workflow has statistics kept for the number of viewings and the number of downloads.
Groups
Groups are collections of users. Any user can create a group and invite others to join it. Alternatively, users can request to join a group. A group can be set to automatically accept users that wish to join it. In addition to the membership list of a group, a group also has a title and a description. Groups are public – they cannot be made private. The codebase supports the concept that groups are related to other groups via a relationships mechanism but this is not utilised. This feature might be used by the Chemistry instance of myExperiment.
Packs
Packs are general containers for contributions. In addition to contributions on the current server, they can also contain links to contributions on other servers.
Files
Files are generic files that can be uploaded to myExperiment.
Experiments
So far, the experiment contributable in myExperiment is a container for job runs. You do not add workflows to experiments, rather you add workflow invocations to an experiment. Each experiment has a title and a description, and the list of job runs. Each job is listed whether it is not yet started, in progress or has been completed. To execute a job in the cloud, a user must use a registered “runner”. This could be a personal enactment service or one provided for lab use. In either case, the results can be published via myExperiment by choosing the appropriate sharing permissions.
Site announcements
Site announcements can be managed by the administrators of myExperiment.
Ownership, Sharing and Permissions
Each contributable has an owner, which may be the user that uploaded it (e.g. a workflow) or the contributable may be assigned as being owned by a group.
Sharing is performed to three separate groups of users. 1. The public 2. Friends 3. Groups
REST API
We aimed for data access using basic REST principles. Though Ruby on Rails provides a mechanism for automatically providing REST access, we decided on a split between the internal data model used by myExperiment and the one provided to consumers of the service. The REST interface provides the basic interface, and we foresee use of Atom as a means of delivering content (e.g. RSS) and possibly used to synchronise content with peer services (e.g. on the vein of Ray Ozzie’s RSS work).
Elements of the myExperiment data model have been revealed via the REST API on a case by case basis. Currently, the entities we reveal are:
1. Workflows 2. Files 3. Users 4. Groups 5. Pictures 6. Tags 7. Messages 8. Announcements 9. Citations 10. Reviews 11. Comments 12. Ratings 13. Packs 14. Experiments 15. Runners 16. Jobs
Authentication
Why support OpenID and OAuth at the same time?
Authentication is achieved by using the OAuth protocol. While the protocol itself may appear similar to OpenID in principle, it achieves a different goal. The purpose of OAuth is to not just authenticate that a user has given a service consumer access to a service provider; it is a specific key that may have certain privileges assigned to it. Thus in OpenID, you have an identity that is typically a human user. When you sign into a service using that OpenID, you can then give certain privileges to that service but it is for that user. With OAuth, a user can create several keys which could be used with one service. And each of those keys may have a different set of privileges.
User keys
Using OAuth, regular users of myExperiment may create API keys. They can then register those keys in other services such as facebook. By configuring the keys, the myExperiment user can give certain privileges to the peer service, such as the ability to create friendships but not upload a new workflow to myExperiment. Using a key management page, the user can also revoke the API key if he or she decides not to trust the peer service. From that point onwards, attempts from the peer service to access will fail.
System keys
Some operations may require more privileges that a regular user has access to in myExperiment. In this case, administrators of the service can create system keys that give wider access. It is anticipated that these keys will be used for peer services, which may be other instances of myExperiment or may not, to allow federation of data. To achieve this, the number of possible REST entities we reveal will be extended when a system key is used.
