Where is NZOR?
NZOR dynamically harvests taxonomic data from multiple data-providers to create a single unified catalogue (see how does it work?). The principle aim of the NZOR information infrastructure is to provide web-service level access to that catalogue. By web-service we mean the technical communication layer which facilitates one computer communicating with another computer. NZOR, in its current form, is not primarily intended to be a website for use by humans.
Why is the focus on computer communication and not with people directly?
NZOR is intended primarily to support the integration of relevant data directly into end-user business critical information systems. Such systems should not require users to find species name by stopping to search any number of websites (or non-digital publications) of varying quality and coverage and then cut & paste data into a local system. Full use of NZOR content requires an end-user agency to develop internal information systems and services which link directly to the NZOR services.
The search and match facilities available through this website were constructed using those web services. This website serves as a relatively simple demonstration of the use of those services and exposes data normally hidden from humans (e.g. GUIDs).
The NZOR demonstration website exposes a number of the basic features of NZOR:
- Search for a name, either precisely or using ‘fuzzy’ matching
- Return a list of hits, with basic data on what was found
- Expose the NZOR summary data on the name
- Expose the harvested data from each data provider used to generate an NZOR record
- Provide the ability to submit a list of names as a spreadsheet and return a list of matching NZOR data
This website is a demonstration of the NZOR web services
The website demonstrates how the underlying web-services implement these functions, which many end users might wish to embed within their own information systems.
The web-services allows organisations like the Department of Conservation, or the Ministry for Primary Industries, to maintain a local database which can be kept automatically in synchronisation with NZOR content over the internet. Internal institutional information systems, for example those for collecting biological survey data, or carrying out an expanded query against a document store may then access this local synchronised copy of NZOR data (see why do we need NZOR?).
NZOR has an information architecture specifically designed to support in-house end-user access to these data. NZOR does not dictate which data they should use, rather it provides a platform to build local content. In order to provide this functionality NZOR associates data elements with Globally Unique Identifiers (GUID, e.g. 327b35ea-aaa5-4456-9cee-be2c4b734580). These identifiers are not intended for human eyes. They are the necessary glue allowing computers to make the unambiguous linkages between different data elements (names). End-users are encouraged to embed the unique identifiers provided by NZOR as a tool for improving national and international data-linkage and discovery.
This is the real connection to the NZOR data. It is Web Application Programming Interface (API), delivering a set of web-services allowing programmers to write computer code to interrogate NZOR data content and build local data-stores.
For those wishing to develop applications to consume NZOR data then the data service description pages are the starting point and the web-services are documented there, as are the data standards for data providers/consumers and details of the data harvesting network.