Common requirements for UAB and JOIN2¶

Derived from UAB requirements:

Bibligraphic records¶

• [R] Internal format must be MARC21. This is necessary to keep many of the current data we keep in our records, like the library catalog id, but also the links between fields that are not possible to describe in Dublin Core, like author-Orcid, author-affiliation, etc.
• [R] Records should be exported in different formats: DC, CVS, EDM, DataCite, BibTeX...
• [R] We should be able to parametrize which bibliographic fields should or should not be shown to the end user, because some of them must be for internal use only. Note for JOIN2: usually we do not hide anything unless money/cost codes/email addresses.
• [R] The system should not have a limit for the number of bibliographic records.
• [R] The system should allow us create our own indexes.
• [R] The system should be able to link records. Note for UAB: journal and articles.
• [R] The system should have forms for different types of documents.
• [R] The system should have forms for self-archiving. Note for JOIN2: this is understood as "it is possible to attache full text files and release them to OpenAccess or keep them private" UAB clarification: sorry, we ment that researchers themselves (that is, not the librarians) sould have specific forms (that is, different from the librarians).
• [O] Fields in the forms should be autocomplete. Note for JOIN2: for authority controlled fields this is mandatory, especially for complex fields with several consistent subfields.
• [O] Records should have version control.
• [O] There should be different metadata levels, for example for users and harvesters. Note for JOIN2: this is understood as "there should be customizeable serializations of the internal format depending on requirements"

Files and digital objects¶

• [R] The system should accept any file format (for example, for research data can be anything).
• [0] Files should have version control.

Notes for JOIN2

• [O] The system should keep the current directory and file structure. (O instead of R)
• [O] The system should be able to restrict the access to documents for an IP range. (O instead of R)

Usually, at JOIN2 we find that access restrictions on IP ranges do not suffice today any more. We do not rely on the directory structure as such, however, moving around some 10k full text files might be a lot easier if the file system structure can be maintained or easily transferred.

User interface¶

• [R] Our permanent links should be honored and kept. Our repository is commited to the Manteniment dels enllaços permanents. The repository is responsible for the custody of our digital objects and to keep them accessible. The permanent links are an explicit roles for preservation and access. We have committed to two types of permanent links: records and collections. Note for JOIN2 we do not believe in URLs (be it record urls or collections) to be valid over time, but register DOIs or the like to this end. However, keeping a DOI stable requires some way to tell where it has to point. Note especially that JOIN2 would not rely on collections at all.
• [R] The workflows should be clear. Note for JOIN2 we need quite a bit of defined workflow, at least replicating the 3-step-release workflow we have right now, preferably a more flexible module that could e.g. handle authorization steps.
• [O] The system should provide faceted search.
• [R] The system must allow flexibilty in order to personalize the web interface. Note for JOIN2 usually, we consider wording/CSS here. Not a full rewrite of an interface or full user customizable interfaces.

Notes for JOIN2:

• [O] The system should allow thumbnails for digital objects. (O instead of R)
• [O] The system must be multilingual. (O instead of R) Note english has to be the first class citizen.
• [O] The system has to follow the current best web practices and accessiblity web standards. (O instead of R) Note while we subscribe to the principle web standards change so frequently that a best effort to keep up to date will have to be good enough. (Besides that one can discuss the value of the word "standard" in a constant change.)

Interoperability¶

• [R] The system must provide an OAI-PMH server (current oai2d).
• [R] We should be able to keep using the programs and scripts to import and export records Note the UAB specifics do not apply, but as a rule of thumb the more im/exports the better, the less do-it-yourself the better.

For JOIN2 the following changes apply:

• [R] The system should provide OAI harvester (R instead of O) Note we have a lot of common authority data that requires interchange. If a separate system can handle this and is easily integrated that would be good enough. However, we'd then regard it as part of the package.

Users and permissions¶

• [R] User management should allow different user types, user authentication methods and authorizations. Authentication should allow LDAP and/or SSO methods.
• [R] Data from internal and external users and its interaction with the system must follow current laws.
• [R] The system must allow or deny the users to ingest files in the system according to his or her access rights. It should check whether the records or files are duplicated.
• [R] The records in review state must not be accessible via Google.

For JOIN2 the following changes apply:

• [O] Anonymous, external users should be able to create accounts for themselves and keep their password management. (O instead of R) Note usually, JOIN2 would prefer to handle this on a central system at the respective IT infrastrcutre. In this case those external users look like very other user. Further note: to log in is one thing, but to gain permissions is usually quite a different story. In our current use just be able to log in would not provide any additional features.

Social features and notifications¶

• [O] User alerts for specific searches Note for JOIN2 right now, we use alerts for our workflow
• [O] RSS
• [O] The system must support social networks.

Other¶

• [R] The software must be open source and have a free licence.
• [R] The system must be robust, and able to handle many simultanious users without affect the response time.
• [O] The system should provide standard statistics. Note for JOIN2 a lot of specific stuff will be required at this point. So this is read as "system usage statistics"
• [O] There should be a user community with a main developer and companies providing support. Note for JOIN2 companies proved very difficult in the past.
• [R] We should be able to have a test installation. Note for JOIN2 if it is to complex to handle this easily it's most likely a no-go. Also note that there is a definite preference for on site installations.
• [O] The system should provide an url checker for the 856 links. Note for JOIN2 it proved difficult in the past to really detect broken links as many system just relay to some other place a link without proper errors.
• [O] The system should check the integrity of the communications and the data kept in the repository.