paul walk: relevant content on this site

Confidence, and the business of persistent identification

Paul Walk — Thu, 28 Oct 2010 12:48:10 +0000

The persistent identification of resources is a foundational element of the JISC Information Environment. There are several schemes and technologies available to support this, with one of the most prominently used in the JISC IE being the Digital Object Identifier (DOI). Built on the Handle technology, the DOI, under the stewardship of the not-for-profit International DOI Foundation (IDF), adds the important element of collective commitment and management, based on straightforward business interests. DOIs are allocated and managed through Registration Agencies (RAs).

DOI has become somewhat synonymous with scholarly publishing, with most people working in the JISC IE having encountered them in citations for papers in online journals and repositories. However, while publishers continue to play an important role in minting and using DOIs, the use of DOIs to persistently identify datasets produced in research is growing in significance. Last year saw the creation of a new RA - DataCite, which deals with this relatively new and growing area.

There has been much debate over the years about the persistent identification of resources - especially at the technical level. Yet all technical solutions are bound, eventually, to come up against the issue of the persistence, or lack thereof, of organisations of people. In the JISC IE space we can see that publishers come and go, and that journal titles, for example, merge or change ownership from time to time. Universities, seen by many as very persistent organisations (a pre-conception which might, sadly, be tested in the next few years) do, nonetheless, merge and change.

The creation of a body which has as its primary goal the management of the persistence of identifiers - essentially the role of the Registration Agency in DOI - is an approach to addressing this lack of permanence. Within the 'ecosystem' of the RAs, each participant has a vested interest not only in maintaing their own identifiers, but in ensuring that the system as a whole continues to function well. From this point of view, it is in the interests of all participants that the commitment from others is strong which means that the addition of new RAs, such as DataCite, can only be a good thing.

Over the last year or so, IDF has been working with MovieLabs as part of a project to establish the not-for-profit Entertainment Identifier Registry (EIDR). This initiative includes the establishment of a new Registration Agency for DOIs for all digital resources created for TV and film by a consortium of many of the major producers in the entertainment industry. EIDR is actively seeking more participants, and offers a variety of types of membership.

While the engagement of this new industry may not be directly relevant to many people working in the scope of the JISC IE, the confidence and investment which this industry has placed in the DOI system is significant. This development increases the viability of DOI in general and, as such, should make it a more attractive prospect to those working in the JISC IE and in HE in the UK generally.

Essentially, confidence is an important aspect of persistence - and significant buy-in to DOI from such different sectors, commercial and public, should increase confidence in this solution.

A whitepaper about EIDR is available on request.

An introduction to DOI in a higher education context (set of presentation slides)

Aggregation and the Resource Discovery Taskforce vision

Paul Walk — Thu, 19 Aug 2010 12:43:35 +0000

On Tuesday of this week, UKOLN convened a group of invited experts to discuss aggregation in the context of the Resource Discovery Taskforce's vision. The Resource Discovery Taskforce (RDTF), a joint JISC / RLUK venture, has summed up its vision:

UK researchers and students will have easy, flexible and ongoing access to content and services through a collaborative, aggregated and integrated resource discovery and delivery framework which is comprehensive, open and sustainable

Given the limitations of time and resources, and with a firm intention to make a real contribution, the RDTF has decided to focus on aggregation of metadata as a means to progressing the vision. There was some debate at the meeting about the extent to which aggregation is something worth focussing on, and a general concern that this not become an end in itself, rather than a means to an end. We agreed to use the phrase 'aggregation as a tactic' as a way of characterising the proper relationship of this approach to the vision, and steered the remainder of the meeting to address aggregation from a mainly technical perspective. To get the ball rolling, I introduced a slide wherein I attempt to list possible reasons for aggregating data:

to address systems/network latency - a cache
for ‘Web Scale concentration’
- ‘gaming’ Google - raising ‘visibility’ of content
- network effects if user facing services also developed
to showcase (e.g. scale & nature of OER in UK)
to create middleman business opportunities
as infrastructure to support locally developed services
as an approach to preservation

This was discussed at some length, and we agreed that some other reasons could be added to this list:

for economic reasons - e.g. to achieve economies of scale through storing & managing metadata in one place, implying that the aggregation becomes the sole source of a given metadata record
to add value to the data through processes, especially around data quality, which are impractical or even impossible to contemplate when the metadata is distributed
to simplify licensing from the point of view of the consumer of the aggregated data

We noted that while the RDTF vision seems to concentrate on metadata describing resources and their provision, other types of metadata, such as user-generated annotations and user attention or activity data, which is also of great potential interest and value might be aggregated advantageously.

The importance of registries to help in the identification and discovery of relevant data was raised.

For the second part of the day we broke the meeting up into three smaller groups, each concentrating on an aspect of the preceding general discussions. Each of these groups, when they summarised their discussions for the whole meeting later, identified issues and made recommendations. Where these are generally applicable (which they mostly are), rather than outline them in the following descriptions of the breakout groups I have treated them together in two sections at the end of this post.

Breakout 1: APIs

This group looked at the role which Application Programming Interfaces (APIs) have to play in an environment of aggregated metadata and related services. It used a spectrum of technological interventions ranging from specific service development to meet a particular need, through to generic infrastructure provision to provide opportunities for others to develop services, and attempted to place classes of APIs on this spectrum:

It was agreed that it was important to understand this distinction, and to be equipped to judge where to 'draw the line' between meeting specific requirements and investing in capacity for future innovation. There is clearly a tension between agility - which is a feature which becomes more desirable as one moves along the spectrum towards those servicing users' requirements, and stability which is necessary for infrastructure to be trusted. Part of the purpose of APIs is to help to manage this tension.

APIs are for developers, and so APIs on aggregations must be highly usable from the point of view of a developer. Focussing on the need for aggregations to expose APIs so that services can build upon them, this group made some recommendations (included in the general recommendations at the end of this post) about the sorts of general features an API should exhibit. In general, it was agreed that an API on an aggregation must be more convenient, from the point of view of a developer, than going directly to the individual sources. Leaving aside simple issues of network latency, in a possible Linked Data future where data is commonly openly available, the aggregation and its API must not become a barrier to building services and adding value to data.

This group also discussed the issue of federation of aggregations - where one aggregation feeds another. There are serious engineering issues with this kind of federation which require better understanding.

Breakout 2: Aggregation as tactic

This group decided to start by looking for "prior art" - examples of successful uses of aggregation as an tactic to improving resource discovery. With this approach, it was suggested, it would be possible to identify stakeholder groups which are already 'bought into' the idea of using aggregation as a tactic in this way, which ought to be easier than convincing people from scratch. The trick would seem be to be to identify a shared service which could be developed upon an aggregation of metadata, and which they could recognise would be beneficial to them. Examples of successful aggregations were identified and included:

Copac (aggregated records from National, Academic, and Specialist Library Catalogues)
SUNCAT (a national serials union catalogue)
Worldcat (a global, aggregated library catalogue)

Echoing an earlier point, the group suggested that the value in aggregation as a tactic comes from the ability to normalise metadata into some sort of canonical form. This aspect of the aggregation adding value to the data it aggregates is crucial if the source record holders are to be persuaded to participate.

The group suggested that JORUM's role in supporting the national (and global) Open Educational Resources (OER) movement was very much in line with this thinking: that JORUM enhances discoverability of OERs created in UK institutions, while simultaneously offering the potential for long term archiving (preservation). Again, the importance of the registry becomes apparent this group suggested, with JORUM likely to become important as a service providing identification and 'provenance' services.

The group discussed the idea of concentrating on one particular domain, such as geography, on the grounds that this could then be built out to an extent that other domains would become interested once they had seen what has been achieved. The counter to this argument was a suggestion that it might be better to consider a range of resource types including scholarly communications (bibliographic data), learning materials, repositories, spatial/geographical data and multi-media.

It was also noted that the 'aggregation as a tactic' argument might apply to self-archiving and Open Access - which has similar arguments as for JORUM and OERs.

It was suggested that this was leading to a set of tactics which would help content providers get over a 'fear' of aggregation, and of encouraging them to open up from a position of 'data ownership'. It was also recognised that once this is achieved, aggregation as a tactic creates opportunities for 'middle-men' to add value through new services building on top of the aggregation.

Interestingly, this group suggested that aggregation as a tactic might be a short-or-medium-term tactic, that the 'end game' would be to dis-aggregate content back to source. At this point, the remaining infrastructure would be of the 'registry' type, helping to locate data at source.

Breakout 3: Build better websites!

The emphasis of this session was about advising & enabling those who hold source metadata to make it available in an appropriate form. The group identified a number of 'steps' that a content provider might take. These steps are ordered in a system of progressive desirability in a model influenced by Tim Berners-Lee's Linked Data Note:

make data available in an open form (even using the much-maligned CSV format if necessary)
assign and expose HTTP URIs for everything, and expose useful content at those URIs
publish as XML
expose semantics

It was noted that these steps do not demand that a provider should work their way through them sequentially - it is perfectly acceptable and even desirable to jump in at step 4 - however this might represent a significant barrier to some, so steps 1-3 are there to give content providers a chance to engage comfortably.

Barriers specific to this model being adopted successfully include the issue of securing vendor 'buy-in'. For content providers to support this model, their software platforms need to enable it. This may not be the case at present in most cases. Also, specific skills in Linked Data are not so widespread in these sectors (yet), and an appreciation of and support for Linked Data is not common among senior managers. It was recommended that JISC create some political momentum around this, perhaps devising a convincing argument for senior management. It was also suggested in this breakout group that RDTF should provide a central resource (guidance & possibly infrastructure) for hosting data, especially for smaller organisations.

This approach was summed up as a description of a potential glam.ac.uk where glam is galleries, libraries, archives and museums.

General Issues

Lack of technical expertise in libraries, museums and archives. This applies most strongly in respect of the 'build better websites' model, but is also true more generally, especially when the long-tail of glams is considered.
Business case, or possible lack thereof. The content providers need to see a clear benefit before committing to the cost involved in supporting the aggregation of their data.
Content providers often show a reluctance to make data openly available on the grounds that they may expose poor quality which reflects badly on them

Recommendations

The various discussions during the meeting gave rise to a number of suggested recommendations. It should be noted that these are based on a few short hours of discussion - however the experience of the group which made them is considerable, so I hope they might be considered seriously.

The 4 step model for advising/supporting content providers in opening up their metadata
The RDTF should fund aggregation projects that demonstrate value in these steps
- e.g. "Tell me how my content is being used"
Providers should provide a semantic sitemap leading to a data aggregation. This could be RDF or XML
Providers should expose the schemas they use (whether their own schemas or links to established schemas)
Aggregation services should provide guidance to content providers about schemas to be used (a registry of recommended schemas would be a useful component)
Aggregators should not reject data on basis of schema used by the content provider - aggregators should be prepared to accept anything
The RDTF should (in partnership with others) seek to engage with vendors of collections/content management systems in the various domains.
Aggregations should have supported APIs which are attractive to and convenient for developers, offering developer-friendly output formats such as XML or JSON
Aggregation should be considered, perhaps, as a temporary approach to aiding discoverability. More extremely, a 'just in time' approach to aggregation might be considered.
A 'cookbook' of design patterns involving aggregation as a technical approach to resource discovery might be a useful thing to consider funding.
A '2 tier' model of metadata might be worth considering, where one tier is for common, basic description and identification, and the other tier is for more targeted uses.

Many thanks to those who attended and made the meeting a success:

Peter Burnhill (Edina)
Hugh Glaser (Seme4)
David Kay (Sero)
Andrew Kitchen (Becta)
Ross MacIntyre (Mimas)
Andy McGregor (JISC)
Paul Miller (Cloud of Data)
Andy Powell (Eduserv)
Owen Stephens (independent)
Adrian Stevenson (UKOLN)
Paul Walk (UKOLN)
Jo Walsh (Edina)

And thanks to Adrian also for organising the meeting.

Provision, fusion, presentation and shared infrastructure

Paul Walk — Tue, 01 Dec 2009 10:56:00 +0000

The JISC IE introduced a characterisation of service types which categorised them into one of provision, fusion, presentation or shared infrastructure. It should be stressed that this characterisation was not meant to be strict so much as it was intended to be a device to aid high level thinking around the problem space with which the IE is concerned. The fact that the iconic diagram (above) has become so closely associated with the IE is a testament to the appeal of this approach. The architecture which this categorisation scheme implies is informed by the contemporary interest in the Service Oriented Architecture (SOA) as an approach to sector-wide service provision and usage, and underpins the expectation of an environment evolving out of strategic investment, machine-level interoperability through open standards, and a separation of concerns.

Largely unanticipated only a few years ago, the effect of the Web 2.0 phenomenon on how users interact with services and on how services inter-operate has been profound. The diagram above implies a flow of information towards the user: the reality today is that users expect to interact with services with richer interfaces than was the case 3-4 years ago. The idea of a distinct layer of presentation services is something which is surely challenged today, as is the positioning of provision services, somewhat remote from the user, with layers of intervening services.

Having said that, while the diagram with its divisions of provision, fusion or presentation services might appear now to be an over-simplification of how services in the IE could fit together, it was in truth never intended to be a blueprint or even an architecture.The introduction to the IE of some of the fundamentals of modern systems design, such as the separation of concerns and modularity of services encouraged by the SOA has been valuable. However, it could be (and has been) argued that a Resource-Oriented-Architecture (ROA) is a better fit for the IE. We will examine the relevance of ROA to the JISC IE in detail in a subsequent post. In the meantime, we should take the opportunity to review the impact and continuing relevance of this approach.

Questions:

Is the characterisation of provision, fusion or presentation still useful? If not, is there a better categorisation we might adopt, or is this whole approach no longer useful?
How has the emergence of simple point-to-point services on the Web affected this picture?
Rather than a focus on services, there would seem to be an emerging emphasis on users and data. How should this inform the evolution of the JISC IE’s technical foundations?

Further Reading on this topic:

Mapping the JISC IE service landscape, Andy Powell, Ariadne, Issue 36

The JISC IE: Some lessons from Web 2.0 , Paul Walk, presentation to the JISC IE Working Group

Lost in the JISC Information Environment, Tony Ross, Ariadne, Issue 56

Lost in the JISC Information Environment? a post by Andy Powell on the eFoundations blog

All models are wrong, but some are useful, a post (+ associated comments) on Paul Walk’s blog

The collaborative research environment: publications management, CRIS systems and repositories

Talat Chaudhri — Thu, 02 Apr 2009 16:41:00 +0000

Some months ago, I intended to write a post inspired by this post by Chris Rusbridge on CRIS systems. One particular motivation for this was reference he made to some comments by Stuart Lewis, particularly relating to the Symplectic Publications Management System. This was the subject of an impressive demo in Aberystwyth by Daniel Hook of Symplectic and Imperial College, London, while I was in my previous post as Repository Advisor. We were very interested by CRIS systems as back-end systems for managing research outputs at source. I believe that Stuart had been in touch with Niamh Brennan, who has since been kind enough to give me some general details about the CRIS system that has been produced in-house at Trinity College, Dublin. I should note that I have not seen it in operation.

One reason that I never published the original post is that most commentators in the repository community probably agree that a CRIS is innately a Good Thing in any event, so it needs no detailed endorsement from me. (A further concern is that I do not wish to be seen to be making specific comments on developments at Aberystwyth, which is a matter for them, so I shall confine my remarks to the systems at issue here.) In short, as Stuart’s comments cited by Chris in the above blog make clear, the CRIS does not replace the repository but “sits behind it” and provides content. There are of course a great variety of ways in which this could be achieved in practice, depending on the particular system in question. I will address the definition of a CRIS further below. However, the Symplectic system deserves more detailed commentary here, for reasons that will become clear.

Symplectic Publications Management System

There seems no reason to doubt Symplectic’s obvious competence in publications management, having witnessed how effective this piece of software had already been, albeit having only been tested in a limited number of institutions at the time. It was, to my mind, impressive that Daniel Hook was both frank and receptive about the merits and development potential of his system. Indeed he had no real need for the hard sell because the software had been built "by academics for academics", so it consequently fulfilled most of the basic requirements already and many of the other features that he was questioned about were already in the pipeline.

However, this post is by no means intended as a wholehearted eulogy directed at the Symplectic system. It was developed in the context of scientific disciplines, and had not at the time been tested in arts and humanities disciplines, although to be fair this point was made openly by Daniel Hook himself. I do not see why it should fail in principle in non-science disciplines, although the take-up may be less enthusiastic in the same way that one finds in repositories. The real problem is the limited coverage of these disciplines by union databases such as Web of Science, though this is not the fault of Symplectic. Their efforts may in time provide one reason to improve those databases, which underlie the core functionality of the system.

Briefly, the system replaces the university's reporting system. The academic logs on and merely has to choose whether to agree that a new paper in Web of Science belongs to him or her. They are able to declare that it is identical to another version, perhaps in another database, or else they can separate two papers of the same name, e.g. a conference paper and a published paper. They can optionally correct the metadata. Evidently, for papers not found in Web of Science, academics can enter the details of the papers manually, although this process then loses all of its automated advantage over author self-deposit in a repository. For this reason, the system has the greatest advantage in science subjects. The administrator can see whether academics are responding to its suggestions and thus, in disciplines with good database coverage, can gain a good idea of how comprehensively they are archiving content. Finally the system is entirely interoperable with DSpace, so that items may be deposited through either interface (I am less sure about EPrints and Fedora). Permissions can be set and delegated on a fairly granular level, unlike in repositories, so that academics can have control over who can deposit items on their behalf, such as co-authors.

The system provides useful tools to help simplify and automate research reporting that is already mandatory for academics, rather than introducing new obligations and unnecessarily duplicating the deposit/ingest phase. By contrast, repositories require this as an additional process, after research reporting. Of course, certain repositories are used for research reporting, which requires an effective or explicit institutional mandate, but in their present forms they are badly suited to describing the finer details of funding grants and projects. This is handled rather better by Symplectic, but obviously requires manual metadata input.

It may come as no surprise, given my involvement with SWAP, that I should level a criticism at the Symplectic system on the basis of its simple versioning model. Clearly one might wish to be able to say more than whether two papers are identical or not. It was clear that no complex relationships could be described at the time of the demo. I hope that this is addressed in future iterations of the software.

CRIS systems

A further issue is whether the Symplectic system qualifies as a CRIS at all, as pointed out to me by Niamh Brennan. Apparently it does not. There is no indication that it supports the CERIF standard maintained by EuroCRIS, and moreover it does not provide the means to support the creation and versioning of research outputs and related project information from their very inception, which is one of the purposes of a CRIS system. Instead, it only deals with papers after publication, in the same way as a repository.

Whether or not academics, particularly those whose working practices are long-established, would willingly switch over to using a CRIS in this way is perhaps a matter for doubt. It might be possible to compare, for example, mandated and voluntary use of CRIS systems, but at present I have no evidence for the relative feasibility or success of either approach. I hope to be able to see other CRIS systems in action, and that an Open Source platform will become available before long. I suspect that they have considerable potential in managing research and making it freely available. However, it may be naïve to simply assume that they will provide a complete solution for research management. At present, the only commercial software seems to be PURE, given the apparent demise of UniCRIS there appear to be three commercial competitors: CONVERIS, PURE and UniCRIS [updated 22/09/2009].

The functionality that these systems highlight that traditional repository platforms lack – with the proviso of course that no two in-house CRIS systems necessarily share the same functionality – is the ability to offer a collaborative environment for research management and research reporting. In the case of a CRIS, this is supposed to extend to the creation of research from its inception. As a repository manager, I recall being asked by several academics why they were unable to manage their own metadata in our repository, considering that responsibility for their own research is a core function of their employment. This is an entirely fair criticism, to which I will return.

It is difficult to see why a CRIS should not share all of the main characteristics of a repository. Both manage the ingest of bitstreams and the creation of metadata. Both repositories and the Symplectic system can be used to expose these materials to the web or alternatively set permissions to view them, and to generate publications lists for authors or research groups. Ultimately these are a set of very similar systems with slightly different but related, complementary purposes.

Implications for repositories

This discussion highlights the conceptual similarity of the current repository platforms to publication platforms, despite the usual claim that they are not publishing research but merely archiving it after publication. In legal and practical terms at least, they are self-evidently re-publishing it by making it publicly available in a further location. (One might speculate that this is the reason for the animosity of certain publishers towards repositories.) After all, to publish ultimately means to make public. But in academic usage, publishing also includes peer review. In my view, it might be a good time to start drawing a clear distinction between these functions.

I have heard Paul Walk refer many times to the “silo effect”, which seems to be at the core of the problem with the present repository platforms. Unlike other websites, the repository is not an interactive site. Having seen the statistics for repository access using Google Analytics, I can report that only a small minority of visitors access the site directly or by referral from university web pages. Virtually all papers are found using Google (only rarely other search engines) and those visitors do not remain on the site after they have found the content. They are largely oblivious to the existence of the repository. Very few users were referred by Intute or OAIster. All of these problems are to some extent unavoidable and well-known, but the repository should at least be more interactive than it is from the point of view of the depositors.

I should note that the large part of my experience with repositories relates to DSpace, though I am also familiar with EPrints. The My DSpace (user area) function offers the user no functionality other than being able to change their personal details and submit content, and even the latter usually requires manual authorisation by the administrator. EPrints is generally similar. This immediately results in confusion, erroneous error reports and so on from sometimes irate new users, but it is quite logical for the repository manager, who needs to know who is submitting content and generally wants to intervene to give basic initial copyright advice in order to save problems later with incorrect versions being supplied.

There is clearly a role for automating the setting of permissions for deposit on the basis of staff records. Though it presents problems, it can be done routinely for other university software systems (including apparently the Symplectic system). I would be interested to hear whether this has been done successfully in the majority of EPrints and DSpace repositories.

But the issue runs deeper: the only tool that the repository manager has to safeguard copyright liabilities is the ability to monitor submissions. It would be most unwise to set editorial permissions for all authors over their own metadata because there is no function to view recent changes, only recent deposits. Such changes might easily be in breach of copyright, despite the author’s best intentions. (In DSpace up to version 1.5, permissions can only be set by group, not for individual authors.) There is no easy versioning system, such as the sort used in wikis, and any changes to bitstreams can normally only be reversed by recourse to restoring from general back-ups.

It is evident to me that the present situation is not scalable. When the majority or even the plurality of research outputs are available, there will be far too much in each repository for its staff to deal with. A more scalable, collaborative solution is needed before that situation is reached, involving all parties concerned with the production of research in maintaining it on the web.

General recommendations

To summarise, the consequence is that items are “frozen” as soon as the repository manager completes checking for copyright checking and basic metadata compliance, after which any changes must be requested by email. The following features would need to be in place in order to allow repository managers to implement a more collaborative worklow:

(1) historical versioning control needs to be in place for editors to have the ability to easily roll back records and choose
which may be viewed by the public.

(2) in addition to the initial checking step in the workflow, all recent changes to the repository need to be visible to the repository manager. These could be vetted, i.e. they could remain pending until allowed by the repository manager, if desired.

(3) users need to be better identified as authors, even where another individual, e.g. co-author or administrator, has deposited on their behalf.

(4) the permissions system needs to allow granular control over what an individual may change within their own deposits, whether bitstreams or metadata, and within groups in the repository.

(5) bitstreams and links to versions elsewhere on the web should be treated equally in the interface, since the user is concerned with getting the resource, not where it is.

(6) as in the Symplectic system, users should be allowed to delegate those rights to individuals within their workgroup.

(7) as in Symplectic, users should have control over which publications appear in their publications list, and in what order.

It would also be desirable for repositories to use a method similar to that used by Symplectic to compare records to new items appearing in Web of Science. In that way, authors would have an ongoing dialogue with the repository, and an impetus to use it as a collaborative tool. In effect, there should be no conceptual difference between a publications management system and a repository – and, frankly, the former term is instantly meaningful to the user, while the latter means nothing to them at all. Such public relations disasters have led to the present stagnation in repositories. I would suggest that in any working system, the CRIS, the publications management system and the repository ideally need to be modular parts of the same software.

The repository world currently suffers from a dictatorial, top-down management structure that is in considerable part imposed by the design of the current repository platforms. At present, repositories do not meet the standards of collaborative software that we come to expect from Web 2.0 services. They also seem to be in direct conflict with the traditional responsibility of the academic and/or department for proper research reporting within the institution. The Symplectic Publications Management System and the concept of CRIS systems offer a more collaborative model that can help avoid repeating the same tasks. In addition, they can help record complex grant information, some of it confidential or commercial, that may not be for public release on the Web. Moreover, they offer an interactive workflow with real time-saving benefits for academics. In contrast, self-archiving in repositories merely repeats a task that is mandatory elsewhere, and does not represent joined-up thinking.

Incorporating the already mandatory process of research reporting into such systems would effectively by-pass the need for institutional mandates for self-archiving by incorporating it into the existing workflow using new software tools. Progress with such mandates has been crushingly slow, despite the success of the few that have been achieved. However, since all institutions are organised differently, it is simply not the case that only one single method for acquiring freely accessible content, however effective when implemented, is the only possible way to success. Collaborative research management is clearly a good idea for this end, as well as for saving time and effort on the part of academics, irrespective of the merits of institutional mandates. It would also be a more scalable, sustainable basis for repositories to work that the present situation. On that basis, I suggest that it may well be a Good Thing.