Create project and category naming scheme

[peer35]

Looking at the structure and naming in Yoda as a rodsadmin should give a good clue into who is responsible for which project.

There is no technical requirement except for unique group names, but our successors will be thankful once there are hundreds of projects.

• Assume 1 instance for the VU
• Variation per faculty (different subdivisions)
• In collaboration with data stewards. It is very hard to see all local variations looking from IT or the library.

Categories: share metadata scheme (might change in future yoda versions), basic administration level (although a good naming scheme makes this less necessary).

For example: Basic category level, disciplines and institutes: Beta: few-geosciences, few-aimms, few-informatics, ... FGB: fgb-movement-sciences, fgb-psychology (or do these need subdivisions?)

Might make sense to repeat these in the groups themselves, since it's so easy to change categories: So: few-aimms-flow_cytometry few-geosciences-nlbv

Keep in mind the VU has a tendency to change or merge faculties.

End goal should be a document the project team can use when adding new projects during the pre-production which can be handed over to the functional admin (library?) when we go in production.

[peer35]

Start a wiki in this repo?

[bgoli]

A wiki might be useful to start some proto-documentation. For general information here is the structure of the AIMMS/Yoda which is the result of evolved guesswork.

AIMMS/Yoda is used by three departments: Chemistry and Pharmacological Sciences, Environmental Health and Toxicology and Molecular Cell Biology. The departments are split into sections so, for example, MCB is split into: Systems Bioinformatics, Molecular Microbiology and Structural Biology.

Categories (institute/section level)

• AIMMS
• test

There is one data manager defined for AIMMS.

Sub-categories (I tried two approaches. Either research group level, typically of professors in a department or a functional grouping per research group):

• Professor1 Lab
• sbi-phd-data

Projects in each sub category the projects where named as:

• research-<group>-<project>

or if there are functional subgroups (msc, phd) then they are also included with a project or lastname identifier:

• research-<group>-<subgroup>-<lastname>

Examples:

• research-scb-data-archive
• research-tc-<lastname>-project
• research-sbi-nwo-54mt5
• research-sbi-phd-<lastname>

The good: inserting the administrative group and functional subgroups into the project name. The bad: The sub-category should be used more effectively and for something else.

Note that AIMMS uses Yoda 1.1 so I some questions about the latest version:

• at what level can a data manager be defined: category/subcategory?
• at what level can metadata be customised: category/subcategory?

[peer35]

AFAIK both data manager and metadata are still defined at category level in 1.6

I will also take a look at how subcategory and category are set in the irods metadata to see how useful they are for finding and reporting.

[peer35]

It looks like our first publication will be an archaelogy project. So that will also be the first project in the vault. Possibilities for categories:

• Archaeology

• Faculty of Humanities

• CLUE (multi-disciplinary institute for landscape archaeology. If Maurice is involved it's probably via them, will check with him.) (- SPINlab (Maurice is part of this institute, part of Spatial economics, part of SBE, also multi-disciplinary, although they have no official status like CLUE, so probably not a good idea. The project definitely has nothing to do with spatial economics)).

• Metadata-wise it makes sense to group Archaeological datasets together.

• CLUE (https://clue.vu.nl/) might make sense financially and organizationally, maybe less so with regards to metadata.

• Faculty-level might make sense for the Yoda datamanager role. Although that person can also take the role for Archaeology and/or CLUE categories

[peer35]

Group name: research-fgw-archaeology-<project> Maybe: research-fgw-clue-<project>

[peer35]

See #23 Some more info about the project here: https://euboia.labs.vu.nl/about.html

PI is https://research.vu.nl/en/persons/jan-paul-crielaard Full Professor, Faculty of Humanities, Art and Culture, History, Antiquity Full Professor, CLUE+

[peer35]

https://www.clue.vu.nl/en/projects/current-projects/sea-and-landroutes-of-southern-Euboia/index.aspx

https://fgw.vu.nl/en/about-the-faculty/index.aspx states: "Scientific research at the VU is done within two Research institutes: CLUE+ and The Netwerk Institute."

So I would suggest we go with: research-fgw-clue-seslr

[bgoli]

I like this approach. So the generic template would be something like:

research-<faculty_abbreviation>-<institute_or_department_abbreviation>-<projectname>

So my examples from above would be:

research-beta-cap-data-archive
research-beta-cap-<lastname>-project
research-beta-mcb-nwo-54mt5
research-beta-mcb-phd-<lastname>

or

research-beta-aimms-data-archive
research-beta-aimms-<lastname>-project
research-beta-aimms-nwo-54mt5
research-beta-aimms-phd-<lastname.

However, research groups could always define their own structure in the <projectname>:

research-beta-aimms-scb-data-archive
research-beta-tc-<lastname>-project
research-beta-aimms-sbi-nwo-54mt5
research-beta-mcb-sbi-phd-<lastname>

Is there a list of department/institute abbreviations out there or could we generate one for ourselves? The advantage of maintaining our own is it could be kept a unique set, in which case we could consider dropping the (even sometime in the future).

If we do this we can free up

• categories: for projects managed by the same data manager and common metadata
• sub-categories: would it make sense to ask to have metadata customisable at this level?

[peer35]

Moved the fgw projects

[peer35]

Maybe we can get a list of departments from Pure. I can ask the admin, or probably get it myself with the API.

https://research.vu.nl/ws/api/518/api-docs/index.html#!/organisational45units/listOrganisationalUnits

Needs a bit of effort to parse, I'll add the scripts to the api tools repo.

[peer35]

https://github.com/vu-rdm-tech/api-scripts/blob/master/pure/pure_ou.json

Research institutes are not associated with faculties in Pure. Kind of makes sense because they could contain researchers of multiple faculties.

[bgoli]

Interesting. In your example with archaeology, the only issue that may be problematic is that the Data Manager Role can only be defined on the faculty level ... we should consider the implications on workflow?

What about this for a completely leftfield idea. We make departments the categories and then, if necessary, include the faculty (and department) in the project name.

[peer35]

Note: Yoda stores (sub)category info in the metadata of the iRODS group. It is possible to move a group to a different category, Yoda will also fix the datamanager authorization. https://github.com/vu-rdm-tech/yoda-pilot/wiki/notes

[bgoli]

Good to know.

Jumping back to my previous idea it might be more interesting than I originally thought as it virtually eliminates the need for structured project names. Although, we can/should still do something purely for human readable purposes.

Given Yoda's current structure would the following work?

Category -> departments Sub-category -> research groups Category data manager group -> for Yoda workflow management priv-group-add -> users that can create projects

Department of Art & Culture, History, and Antiquity

• Description: FGW
• priv-group-add: FGW data steward
• Data manager group members: FGW data steward
• Sub-category list:

Biological Psychology

• Description: FGB
• priv-group-add: FGB data steward
• Data manager group members: FGB data steward, Biological Psychology data manager
• Sub-category list: Research Group 1

Molecular Cell Biology

• Description: BETA
• priv-group-add: BETA data steward
• Data manager group members: BETA data steward, AIMMS data steward
• Sub-category list: Systems Biology Lab, Structural Biology

Chemistry and Pharmaceutical Sciences

• Description: BETA
• priv-group-add: BETA data steward
• Data manager group members: BETA data steward, AIMMS data steward
• Sub-category list: Theoretical Chemistry, Science Business & Innovation

The advantage of this is this gives us a flexible basis to define faculties, institutes, etc.

[peer35]

I've now put the ou's in a tree for readability: https://github.com/vu-rdm-tech/api-scripts/blob/master/pure/pure_ou.json

[peer35]

To summarize: Yoda constraints:

• Datamanager role is defined at category level (but a person can have that role for multiple categories)
• You can always move groups to a different category, although this might get complex once you have hundreds of projects.
• Metadata schemas are set at the category level (although that might change in the future)
• Storage usage reporting is at category level, but we can always implement our own reporting so this should not be a big consideration.
• A datamanager in the priv-group-add system group can create groups in the categories he has access to
• It makes sense to reserve the priv-category-add to admins only
• Group names must be unique
• Group names can't be changed
• Authorizations are set at the group level so a research project = one (or more if needed) group

System constraints: As always with filenames:

• Only lowercase
• No spaces
• No punctuation except - and _
• No diacritics

Usability:

• In webdav, iRODS and Research/vault in the portal you only see the group names, but no category information. So the names themselves should be clear, especially for those users who have access to a lot of groups (like data managers).

Long term considerations:

• Group names and categories should always provide clues as to who is responsible even when all the users are gone from the VU (remember we are doing this for 10 years).
• Departments and even faculty names could be changed, we can't help that. We could reflect these changes in Yoda by moving (sub)categories.
• Orphaned research- and vault- folders will always be accessible by the datamanagers of the category they are part of.

[peer35]

I agree it does not make sense to have the faculty as category, certainly not for large and diverse faculties.

Let's keep categories relatively small. So that means the category level should be research institutes and/or departments. The actual division might differ across faculties: researcht institutes for FGW, departments for SBE.

[peer35]

Started a wiki here: https://github.com/vu-rdm-tech/yoda-pilot/wiki/naming

BETA: Mix of institutes and departments?

FGW: Categories = Research institutes: CLUE+ & Network Institute

FRT: https://www.frt.vu.nl/en/research/index.aspx The research is conducted in two Research Departments: Texts and Traditions, and Beliefs and Practices, which are brought together in the inter-faculty research institute VISOR, in which theologians, philosophers, historians, anthropologists and literary and religious scholars work alongside each other. Category = VISOR

LAW: ??

SBE: Categories = Departments Are there relevant Research institutes?

FGB: Biological Psychology Clinical, Neuro- & Developmental Psychology Educational and Family Studies Experimental and Applied Psychology Human Movement Sciences ,

Institutes: LEARN! Amsterdam Movement Sciences Network Institute Amsterdam Neuroscience

which makes more sense?

• Research institute: Amsterdam Movement Sciences and subdepartments or
• Department: Human Movement Sciences and subdepartments

FSW Departments??

[bgoli]

Great idea with the wiki. One question though, doesn't FGB have 5 departments https://www.fgb.vu.nl/en/departments/index.aspx ?

[peer35]

Added them, still a choice to make between the research institutes and departments....

[peer35]

I've now excluded the ou's that no longer exist. And created a readable list. https://github.com/vu-rdm-tech/api-scripts/blob/master/pure/pure_list.txt copied in the wiki to: https://github.com/vu-rdm-tech/yoda-pilot/wiki/VU-organisational-Units

[peer35]

• There is no official list of abbreviations for departments. Mail and AD groups names are also "made up" as needed.
• SAP number codes are not a good idea: they are not very recognizable and they can change, so on the longer term they will be too confusing.

Conclusion: we should ask the data managers and researchers for suitable abbreviations, taking care they can be matched to Pure.

[peer35]

"Orgeenlijst" on vunet: https://vunet.login.vu.nl/_layouts/SharePoint.Tridion.WebParts/download.aspx?cid=tcm%3a164-336765-16

[peer35]

Talked to the Pure specialist:

• Employee information is loaded from SAP into a sync database, including the "orgeen" codes.
• All the hierarchical organizational unit info is entered into the sync database manually. Based on the "Orgeenlijst" and info from the faculty liaisions.
• This sync db is automatically read into Pure.
• A researcher is always a member of a faculty department and might also be a member of a research institute.

So this looks like the best vetted list of departments. But should we use research institutes or just departments?

[peer35]

Other potentially useful info:

• All the "2e en 3e geldstroom"-projects are entered in Pure including associated researchers. (Although I don't think it makes sense to provision this in Yoda)

[bgoli]

If we could get access to snapshots of the sync database we could use that. We should also check the definition of an 'institute'

Regarding departments/institutes I think that practically the way to go might be to use where the funds are going to (potentially) come from and the type of storage:

• project grants --> project funds but located in department
• departement funded storage (e.g. MSc/PhD data) --> use a department
• institute funded storage --> (e.g. Data resources, genomic) use an institute

[peer35]

Can now confirm it is possible and easy to create the initial categories + data manager groups + data manager accounts (if known) via the web API. See #42

[peer35]

Moved to https://jira.vu.nl/browse/RDA-133, closing this one