It is important to take account of user's workflows when defining a repository so it is not considered a system that is removed from the users daily routine.
Which workflow/routine would this be, then? I agree with this idea in the sense of "take account of things users need to do", but not in the sense that we can reduce the myriad functions of an HE institution to a small set of flow charts and design repositories to fit those.
I agree that trying to get a manageable number of HE wide workflows would be an impossible task. However there might be common points in a large number of workflows that repositories could hook into. Say for example, use of a CRIS, use of word, use of a windows file management system, use of reference management tools. Perhaps couching repositories in terms of these familiar processes would help with selling deposit to researchers?
I agree to some extent, but I'm also wary of comments elsewhere from the likes of Peter Murray-Rust on this. He warns (my interpretation) that we need to be careful of doing this as if it complicates the workflow, it just won't happen.
I'm aware of some scenarios where the user's workflow is already fairly well systematised - in which cases this would make sense.
However, I suspect that in the majority of case this is not the case, so I think that in the general case the it isn't particularly helpful to make the user explicitly aware of the repository. Why should they be made to care?
@paul, I think we should be generic rather than systematic in relation to the word "workflow". This isn't kepler/taverna territory; more it's a general attempt to move the repository upstream, so that it is more helpful to the user, rather than being an extra, downstream burden.
Disagree - the repository is a back end data provider that should not be part of the researchers' / learners' workflow - but the service which sits on top of the repository should be part of the workflow.
Revise
Vote Up
Vote Down
Post New Comment
Close