Data Catalogue

Previous Natural Hazards Research Australia (the Centre) work developed a research data framework to help scope and guide the development of a national data catalogue.

This project seeks to develop a data catalogue that aligns with the Centre's commitment to FAIR and CARE principles through access to research data. The data catalogue will use research data assets of projects funded through the Centre and the previous Bushfire and Natural Hazards CRC, which will support all future research and be available to the community. 

Frequently asked questions

Q) What are the key features you’re looking for in the Data Catalogue web application?

A) The features are defined in the functional requirements of the RFP.

Q) Are there any specific integrations or platforms that you'd prefer?

A) We are currently using Microsoft-based PaaS and integration within our platform is highly regarded.

Q) Could you clarify which specific elements or sections of the Statement of Requirements are expected to be addressed under the “Approach” criterion in our proposal.

A) The "Approach" criterion considers all sections of the Statement of Requirements and can be considered the 'how' aspects of your response. Particular focal areas of the Statement of Requirements could be considered as:

•   Background
•   Data Catalogue requirements

Within your response, the following mandatory sections will be considered as part of your "Approach":

• "Project Team",
•  "Work Plan", and
• "Statement of Acceptance".

You may add additional sections to those outlined in the RFP as you see fit - in this way the response format is flexible. Any additions which could be considered part of ‘how’ you will do the project will be within scope of your “Approach”.

Q) Do you expect the “Approach” to include a detailed software architecture, integration plan with the Centre’s cloud environment, and methodology for collaboration with the IT Service Management Provider?

Detailed software architecture and integration plans are not explicitly required but may assist in communicating your "Approach". Similarly, outlining a strategy for collaboration with the IT Service Management Provider may also clarify those aspects of your "Approach".

Q) How should we present our understanding of the Centre’s data architecture and the ReDCAT-AU metadata profile—within the “Approach” section or as separate supporting documentation?

A) Your understanding of our Statement of Requirements should be evident in your response - that is part of our “Approach” assessment. The response should contain no more than 10 pages (including appendices or other attachments). Excluding the mandatory sections - the format has been left intentionally flexible. This is opportunity to demonstrate your understanding and communication skills with us.

Q) Is there a preferred format or structure for presenting the “Approach” (e.g. problem definition, solution design, integration, collaboration, risk mitigation)?

A) The format has been left intentionally flexible. This is opportunity to demonstrate your understanding and communication skills with us.

Q) Are you expecting a narrative description, diagrams, or both for the proposed implementation approach, particularly regarding the Data Catalogue API, databases, and user workflows?

A) Within the 10-page limit, submissions can include any combination of text, diagrams, and other forms of communication. The level of detail expected is that of an RFP response.

Q) Would this project be built on the initial pilot project solution and Research Data Management Project back in 2022?

A) No, this work is informed by, but ultimately independent to, the Research Data Management Project of 2022.

Q) Are there any preferred industry platform to work with such as traditional catalog vendors like Informatica, Atlation, Collibra, Purview?

A) Integration with our existing Microsoft cloud environment is highly regarded.

Q) Is there any existing EKG platform you have in place, which will be used to develop or integrate the solution (Knowledge Graph's are already AI/ML ready and optimised for research data)?

A) No, the Centre does not have any EKG based platform beyond what is offered via our Microsoft cloud environment.

Q) Would there be a public information session prior to submissions for asking questions and get more clarity for the RFP submission?

A) No, unfortunately due to time constraints and the anticipated number of respondents, there will be no public information session. Questions may be directed to: research@naturalhazards.com.au. Please ensure you have read the FAQs before submitting questions.

Q) Are there any IP rights we must be aware of related to co-developed code?

A) The proposed contract is available on the Data Catalogue webpage for review under the “Download the Services Agreement” button. Please review the ‘Intellectual Property Rights’ section for more information.

Q) What insurance documentation must be supplied during the tender stage?

A) Insurers name, policy number, type of insurance, coverage amount, coverage period, policy expiration date, notable exclusions

Q) What is the data exit strategy or handover process at the end of the SLA?

A) The SLA is an optional extension proposed for after the development of the Data Catalogue. The optional extension is at the sole discretion of the Centre. Details regarding the SLA will be handled once the Centre decides to follow through with the extension.

Q) Can you provide more details on the intended audience for the Metadata Profile documentation?

A) The Metadata Profile documentation is intended for a technical audience of metadata custodian and stewards.
The Centre wishes to promote semantic interoperability within Australia Research sector (more specifically Natural Hazards and Disaster Resilience), referencing similar pursuits such as the Semantic Interoperability Centre Europe (SEMIC.EU).

Q) Are there any mandatory datasets or metadata that must be included at go-live?

A) Yes, there will be Research Data Asset metadata required for the go-live. The aggregation of this data is not expected as an output of this work; however, the automated ingestion of this data is an expected outcome.

Q) What constitutes success for the alpha release in June 2026?

A) The successful demonstration of the minimum functional requirements (features) as described in the RFP in requirement 41.

A) The alpha is intended to be used for demonstration purposes to a limited set of stakeholders.

Q) Will the system include any publishing or syndication functionality?

A) Publication is required in the sense of visibility of metadata to intended users via the Data Catalogue.
However, sale or transfer of ownership is not an anticipated feature - the system is expected to be managed by the Centre for the respective owners of the IP (typically the Centre).

Q) Should the system support integration with Microsoft Power BI or just Power Platform (e.g. Power Apps)?

A) Yes, Microsoft Power BI is considered a part of the Power Platform.

Q) Are there any legacy systems or databases that must integrate with the new system?

A) There are existing databases – however, integration is not considered a requirement for this work.

Q) Are you planning to support external contributors with APIs for metadata upload?

A) No, the Centre does not anticipate any external contributor data ingestion via API for this stage of development.

Q) Will we have access to a technical representative?

A) You will have access to the Digital and Data Manager and to a limited degree the IT Service Management Provider.

Q) Are there any legacy metadata sets that need to be migrated or transformed to ReDCAT-AU?

A) There is legacy research metadata, however, the aggregation is not a part of the work scoped in this project.
The ingestion of data is expected to be extracted, transformed and loaded via the ‘ingestion of bulk catalogue records via an xlsx template’ feature.

Q) Should the system support external data harvesting or only internal data provisioning?

A) The system should support only internal data provisioning but be itself easily ingested by other data harvesting systems.

Q) How will metadata quality be governed over time – automated validation or manual review?

A) Metadata at time of entry should be subject to automated validation processes (e.g. type / format checking).
Already existing metadata will be governed by manual review.

Q) Are you expecting multilingual metadata support?

A) No, the Centre does not anticipate multilingual support at this stage of development.

Q) What cyber security standards, beyond ISO/IEC 27017/27018, should be adhered to?

A) Additional recommendations of standards are encouraged by respondents.

Q) Are synthetic or anonymised datasets required for system testing?

A) System testing is a requirement, the answer to this question should be provided in your proposal.

Q) Should test environment mimic the data residency and security controls of production?

A) System testing is a requirement, the answer to this question should be provided in your proposal.

Q) Should test data be encrypted at rest and in transit, even in dev/staging environments?

A) Encryption at rest and in transit is not required in the dev environment. The staging environment should resemble production as much as feasibly possible.

Q) How important is mobile responsiveness versus desktop usability?

A) Desktop is anticipated as the preferred UX, however, mobile should feature demonstration level capabilities.

Q) Should the GYI include accessibility tools (e.g., contract switch, screen reader hints)?

A) The Centre’s Data Catalogue aims to be as accessible as possible for a wide range of users.

Q) Is there a preference for using the Australian Government Design System (AGDS)?

A) No, there is currently no preference; however, the Centre is open to suggestions.

Q) Will NHRA conduct UAT internally, or is vendor-led facilitation expected?

A) Vendor-led facilitation is expected.

Q) Can we create and propose a Solution Architecture Design to the Centre?

A) Yes, the Centre is open to proposals for solution architecture.

Q) Should the system be design to scale globally in the future (e.g., Asia-Pacific research hub)?

A) No, it is not anticipated that the Data Catalogue will reach a global scale at this stage of development.

Q) Should staging environments mirror production, including SSO and access control?

A) Yes, the Centre hopes that testing stages capture all bugs, including authentication and access control.

Q) Is multi-region failover required, or single-region high availability sufficient?

A) Single-region high availability is sufficient.

Q) Should documentation be authored using NHRA’s preferred templates, or can we suggest a format?

A) The documentation should follow the Centre’s style guide; however, structure is flexible.

Q) Are training sessions expected to be delivered live, pre-recorded, or both?

A) Training sessions are expected to be delivered live. Pre-recorded material would be considered training materials – not training sessions.

Q) What level of technical documentation is expected – developer, admin, user?

A) As the documentation is technical in nature, the anticipated audience is future developers. Training materials are required for admin and users – this is not considered technical documentation.

Q) Are Knowledge Base articles expected for the wider research community?

A) No, this is not part of the requirements.

Q) Are quarterly or annual refreshes of training materials expected during support?

A) Training materials should cover most workflow related questions which are discovered during testing.
Further refreshes are not expected past the timeframe allocated for training.

Q) Should we include printable reference guides or quick start sheets?

A) The Centre expects the training material to be easily accessible, covering both commonly asked questions as well as more detailed workflow guides.

Q) Is onboarding support needed for future hires after go-live?

A) No, past the timeframe allocated for training, onboarding support is not required for this work.

Q) What hours of operation are expected for technical support (AEST or 24/7)?

A) Technical support during business hours AEST is expected during the warranty period. 24/7 support offering capabilities will be favourably regarded for the optional SLA.

Q) Will NHRA require proactive system monitoring with alerting?

A) Proactive system monitoring with alerting is not currently expected within the warranty.

Q) Can you share historical usage data from the MVP for more accurate cost projections?

A) No, unfortunately we cannot share usage data from the MVP.

Q) Should we include a roadmap for phased improvement post-launch?

A) The Centre has left the format of response intentionally flexible. This is your chance to demonstrate your communication skills and understanding.
Please note that the SLA extension is optional and at the sole discretion of the Centre post-development.
Details regarding the SLA will be handled once the Centre decides to follow through with the extension.

Q) Regarding Microsoft Azure Certification, do we need to submit the certificate as evidence along with the proposal, or is it required but not necessary to present?

A) The specific wording used in the RFP is that the Supplier ‘should’, not ‘must’, demonstrate Azure Certification. Evidence of Microsoft Azure Certification for a core team member(s) will be considered favourably in the assessment of your response.