A datamodel is a written specification of the content types and fields that are available in Pure. It is called an implemented datamodel once the types and fields have been set up in Pure with the correct relations and other specifications.
A number of country-specific datamodels are available. They are all modern CERIF-based datamodels that have been validated by local HEIs and research institutions. Pure is usually delivered with one of these models:
DATAMODEL | COUNTRIES | STANDARDISED | USERS |
UK | England, Scotland, N.I. | Yes | 15 |
DE | Germany, Austria | Yes | 1 |
DK | Denmark, Sweden | Yes | 38 |
DK (Colleges) | Denmark | Yes | 8 |
BE | Valonia, Flanders | Yes | 5 |
FI | Finland | Yes | 2 |
Each of these datamodels can be customised according to local requirements, although very little or even no customisation usually is needed. Institutions often choose to go intro production with the standard model as it is, to have customisations done later when or if necessary. Having Pure delivered with a standardised datamodel is free from any additional charge.
The fact that classifications (drop-downs with fixed values) and text- resources including all field-labels and user-interface concepts are configurable by system administrators reduces the need for datamodel customisation.
The Pure User group in a country is often used by Pure-owners as a forum for maintaining and extending the datamodel collaboratively in that country, especially when new national requirements must be dealt with e.g., new REF requirements in the UK, new FRIS initiatives in Belgium, etc. In such situations, the members of the national Pure User group can collectively define the changes they want, have them distributed at once to all members, and evenly share any costs that might be involved; costs for new supplementary functionality, for example.
Please also see Collaboration and cost-sharing.
The following is a table of typical content in any of Pure's CERIF-based datamodels:
CONTENT TYPE IN PURE | DESCRIPTION |
Projects | Title, abstract, primary investigator, co-investigator, other internal project participants, external collaborators, funding, budget, financial spending (in real-time), related outcome (publications, including fulltext), other related files (as attachments, index for searches), start- and stop-dates, file attachments, and more |
Research outputs | Contribution to journal, Chapter in Book/Report/Conference proceeding, Book/Report, Contribution to specialist publication, Working paper, Contribution to conference, Non-textual form, Thesis, Patent, Other contribution, , file attachments (fulltext), and more |
Persons, profiles and CVs | Names and name variations, IDs in other systems, gender, organisational affiliation, start- and stop dates, FTEs, fellowships, profile, file attachments, ,and more |
Organisational units | Type, names, IDs in other systems, profile, addresses, life-cycle, place in hierarchy, and more |
Funding applications and Awards | Type and name information, applicants, funding council or other funding body, funding programme, application status, financial summary of application, financial summary of award, fEC information (full Economic Costing), file attachments, and more |
Research activities and esteem | Awards, Conference participation, Business and community, Editorial work or peer review, External academic engagement, Public engagement and outreach |
External Persons | External authors on publications, contact persons at External Organisations |
External Organisations | External collaborations home and abroad; universities, private sector businesses, etc. Also used to record funding councils and similar stakeholders |
Publishers | Name and name-variations, ISBN root, ratings (recurring ratings over years), and more |
Journals | Type, titles, ISSN values, electronic and alternative ISSN, life cycle, SHERPA RoMEO colour and other information about OA, Impact Factors and ratings, and more |
Events | Type, title and related information, start- and stop-dates, related events, Degree of recognition, location, participants, organisers, sponsor organisation, and more |
Content types for assessment programmes | For the UK’s REF, for example, Pure incorporates Unit of Assessment, Assessment Output, Assessment Person, Impact statement, and Assessment Environment (with Research Income and Student Data). |
Apart from the datamodel in Pure, other areas are customisable too:
The system functionality, the User functionality, Roles and Rights, Workflows, Systems integration, Import functionality, Fulltext and Repository functionality, and PurePortal-functionality are probably the most important areas, but others exist as well.
All of this customisability is rarely used within one Pure-implementation project, but it must still be available to ensure the ability of the system to adapt to future demands as well.
When an institution has Pure customised, that institution's instance of Pure is kept on the same common codebase as all other customers. If this was not the case, we would have to port all Pure's new functionality from customer to customer instead of issuing releases centrally. The latter option would increase costs and introduce more errors and testing. The former is the more advanced and the more effective method for Release Management. Also, this method for release management is a prerequisite for Pure's unique options for cross-institutional Collaboration and cost-sharing.
Owners of Pure can configure things like classification schemes, user-interface text, help-pages and bullets, integration jobs with internal systems, integration parameters for external sources (e.g. WoS), integration parameters for internal source (HR system, finance, etc.), validation options, public website display-options, and other things.
In Pure, functionality is available for administrators and other relevant roles to configure Pure in these and other areas. User-configurability has been one of the main areas of development since Pure's introduction- one of the most recent contributions is the configurability of the standard PurePortal, as described in the separate section. This and other configuration options let users modify and adapt their Pure solution to current and emerging needs on an ad-hoc basis in a safe environment, which will not lead to loss of data or other inconveniences, and which can always be reset to default settings.
More information about this subject is available in the Pure whitepaper.
While private-sector companies rarely cooperate, publicly owned research institutions and HEIs often do. When we scoped Pure4, we wanted the system to support this potential for collaboration among its owners. The result is an architectural design, which facilitates collaborative, cross-institutional customisation and cost-sharing.
A number of Pure-using universities might for example have the same requirements for certain new functionality. With Pure4, they can join, write a common specification, have Atira make the new functionality, and share the cost four ways. Such new functionality will be distributed as part of the next regular release of Pure.
Only the four participating institutions will receive the new functionality.
If other institutions later want the new functionality, it can be distributed to them too at the discretion of the original four institutions.
Put differently, Pure4's architectural design allows distribution of custom functionality to:
1. Individual institutions
2. Groups of institutions
3. All institutions
We also refer to these distribution options as levels; the Customer level, the Base level, and the Core level.
OPTION | LEVEL | WHOM |
Distribute functionality | Customer level Base level Core level | An individual institution A group of institutions All institutions |
Distribute datamodel concept | Customer level Base level Core level | An individual institution A group of institutions All institutions |
The ability for CRIS owners to collectively specify custom functionality and to share the cost introduces opportunities, which are not available with conventional enterprise-class architecture.
The example above concerned custom functionality, but opportunities are available when datamodel modifications are concerned. In the UK, for example, HEFCE introduce new concepts for the REF, which would require datamodel modifications. With Pure4, these modifications could be made once centrally and distributed to all UK-institutions but not to anyone in continental Europe. The new REF-specific modifications would be distributed to all UK-institutions as part of a regular upgrade
Please note that these options for collaboration and cost-sharing among Pure-using institutions are just that: Options. Institutions can always act independently. Collaboration will remain an option, and individual customers will always be able to act independently.
Please also see Development policies. More information about this subject is available in the Pure whitepaper.
Since version 3, Pure has been able to meet most requirements for multi-tenancy. It was however not until the new architecture with Pure4, that a dedicated design-effort was made in order to ensure broad multi-tenancy support.
A group of institutions can run simultaneously in a single instance of Pure without penalties in data-disclosure flexibility, security, integrations, or support of individual business-processes.
Multi-tenancy is a configuration option with Pure, which is available to administrators. The following characteristics describe Pure4's multi-tenancy capabilities:
CHARACTERISTICS | DESCRIPTION |
Tenant-specific content access | When an institution is in Pure as a “tenant”, everything will look and feel as if that institution was in its own private instance of Pure - it will not see or otherwise access content of the other tenants such as Persons, Organisations, Publications, or Activities. |
Tenant-specific searches | Tenants can only search in own content and not that of other tenants. |
Tenant-specific reporting | Tenants can only create and run reports on own content and not on content belonging to other tenants. The same access limitations as are in an individual environment will also work in a tenancy environment within one tenant. |
Tenant-specific PurePortal | A PurePortal can be set up to exhibit only content from one tenant. There can be one such tenant-specific PurePortal per tenant. |
Global PurePortal | A PurePortal can be set up to exhibit content from all tenants. |
Web-Service API | The Web-Service API of Pure works in the same way as in individual environments when queried without specifying any particular tenant. However, the Web-Service API can also be queried while specifying a particular tenant and will in that case return results only for that tenant. |
OAI support | Pure’s OAI data-provider can make tenant-specific metadata available per tenant, and it can make data available from all tenants in one go. |
Global content types | Certain content types can be global: Publishers and Journals are practical to have globally in Pure, for example, because all tenants can benefit from them. Global content types can also be administrated globally (e.g. by librarians). |
Global workflows | There can be one workflow per content type in Pure. This is also true when serving multiple tenants. However, each workflow is flexible in itself, and can support different business processes for different tenants in different ways. |
Global bibliometric administration | Even when Pure is serving multiple tenants, bibliometrics can be managed globally. It is possible to globally update citations on all publications, for example, and to update impact factors on journals. |
Global system administration | A multi-tenant Pure environment can have administrators, which can administrate Pure globally |
When using Pure for multi-tenancy, the datamodel is global by definition: There can be only one datamodel per instance of Pure, and when serving multiple tenants, they will all have the same datamodel available.
The only way to serve different institutions with different datamodels is to let them have individual instances of Pure. If collaboration is still required, a datamodel core can be defined, which will be the same for a number of instances. This allows institutions to have individualised systems while still sharing central concepts.
More information about this subject is available in the Pure whitepaper.
MODULE | DESCRIPTION | OPTIONAL |
Basic module | The basis for any Pure installation, this module contains all basic user functionality. Please also see the page Functionality. | No |
CV module | Allows researchers to create different CVs (profile, publications, projects, grant successes, bibliometrics) for different purposes. CVs can be published online or printed. CVs can automatically update by rules when new content is added to Pure. | Yes |
Bibliometrics | Facilitates import and processing of citation data sets and impact-factors from Thomson-Reuters Web of Science and from Scopus. Also facilitate processing of imported data. Both import from files and online interfaces are possible. | Yes |
Reports | Users can create all-new reports or modify existing ones. Reports can contain lists, tables, calculations, and graphs and can be compound; i.e. several sets of criteria can be expressed in one report. Reports can be scheduled to run at a specified date and time and be distributed automatically to any number of e-mail addresses. | Yes |
Press clippings | Makes it possible to add press-clippings to Pure. Summaries or entire articles can be added. Such clippings can be imported from an XML feed or added manually and linked to Persons, Organisations, Projects or Publications. | Yes |
Student theses | Makes it possible to also have student theses in Pure. Not relevant with all data-models. | Yes |
External publications | Makes it possible to also have “external publications” in Pure (publications written by researchers during previous employments). Not relevant with all data-models. | Yes |
PurePortal | This framework makes it possible to build a public research portal that exhibits all public content from Pure in one go. Many features are available for public users; search and filtering, RSS-subscriptions, save-as-XML, floating diagrams, etc. | Yes |
REF2014 | This module adds functionality and datamodel concepts to Pure, which are necessary to make a full return upon census date. It also includes functionality to make full return scenarios by allocating staff differently to UoAs, for example. Predictive scoring is possible, as is import and comparison with 2008 RAE return data. This module is only relevant in the UK. | Yes |
Pure's architecture supports non-sequential updating. IT staff can choose to only install upgrades that contain relevant patches and additions and skip the rest: Each release will always include previous releases and make sure they are seamlessly installed.
Four feature releases are made available per year, each including improved functionality and all-new functionality. A number of bug-fix releases are made available between the feature releases.
Pure's distribution environment automatically installs new releases by the execution of a simple command. Roll-back is supported. Also, the distribution environment automatically maintains the database schema whenever new releases are installed.
Obviously, all customisations and configurations are retained when installing new releases - e.g., datamodel customisations, custom functionality, import settings, own classifications, own reports, and so on.
As described under Collaboration and cost-sharing, communities can request custom functionality and share the costs. In addition, Atira often makes standard functionality available, which was originally requested by specific organisations as custom functionality. We have defined two different policies for that purpose:
POLICY | DESCRIPTION |
Co-financing extension of modules | We have sometimes offered to delivery custom functionality at a reduced price in order to release the functionality in question as standard functionality in Pure rather than as custom functionality. That means, that it has been released to all institutions using Pure and not just to the requiring institution. |
Creating a new module | In addition, we have sometimes offered to develop and release a new module containing the desired functionality. In those cases, the requiring institution has been able to just buy the module once released, which is significantly cheaper than financing the entire development. |
When custom functionality is delivered as standard functionality instead, one benefit for the requiring institution is that it will be broader than the original requirement - it will cover more usage areas. This is because of our effort to make it usable by all owners of Pure instead of just the one making the original requirement. Another benefit is, that the same (or better) functionality is delivered at a much lower cost to the requiring institution.
The benefit for Atira and the other Pure-owners is, that Pure sees faster growth in relevant standard functionality compared to a traditional, commercial business model.
An important architectural field is the ability to delegate access to content depending on multiple factors. An underlying access control mechanism make sure that users only can access the content they are entitled to. Confidential REF deliberations, for example, are only visible to specified users with special REF-related privileges, and grant applications are only accessible to their original applicants and relevant administrators or editors. Delegating access is a complex exercise because of the many different factors in play: Users' roles and rights, organisational belonging, subject areas, or relations to content. The complexity is increased further by the temporal dimension on access control: Certain content must be accessible by certain users in certain stages, for example, while not in other stages - a grant application may be disclosed to wider circles after award, for example, but not while it is still pending. To meet these and other requirements, Pure's access control mechanism is a fully integrated architectural component - it will for example delegate access to content when users search, but also when they run or create reports.
A primary part of data security is access right delegation, which in Pure is achieved by its Roles/Rights model and the underlying access strategies. Please see Rights management and access delegation under Tech. Data can be secured ad hoc by the option to mark content as confidential, please see Confidential content under Researcher functionality and again under Rights management and access delegation under Tech.
Data security is also handled when content in Pure is exhibited through Pure's Web Service API, OAI interfaces, and reporting and dashboard functionalities.
A primary part of data security is access right delegation, which in Pure is achieved by its Roles/Rights model and the underlying access strategies. Please see Rights management and access delegation under Tech. Data can be secured ad hoc by the option to mark content as confidential; please see Confidential content under Researcher functionality and again under Rights management and access delegation under Tech.
Data security is also handled when content in Pure is exhibited through Pure's Web-Service API, OAI interfaces, and reporting and dashboard functionalities.
One specific purpose of the architectural upgrade from Pure3 to Pure4 was to facilitate the introduction of a Software Development Kit for 3rd party developers.
A Software Development Kit for 3rd party developers, a so-called SDK , will be released in 2012. It will allow 3rd party developers to programmatically customise Pure in certain areas without assistance from Atira. It is not yet determined which areas of Pure will be customisable using the SDK. Also, the business model is not yet determined.
The SDK is aimed at independent partners and not at individual institutions. It will be available for institutions, of course, but most likely it will be overkill for a single institution to invest in developers and in establishing and maintaining Pure-specific programming knowledge.
Together with Pure's Web-Service API, which already allows 3rd party programmers to build their own web applications on top of Pure, the SDK will extend 3rd party programmers' potential to the farthest extent yet in the product's history.
Atira A/S
Niels Jernes Vej 10
9220 Aalborg Oest
Denmark
Phone: (+45) 96 35 61 00
VAT no. 26835526
General info: info@atira.dk
PURE support: pure-support@atira.dk
Our technical area is server-side application architecture, development, and implementation. Our business domain is Research Information Management. We supply our product Pure, an enterprise-class CERIF-based CRIS system.
Pure, released in 2003, is licensed for 47,900 research staff at our 75 references in 8 countries.
Copyright © 2012 Atira A/S, a Reed Elsevier Company. All rights reserved.
Privacy Policy | Terms and Conditions Cookies are set by this site. To decline them or learn more, visit our Cookies page.
