All posts by Oasis

Introducing the OASIS API

Model of a Connecting Rod – Rijksmuseum, Netherlands – Public Domain.

In March 2022 we quietly launched the first version of the OASIS REST API, which provides access to information about OASIS Projects via a RESTful API.

It is designed to provide programmatic access to OASIS Project information and its output is very similar to that of the existing “Export” function that can be found on the OASIS Projects list. Links to the API and documentation are below.

The API is available to all registered OASIS users, and gives you access to the records you can normally acccess in the system. So for example, an HER has access to all their HER records, a Unit has access to all their records and so on.

This is new territory for OASIS, but something that was specified as essential for increasing machine interoperability of OASIS metadata. We hope to be working with some parterns to identify case studies of how and why the API has been used, and publicise these more widely. In the interim, if you are interested in using the API have a look at the documentation page linked above. Any problems or questions, then please contact the OASIS Helpdesk oasis@oasis

OASIS V: recent updates and new features

A craftsman working at his bench. Woodcut. – Wellcome Collection, United Kingdom – CC BY.

Since the launch of the new system the OASIS Helpdesk has received plenty of feedback from users. This has been a mixture of pointing out small bugs or glitches, or else requests for tweaks or additional features to help people with their workflows.

The most recent version of OASIS (deployed 16th May 2022) inlcudes a number of updates we hope that all users will find helpful. These include:

1 More features on the Search page

a)Ability to search on: Museum Accession ID, HER Event ID, HER monument number, Site code, Project Identifier.

b) Ability for HERs to search by review date, to help prioritise records that require more immediate attention.

c) Ability to filter out just records awaiting transfer to the ADS Library, or just those in the ADS Library.

d) Ability to filter on event type.

2 Archive messages bug

The link to this feature had a bug, which has now been fixed. You can now contact your local Archive or Museum whenever you want!

3 Notification email link bug

The link to the user profile section that was creating a 500 error has been fixed.

4 Cancelling on Activity page bug

A strange bug on the Activity page has been fixed. This was where where a user clicked cancel and the page either gave an error or saved the values within that session. This button should now clear any changes made in that session, return to the previous values entered, and not generate an error. This new code has been replicated on most other pages to deal with any other instances of ‘cancel’ causing issues.

5 Watched projects export with no selection causes error bug

This has been resolved, a user is now informed that they have not selected any projects to export.

6 Ability to batch unwatch

On the watched projects page, there is now a button at the bottom of the project list that allows you to batch unwatch seleccted projects.

7 Improvements to notifications + watches

Some major improvements have been made to the notifications: automatic notifications should now be sent for:

  • Reports transferred to ADS Library (with DOI link)
  • Digital Archive transferred to the ADS (with DOI link)

In addition, there has been some re-working of the “watch” function that determined who receives updates. Watches are now removed 40 days after the report has been transferred to the ADS library, or if no report exists 40 days after the review. However, the watch is re-established if additional reports are uploaded, or extra information is entered into the archives section. This is an attempt to keep people in the loop where they would need to know about important extra information, but not small things like typos.

8 Improvements to report page

Users have reported some problems with the status of the report page not reflecting a most recent action: for example the deletion of a report not resetting the core fields to incomplete. These were rare, but frustrating cases often caused by the form becoming out of sync with user actions. The code has been re-worked, and this page should be working much better!

9 File uploads (archives and reviewers page)

Users on the Archive page and the Reviewers Information page should now be able to upload a wider variuety of files: PDF, DOC, DOCX, XLS, XLSX

10 Results page

Frequent users will have already spotted that this has changed slightly over the last few months, with users asked if their project contributes to a Research Framework. Some extra work has gone into the page to better guide users on how to fill in if they answer “yes”. We’re still working with the relevant parties from the Research Frameworks to populate the questions.

11 Organisation details page

The ‘malformed XML’ alerts when users updated details has been fixed.

Say Goodbye to OASIS Images!

As many readers will be aware the a new OASIS system (OASIS V) is now in place. In preparation for this we have taken the decision to remove the OASIS Images function from the current OASIS IV system from the 1st of April 2021.

What! Will this make depositing more expensive I hear you say?

The simple answer is no! In fact we will be reducing our standard ADS-easy set up fee from £200.00 to £150.00 for all ADS-easy deposited archives so archiving will generally become cheaper.

For all archives submitted via ADS-easy from the 1st of April 2021 a set fee of £150.00 (exclusive of VAT) will apply. As as part of this set fee depositors will be able to deposit up to 150 jpg/tiff images at no extra cost. Additional files will then be charged on a per file basis according to our current per file charges.

How will I deposit my photos from 1st of April 2021?

From the 1st of April 2021 depositors just need to log into the ADS-easy system without having to follow the more complex OASIS Image login process from OASIS IV. OASIS IV will include a notification to let users know about the change.

Why now?

Continue reading Say Goodbye to OASIS Images!

OASIS V Beta and timeline for development

A reading woman tries in vain to stop Chronos as he passes by. Stipple engraving. Credit: Wellcome CollectionAttribution 4.0 International (CC BY 4.0)

Progress update

Despite the current tumutlous events, the redevelopment of the new OASIS form has continued. In March 2020, the ‘Beta’ system was demonstrated (remotely) to the OASIS Management Board for comment. Although a few areas still need finessing (as with any IT development), the core infrastructure has been completed. We are now beginning the transition from a Beta (effectively a working draft in this case) to a fully live system that replaces the current form.

In the various information you may have seen, the new version of OASIS is sometimes synonymous with HERALD (a project name). However, we have always been sticking with the name OASIS for the system itself. The current version everyone is using now (as I write in April 2020) is the fourth major iteration deployed since 2002. Internally, we often refer to it as OASIS IV. It is important to note that throughout all subsequent discussion we’re simply going to refer to the new version as OASIS V.

In many ways. moving between versions is more complex than ‘just’ code development: OASIS has over 88,000 records , and over 5000 unique users representing 1386 organisations. It’s also used intensively.

  • In 2019 there were 108,000+ requests for pages within the OASIS form. We don’t know what these are though (could be one person clicking through alot of times!).
  • In 2019 there were 19919 edits to forms that resulted in a new version

We simply can’t suddenly move everyone over in a week! We need to gauge performance, iron out some issues, and start familiarising as many people as we can with how the new system differs from the old one. Most importantly, we don’t want a user to be inputting data into two systems and duplicating effort. This is the next phase: “Rollout of OASIS V”.

Timeline for Rollout of OASIS V

The following is the planned timeline for the next phase. It is important to note, that unless directed otherwise over this period, use of OASIS IV (the current form) should continue until the Autumn of 2020.

April 2020HER familiarisation with OASIS V
Internal testing
Review of OASIS V stability under increased use
May 2020Development Sprint
Testing and Feedback with OASIS V Working Group
June 2020Silver release of OASIS V: a major redeployment
Moving a small number of early adopters over to OASIS V
July 2020Development Sprint
Testing and Feedback with OASIS Working Group
August 2020Development Sprint
Testing and Feedback with OASIS Working Group
September 2020Gold release: OASIS V becomes operational under the domain
October 2020+All existing users are moved over to OASIS V
By March 2021OASIS IV will have been decomissioned when all users migrated
OASIS IV data will have been archived as a snapshot

Working Groups

To aid this, we have set up a number of Working Groups from across all parts of the sector to help us answer any outstanding issues.

Working Group 1: Community GroupsFocus on workflows of community groups and others working outside of development control
Working Group 2: ContractorsFocus on the workflows of archaeological contracting organisations, inlcuding those working in geophysics and maritime
Working Group 3: ALGAO (HERs and Planning+Leg)Focus on HERs, and use within Local Authority work with development control
Working Group 4: Museums and ArchivesFocus on the new ‘Level 3 user’, which allows Museums and Archives (including digital) to be a major part of project workflow, and to help signpost the requirements of collecting organisations
Working Group 5: BuildingsFocus on the use of OASIS by Built Heritage professionals and researchers. In England this will be through the use of a specific OASIS Buildings ‘skin’ tailored for the community.
Working Group 6: End-to-End WorkflowsProviding an overview of how the entire OASIS system works in England and Scotland, from creation of record, re-use and engagement of stakeholders, and access to information.
Working Group 7: Historic England Internal UseProviding a focus on HE internal teams creating records, but also as the national body for England and the insight that OASIS can provide to understanding trends in fieldwork and research
Working Group 8: Discovery and Excavation ScotlandIn Scotland, OASIS feeds into the annual report of DES. This requires specific workflows and techincal requirements outside of the main form.
Working Group 9: Techincal InteroperabilityTo focus on the terminologies being used, howe they are being used, and how data stored in OASIS can be re-used.
Working Group 10: Training + PromotionTo coordinate and deliver a range of training and promotional activities in both England and Scotland, and to investigate new methods of learning in the digital age

It’s hoped that these Groups can begin to form the basis of a community to support OASIS and its users as things move forward. If you’re interested in learning more about a particualr group, and even joining, please contact the project email address at

Putting OASIS on the map

Tim Evans + Kirsty Ackland

Everyone loves a map…

A quick look at the current development version of OASIS

One of the tasks we’re currently tackling in the OASIS redevelopment is the Location module. This is probably the most important facet of new OASIS; not only is accurate recording of a place a fundamental to everyone’s work, but within workflows project locale subsequently helps generate a lot of data in other modules of the form.

Jo has been hard at work knitting together the OpenLayers (v5) interface within a Java framework, and getting it to connect with the back-end (the classic QGIS – PostGIS stack). Without wanting to jinx things, the results are looking really good. A user can record multiple ‘sites’ within a single record, and each site can be represented by points and/or polygons. A user can also upload their own boundary files straight into the map! Once saved, a spatial query is run against an array of background mapping to generate admin areas, HER areas and (currently at review) collecting areas for Museums and Archives. Basically this tells a user where they are, and who the curators are for the record. It also allows a curator to log on and see records for ‘their’ area.

A little task we’re running in the background is coming up with ways to deal with legacy data migrated from the current database. One facet of this has been Polygons. The current OASIS database (Oracle) is not a true spatial database, and thus ‘geometries’ are stored as a set of points, but not a real polygon (if that makes sense). In order to have these polygons appear in new OASIS (PostGIS) as polygons, and not just a series of points we’ve had to do a bit of cleaning post-migration. Fortunately, we’ve been luck enough to have a fantastic Masters student (Kirsty Ackland) with us over the last few weeks. Kirsty has put my rather rusty GIS skills to shame…. In her own words:

“As part of setting up the map interface for the OASIS system an existing dataset was used to test the visualisation process. The original dataset (Oracle) is now held in a PostGreSQL/PostGIS database which was imported into QGIS. However the structure of the original data from Oracle meant the data could not be visualised as a geometry. To fix this, the dataset was run through QGIS’ database manager with a simple SQL query to retrieve only the data which was stored as polygons and output it in tabulated form to remove the geometry links. This was exported into Microsoft Excel to clean the data and remove unnecessary fields. This was then imported back into QGIS as a .csv file.

Because the geometry had been removed the records no longer had spatial references associated with them, so the next step was to find the original input co-ordinates for each record in the OASIS database. This was done using an SQL query to join of several tables within the OASIS database using the OASIS_ID, SITE_ID and GRIDREF_ID assigned to each project during data entry. This produced a table holding all of the IDs necessary to re-associate the co-ordinates (also held within this table) for each site with their assigned OASIS ID using a one-many relational join (one oasis/project ID to many gridref/co-ordinate IDs). The first dataset was then joined with the ID table using the OASIS_ID to add in the easting and northing points to their relevant project information. This was then quickly queried to remove any duplicate fields created by the process and was output into QGIS with its corrected geometry (fig 1).

Figure 1 (just the points)

To create bounding boxes for the sites held within OASIS for visualisation on the map, the convex hull tool within QGIS was used to join the co-ordinate points together a create separate polygons based on their siteID (fig 2). However, when this was complete it soon became apparent that some of the co-ordinate points were entered incorrectly resulting in the weird output seen in the screenshot where there are sharp lines running north-south. The screenshot also shows that some are in the correct place though, which suggests that this workflow works well as long as the data is correct. A secondary point to note is that some of the sites only relate to one co-ordinate point, but have been stored as “polygons” during data entry. This means although they exist within the dataset as point data, when converted to polygon to show their extent they get removed because shapefiles
can only store one datatype at a time i.e. point or polygon. The effects of this can be seen in fig 3.

Figure 2: rebuilding the polygons
Figure 3: Points + polygons

This is also an issue to bear in mind when considering the point data removed from the dataset right at the start of the process, as it is very likely some of the sites should be stored as polygons rather than points, leaving the visualised data output here incomplete.”

It’s at that point that I think we’re going to stop. We now have real functioning polygons in our new database. Some of them may be incorrect, but this is just the legacy of manual data entry (with no immediate visual control) in the current OASIS form, and which does date back to 2004. Hopefully the new system will deal with this alot more efficiently! Thanks to Kirsty for her quick and efficient help on this.


Just a quick blog to let everyone know that Tim and colleagues from the ADS will be at the CIfA conference in Leeds later this month.

There will be new information on the OASIS redevelopment project available from the ADS/Internet Archaeology stall, including some new promotional material .

Please come and say hello, we’re more than happy to answer any questions about what’s going on with the project. Tim will have a laptop, so (wifi permitting) he’ll be able to show you the current form as it stands!

OASIS open for testing

March saw the completion of the first major phase of the redevelopment of OASIS. After alot of hard-work by the team, we have finished the following major tasks:

  • A new database is in place (PostGreSQL + PostGIS)
  • A Java application is in place (the basis of the form) that can ‘talk’ to the database
  • Workflows mapped (what happens when(
  • Mapping old OASIS terms to existing heritage thesauri
  • Full-scale test migration of data completed
  • Testing and feedback on migration/mapping
  • The basic form is in place (at last!)

The local version has been deployed to a ‘live’ server, and a group of users who have signed up are now being notified that they can log on and have a look/test what is there.

The testing phase is now running until the end of May, during which time we will be collecting and compiling comments/bugs, as well as moving on with the rest of the build.

The slides below give a very basic example of how the new form is shaping up and the sort of information recorded within.

In a nutshell, what we have completed is…

  • A user can log on (change password etc)
  • Do all the admin type tasks detailed in this post of October 2018
  • Look at a list of their records – filter by various fields
  • View/edit/create a new record
  • Fill in details about the project (using FISH event thesaurus) and the new wordlists now hosted as LOD at heritage data, for example “development type
  • Record the location, and have this generate the geographic administrative areas (county/council, district, parish etc) and then generate the list of reviewers for that record (e.g. HER)
  • Record monument and object (and period), again using relevant FISH thesauri

What we’ll be working on next is:

  • The report / other publication section (with ability to upload a file)
  • The archives section
  • Moving forward with the map (currently only in a local version)
  • Set up the triggers that give the user an option to fill in a specialist module (currently Buildings, Geophysics and Burial Spaces Survey)

If anyone is interested in testing over the Summer, particularly for Archives and Buildings, then please get in touch with

Review periods in OASIS

Stained glass windows in Art and Crafts style, c1874-1910, at ‘Haunted’, Stonegate, York. Culture Grid. CC BY

Before I start a quick note: this is a very long blog that tries to condense about 18 months of discussion and internal reporting into an overview of a key workflow in OASIS. I’ve tried to keep it short, but for clarity i have to explain some background…

The Background

Although we all love OASIS (!), one of the key problems that has consistently been raised has been the delay in reports being transferred into the ADS Library. A Level 1 user (unit, community group, buildings archaeologist, academic) uploads a report, completes the form and then there’s either a delay or in the worst case the report never gets copied over at all.

This is normally caused by a backlog at what has traditionally been called the validating organisation: the HER/SMR. In our review of workflows in HERALD Phase 1 it became apparent that the problems at the validation level were caused by:

  • No HER provision
  • An HER was not actively validating OASIS records, and did not want to!
  • Lack of resources for an HER to validate as quickly as they’d like
  • Validating an OASIS record was taking a long time

In the current system – and where there is agreement with the HER provider – in some areas of England so-called proxy validation is being undertaken by Historic England.

After a review and comment from project funders (HE and HES) and representatives from ALGAO (HER), the new OASIS is taking significant steps to overcome this backlog while also doing as much as possible to ensure the accuracy of information and ensuring that HERs are able to delay transfer of reports where there is a critical need.

The first thing we’re doing is changing the terminology! Validation is now being replaced by ‘Review’. This more accurately represents the role most HERs perform, and separates it out from any formal sign-off related to the planning process.

In England, one of the features being implemented is the HER being able to select its level of engagement. A previous blog explains the differences, but basically an HER that is Lite can access, and edit their records but are formally ‘Not Reviewing‘. An OASIS that is Standard is ‘Reviewing‘. By default all Scottish HERs will be Standard users, and we’re currently surveying English HERs (via the HER annual survey) to establish their level of use. It should be noted that an English HER can change their Reviewing status at any time.

What does all that mean? Here’s a simplified overview of the workflow:

1) A Level 1 user uploads a report. The user is also presented with a preview of the metadata record to accompany the report in the ADS Library. In Scotland, users will see the DES preview. Level 1 users will be able to correct any errors they see in this preview record.

2) A Level 1 user will also be able to set an embargo period for the report (in months), which includes the capacity to set a “no release” value.

3) The Level 1 user will be presented with a series of alerts and challenges reminding them of the obligations of depositing uploading a report to OASIS under the (pre-agreed) terms and conditions of the OASIS Licence Agreement. These Terms include:

  • That the Depositor (i.e. the Level 1 user) us responsible for ensuring that the report does not include any personal details (in accordance with current GDPR legislation)
  • That any third party material is covered by a licence or agreement which permits its distribution within the final report.
  • That the Depositor is responsible for ensuring that the correct version of the report has been uploaded (with primary reference to reports forming part of a planning condition).

4) If enough of the OASIS form has been completed, the form then establishes the stages of Level 2 (HER/SMR) and Level 4 (national body) review appropriate to the record:

  • In England Level 2 Review status
  • In Scotland Level 2 Review status is defaulting to OASIS Standard.
  • In England there is no formal Level 4 Review.
  • In Scotland, Level 4 Review of the DES record will be undertaken by Archaeology Scotland (Level 4). In addition HES (Level 4) will subsequently review the record and add in relevant Canmore information.
  • In Scotland, transfer of the report into the ADS Library would only occur after all parts of Level 4 review were completed.

5) In the case of areas where HERs are not reviewing records and reports (OASIS Lite), transfer of metadata and report to the ADS Library is allowed to happen (i.e. as soon as the minimum level of information has been recorded and report uploaded), unless an embargo period has been set by the Level 1 user. The resulting report in the Library will have a very clear disclaimer as to its origins and the lack of Review at Level 2.

6) Where an HER is reviewing, it was deemed necessary to have some sort of mechanism to stop records forming large indefinite backlogs at HERs. This is being called the Review Period. If no action is undertaken in this period the metadata and report are automatically transferred into the ADS Library, again subject to any Level 1 embargo period, and with a very clear disclaimer as to its origins.

7)I n the case of the report being rejected, the Review Period would be reset upon the next upload by the Level 1 user.

8) Additional reports can be added to an existing OASIS record (an OASIS record never closes). Each report would have their own Review Period.

9)T here will always be the capacity for a report to be removed from the ADS Library.

The question we were asked to solve was, how long should this Review period be?

The Review Period

To this end, the question over the desired length of the period was put to ALGAO (HER) members in England and Scotland, courtesy of the relevant ALGAO representatives on the OASIS Management Board. The recommendation from Scottish members was for an initial review period of at least 12 months, with the capacity for Level 2 users to place their own embargo period (including “no release”) on any report within their mandate. The feedback from England was mixed, with a range of review periods from 3 months to a year mooted, and again with some form of ability to stop or delay a report from being released.

The need to reconcile the differing requirements for a Review Period across HERS and countries has been discussed at great length. The primary concern of HER users is the possibility that a shorter review period would result in the release of reports into the ADS Library that were not formally approved by the relevant Local Authority archaeologist/Planning Adviser, and thus potentially clash with the signing off of work/developer requirements within the planning framework. Another concern is that HERs with less resources/staff capacity would not be able to review all the uploaded reports for their administrative areas within a short period of time.

In short, everyone wants reports to be made available as quickly as possible, but we do need to have a sensible Review Period and the means for an HER to extend this where there is justified need. This has been labelled as “the capacity for Level 2 users to set an Extended Review”, with the following limitations:

  • The Extended Review period would not be infinite.
  • There would be no ability to set separate periods.
  • HERs that are not reviewing (England) will not have access to this function.
  • Level 1 users will still have the option to set their own embargo period, including ‘never release’.

However, we still need to decide how long these periods should be!

Analysis of OASIS workflows

To augment the anecdotal feedback from HERs, it was thought beneficial to look at the actual data stored in OASIS to look at how long records stayed in the system. The following analysis is based on exports of data from an 18 month period over 2017/18, and are deliberately brief to aid clarity. It is acknowledged that within them are a myriad of factors (organisational, financial, and personal) which influence the timings identified which are not considered here. However at the time of writing they are at least a neutral and statistical source on how OASIS is currently used.

OASIS workflows: Scotland

The following data was exported from the current OASIS database on 1st June 2018:

  • Identified 490 records completed by Level 1 user in 2017
  • 315 of which have since been validated by the HER (64% over a period of c.18 months)
  • The average time from one of these records being completed by Level 1, and then validated by the HER was:
    • 52 days (mean average)
    • 33 days (median average)
  • The average time for all records (validated and awaiting validation) was:
    • 167 days (mean average)
    • 66 days (median average)
  • Nationally:
    • 54% of records were processed in under 3 months
    • 9% of records were processed in 3-6 months
    • 13% of records were processed in 6-12 months
    • 24% of records were processed in 12 months+

A breakdown of times by anonymised Scottish HER shows a deeply polarised picture: with most HERs (and those with least records) taking over a year to process a record; conversely, areas where OASIS is used frequently process records in a relatively short period of time.

Time that a completed OASIS record then spends with (anonymous) HER in Scotland (for all records completed by level 1 user after 1st January 2017).  Each HER area is split into a bar showing the percentage of records that fall within the time periods. Dotted line shows number of records for that area

OASIS workflows: England

The following data was exported from the current OASIS database on 1st June 2018:

  • Identified 3376 records completed by Level 1 user in 2017
  • 2250 of which have since been signed off by the HER (66% over a period of c.18 months)
  • The average time from one of these records being completed by Level 1 and signed off by the HER was:
    • 76 days (mean average)
    • 31 days (median average)
  • The average time for all records (validated and awaiting validation) was:
    • 173 days (mean average)
    • 115 days (median average)
  • Nationally:
    • 47% of records were processed in under 3 months
    • 10% of records were processed in 3-6 months
    • 25% of records were processed in 6-12 months
    • 18% of records were processed in 12 months+

These broad figures only aggregate out a great deal of nuance as it is well known that validation workflows within the current OASIS system vary across the country, as demonstrated by a breakdown of the 2017 data by HER (see below). A brief overview of these figures shows some clear trends:

  • HER working patterns currently vary significantly
  • The majority of areas process the majority (57%) of their records in 6 months or less.
  • 82 % of records are processed in under 12 months.
  • There are some areas where validation is significantly slower.
  • Even areas with high numbers of records and throughput (what we may tentatively call typical users) still have a minority of records which take over 6 months to process, and in certain cases over 12 months.

Time that a completed OASIS record then spends with (anonymous) HER in England(for all records completed by level 1 user after 1st January 2017).  Each HER area is split into a bar showing the percentage of records that fall within the time periods. Dotted line shows number of records for that area. Areas validating via proxy and non-validators filtered out

Reaching a decision

The brief overview of current statistics indicates that:

  • Where OASIS is embedded within an HER’s workflow – and where resources permit – the time to successfully validate/review a record is below 3 months for over half of records.
  • In each country, the majority of records are validated in under 6 months (57% in England, 63% in Scotland)
  • In each country, over three quarters of records are processed in under 12 months (82% in England, 76% for Scotland)
  • Some records, even in areas with very efficient reviewing times, will take over 12 months to process

In trying to pick out the most suitable periods, it is worth highlighting that:

  • There is a need to establish a balance between being aspirational and being realistic.
  • The new system will improve the quality of recording by level 1 user.
  • Alerts will be in place to aim to prevent uploading of unsuitable reports. This can include guidance from each HER on how to use the form in their area/expectations etc.
  • The use of the embargo period seems to be well established in many areas, which could be taken to indicate that dialogues between Level 1 users and Development Control/Archaeological Advisers on what should be uploaded to OASIS – and limits to accessibility – are already in place. However it is also clear that a form of Level 2 override is still needed.
  • Although safety nets are planned, there are obviously still cases where a Level 2 ‘override’ is needed.
  • In Scotland the workflow through DES-HES will still be in place.
  • Both the initial Review and Extended Review period could be changed at any point.

At this stage, it is suggested that as the majority of records from each country are successfully reviewed/validated in under 6 months that an initial Review period of 6 months is set as the starting value in the new OASIS system. As there seems to be a significant number of records which do take up to a year to process, it is suggested that there is a strong need for an Extended Review button/option being able to add on an additional 6 months when triggered, meaning a record would have a cumulative total of 12 months under review in the first instance. If rejected by the Level 2 user, the initial Review period will still be in place upon upload of a new report, giving the Level 2 user a further 6 months to act.

Overview of the Review / Extended Review workflow

The option for Extended Review will appear in the Report section of the form, and will also include an additional field for the Level 2 user to record a description of why the report is being withheld if they wish. This will be available to anyone with access to that record. To allow the Level 2 user to have as clear a picture as possible, the following alerts and information displays are being built into the new OASIS form.

  • Current release date of report will appear on overview e.g. “Report will automatically be released into ADS Library on 01/04/2030 if no action taken”
  • Level 2 user will be able to filter records on Release date to see imminent releases
  • Level 2 user can set their email preferences to send a digest of reports nearing end of their Review period, e.g. “The following reports will be released into ADS Library next month:
    • jensdigg1-12345
    • jensdigg1-12346
    • etc.

The Extended Review period will automatically add 6 months onto the existing Review period, this is best demonstrated with some hypothetical examples:

  1. Level 1 user uploads report a report to OASIS on 1st January 2030. All relevant sections of the form are complete, and record can pass to Level 2 review (OASIS Standard). No action is taken by Level 2. The report is released into the ADS Library on 1st July 2030 by default (with disclaimer)
  2. Level 1 user uploads report to OASIS on 1st January 2030. All relevant sections of the form are complete, and record can pass to Level 2 review (OASIS Standard). Level 2 user reviews record in 1st April 2030, no problems and report goes into the ADS Library.
  3. Level 1 user uploads report a report to OASIS on 1st January 2030. All relevant sections of the form are complete, and record can pass to Level 2 review (OASIS Standard). Level 2 user reviews record in 1st April 2030, has a query over the version/contents of the report, clicks “Query/refuse report” and communicates this back to Level 1 user with a request that report is re-submitted. The record is marked as ‘awaiting upload of report’. On 1st June 2030 the Level 1 user uploads a new version of the report. The Review Period is re-set to 6 months from this point, meaning that if the HER does not perform any action the report automatically goes into the Library on the 1st December 2030.
  4. Level 1 user uploads report a report to OASIS on 1st January 2030. All relevant sections of the form are complete, and record can pass to Level 2 review (OASIS Standard). On the 1st June 2030 the Level 2 user is alerted to the fact that report will be released next month until action is taken, Level 2 user is busy and wishes to give themselves more time to check contents and status with DC, and clicks ‘Extend Review’. The report is now due to be released on 1st January 2031 (i.e. 12 months after report was initially uploaded).
  5. As above, on 1st November Level 2 user reviews record and identifies problem with the report, clicks “Query/refuse report” and communicates this back to Level 1 user with a request that report is re-submitted. The record is marked as ‘awaiting upload of report’. On 1st January 2031 Level 1 user uploads a new copy of the report with another 6 month review period if no action is taken by Level 2. The report is released into the ADS Library on 1st July 2031 by default (with disclaimer). The option to click another Extended Review is now not available. If the Level 2 user is still not happy with the contents of the report they have this additional 6 months to refuse it, effectively resetting the Review Period each time.

That’s the plan! This has been presented to English and Scottish HERs and there is agreement that this is a sensible way to proceed. This will be reviewed, tro see if the windows are working as intended, and guidance/training on this workflow for all users will be a key feature of the public rollout of the system. However, time to stop writing!

OASIS for English HERs: Standard or Lite?

Justice from BL Royal 19 C II, f. 49v – Laurent d’Orleans. The British Library – Public Domain

In England the ADS (via the Historic England HIPs team) are currently asking HERs about their preferred level of engagement with OASIS. This is because in the new OASIS system we now have three tiers of recording instead of just one: OASIS Lite, OASIS Standard and OASIS Plus.

[Note: that in Scotland, because of the the workflow designed to communicate results to HERs, HES and DES, OASIS Lite will not be an option.

Another note: OASIS Plus are specialist modules designed to record fine detail about very specific types of events such as geophysical survey, that fall outside of the main Level 1 (data in-putter) to Level 2 (HER) workflows and thus can be put to one side for the purposes of a concise blog.]

The two main workflows – OASIS Standard and Lite – have been created to reflect the realities of the levels of HER engagement we see in the current system, and reinforced by feedback to the original HERALD phase 1 survey on what people wanted in the redesign. The fine details of these workflows, and the list of mandatory fields are best viewed in the online version of the Functional Specification

However, I thought it best to provide an ‘at a glance’ overview of the differences between the two systems, so without further ado…

OASIS Standard

  • The HER (Level 2) is actively participating in OASIS and wants to hold reports and metadata for review before they are available to the public.
  • So, the Level 1 user fills in the mandatory fields for OASIS standard and uploads a report. Once everything is completed the HER has a window to review, or highlight records are held for extended review.
  • When review is completed the report and metadata go into the ADS Library.


  • OASIS LITE is a mechanism for uploading project reports to the ADS Library.
  • OASIS LITE will collect an enhanced bibliographic record which is used as discovery metadata for locating the report (so less than OASIS Standard)
  • OASIS LITE only applies to the areas of the form which are relevant to transfer to the HER (i.e. not the archive section which will be dependent on participation by the museum/archive rather than the HER).
  • OASIS LITE will only be available when there is an HER for the area and that HER is collecting the full event record by other means (i.e. not via OASIS). All other OASIS modules which are relevant to that event/project will be collected even if the HER is not using OASIS i.e. Archive and Geophysics.
  • Any reports that are released into the ADS Library through this mechanism will have a very clear disclaimer explaining that they have not been reviewed by an HER. The text of this disclaimer is being written by ALGAO executive with input from HE/HES.

There’s doubtless a few questions, I’ve tried to preempt them below:

What are the mandatory fields for OASIS Lite and Standard?

Please refer to Page 81 onward of the  Functional Specification

Can an OASIS Lite have more than the mandatory fields recorded?

Yes, if the Level 1 user wants to, they can fill out as much as they want.

Why are you asking now?

As part of the package of work establishing the review and extended review (i.e. how long an HER using OASIS Standard has to review a completed record), we need to get an idea of the split between Lite and Standard users. We also need to have the participation level set for when we start testing workflows for Standard and Lite.

Can an OASIS Lite HER still log in and see records/export data etc?

Yes. They still have access to all the data for records in their area, with access to any exports and API functionality.

Can the level of participation be changed? 

In short: Yes. The HER user simply clicks a button in their admin panel.

In more detail: when the record is started it is defined as Lite or Standard in the database, a separate audit table also records when a record is saved, mandatory fields present depending on level  (i.e. “complete”), report transferred to Library and so on. This will be reflected in what the user sees in their list of records.

If an HER swaps from Lite to Standard there is a good chance the HER could suddenly get records to review, but only ones which hadn’t been defined as completed already and transferred to the library. This will mean however that a Level 1 user will be presented with increased requirements for any records that have been left open. However the differences in mandatory metadata requirements are not onerous, the main impact will be on the timing of transfer of reports into the ADS Library (i.e. any live or new records will be subject to HER review).

If an HER swaps from Standard to Lite then completed records will be unaffected, incomplete records will simply have less for the Level 1 to complete as mandatory and report transfer will default to no review.

That’s the plan, however we will be reviewing how this works in practice!

If I change from Lite to Standard, can I edit completed Lite records?

Yes. However you can’t request that a Level 1 user goes back and edits as they have completed what was required of them at the time. The record will still be marked as a Lite record, reflecting its original status.

We have identified a potential issue where a Level 2 user switches to Standard, and then may want to start correcting or amending completed Lite records for their area.

If an HER wants to go and add or edit that’s fine. Any OASIS record is always open, so additions or corrections are fine. The only sticking point is the report…. When a report and its metadata are transferred into the ADS Library that version is what’s archived as a point-in-time exercise. If an edit to report metadata is required it can be made by either the Level 1 user or HER responsible for that record directly in the ADS Library (we have created a module to do this!). This will need care, but basically there will be a system where accredited users can update Library records themselves without making a request to the ADS.

Hopefully because of the new functionalities in the data entry form there should be many fewer errors in the basic bibliographic record, but we have to be prepared!

Things get trickier if the HER, once switched to Standard, notices problems with the completed Lite reports uploaded for their record. We have to try and balance the integrity of what was originally recorded (according to what was required, and the disclaimer) with the need to add or remove new reports where urgently needed. In this case there are options:

  • The HER simply uploads the correct version of the report, both versions of the report are online (the first with a disclaimer). Potential to have links between the two records so that a user finding the first, is aware of the second.
  • The HER finds the report they want to remove in the ADS Library, and flags it for removal/hiding. The ADS are then notified and the report is removed. Level 1 users will also have the ability to flag reports for removal (please note that if a report is deleted, the DOI remains, but just points to a landing page notifying the user that it has been removed).

It should be noted that the above are options, and nothing is completely set in stone. There’s a a balance between creating a system that allows the upload of reports in a timely manner and the ability to fix genuine mistakes or remove sensitive information, with the risk of having a system that becomes a mechanism for a constant cycle of upload-removal-upload-removal of different versions of the same report by different people.

We will be exploring this further with all relevant parties during the ongoing development, but as always I’m happy for thoughts/ideas/concerns to be raised, so feel free to email