Project Navigation API

Driving Use Cases

Use cases are derived from the following sources:

Metadata use-cases

Project Group Use Cases

1. A project contributor needs to navigate from one project in a group to all other projects in the same group.

2. A funder needs to navigate from one project they are funding to all other projects they are funding

3. A scientist needs to navigate from one project related to a diseases ‘z' to all other projects related to disease 'y’.

4. A project manager needs to navigate from one project funded by ‘x' to all other projects funded by 'x’.

5. An analyst needs to navigate from one project containing data sets of type ‘y' to all other projects with data sets of type 'y’.

6. Any user from the above uses cases might need to refine their navigation of projects by adding an additional facet to their selection. For example, if the primary facet is a project group, but there are dozens of projects in the group, adding an additional facet to the navigation, such as funder would allow them narrow the selection to a more manageable list.

7. Not all projects are the same. For example a project used to run a challenge is different than a project of curated data sets. As such, projects might fall into different types, each with their own set of defining attributes. Ideally, we would be able to define new project types as needed.

Proposal: Faceted Navigation

Project Context

The basic proposal is provide faceted navigation for projects. Project administrators would need to “annotate” their projects with the appropriate facets. For example project syn123 might be annotated as follows:

Each facet value would be represented by an object in Synapse. For example, ‘Foo’ might be defined as follows:

A project annotated with ‘Project Group’ = ‘Foo’ would then belong to that group.

In the example above, the page for project syn123 would show its attributes with each value as a link. For example, clicking on the link ‘Foo’ in project syn123 attribute display would navigate to a page representing ‘Foo’. The page for ‘Foo’ would show its name, description and most importantly a list of all projects annotated with a ‘Project Group’ = ‘Foo’. Similarly, there would be an object for ‘Disease’ = ‘Bar’ and ‘Funder’ = ‘Baz’ with the same features as the Project Group.

Non-Project Context

Lastly, we could provide faceted project navigation in a context other than a project’s page (maybe on the home Synapse page?). Outside of a project’s context we could show all of the possible project facet types on a side bar. With the example above this list would include: Project Group, Disease, and Funder. Selecting one of these types could then present possible value with statistics for each. For example, selecting ‘Funder’ would then show all possible values of funders with a count of the number of projects within each value. Selecting one of the values would then apply a filter showing only projects that match the user’s selection. From the example, if the user selected ‘Funder’ they would see the following: ‘Baz (25)' ‘BazBaz (3). Selecting the value ‘Baz’ would then list 25 projects funded by 'Baz’ including the example project syn123 from above.

Users would then be able to make additional selections to further refine their navigation.

Project Types

It is unlikely that there is a set of attributes that would be appropriate for all projects. It is more likely that projects can be categorized into types. Rather than attempt to define all of the project types, we propose providing a system where users can define project types. A project type would be defined by a schema that explicitly defines the attribute of all projects of that type.

Given that each project type might have different attributes, a top level non-project context navigation, would first require a user to choose a project type. This type selection would then define the available facets for facets for further navigation.