<aside> ❗ This pitch uses ‘data connector’ instead of ‘data source’. Why? In writing this, I’m realizing that our name ‘data source’ is misleading. For example, in this pitch, we’re not actually talking about sharing data, the object we are talking about sharing is the metadata or configuration for connecting to that data. I think ‘data connector’ would be a better name. Therefore, instead of a dialogue in RenkuLab saying “share this data source”, it should say “share this data connector”. And for the visibility: it’s not “make this data source private or public” (because changing the visibility you set in RenkuLab doesn’t affect whether the data is private or public!!), but instead “make this data connector private or public”.

</aside>

🤔 Problem

<aside> 🔶 write problem statement!

</aside>

When I am working on a project that uses the same data as other projects on my team,

I want to reuse that data source with minimal overhead

So I can get on with the main activity of my work, and time and effort is not duplicated among my team doing the same data access operations.

When I am working on a project that has thematic overlap with other projects on my team,

I want to know which other people and projects are using the same data as me,

so I can benefit from their knowledge and reuse their work.

🚞 User stories / journeys

🍴 Appetite

6 weeks.

🎯 Solution

The main goal here is to make it so that users can search, share, and reuse data connectors between projects. We want to make data connectors ‘first class entities’ in RenkuLab. This means that data connectors are independent of projects, have their own namespace and access rights, and their own linkable homepages on RenkuLab.

I’ll walk through the data connectors lifecycle, noting what parts of this process require new work.

Creating a data connector (new: data connectors belong to namespaces!)

First up is creating the data connector. A user most often creates a data connector in the context of a project, via the ‘add data connector’ button on the project page.

We can consider adding a ‘create new data connector’ in the main ‘New’ button in the nav bar too, but that’s a nice to have.

The main new change in this pitch for the data connector creation process is that the user specifies the owner of the data connector. The concept of ‘owner’ is synonymous with ‘namespace’, but we use the term ‘owner’ because it is more evocative for our users. The options for setting ht e owner are (1) themselves or (2) a group that they have write access to, i.e. editor or above. When creating the data connector, the owner should default to the same owner as the project it’s being created for. By saving a data connector in a group namespace, users can create a collection of related research artifacts/components that are used - and easily reused - among multiple projects.

Data connector visibility: via namespaces + a private/public toggle