Table 1
The extent to which the PID Service implements the four Pillars.
| Pillar | PID Service Implementation |
|---|---|
| Identifier Independence | Cannot enforce syntax policy so Avoid organisation names – not enforced, Avoid technology references – not enforced. |
| Locked to a single protocol (HTTP URIs) so unable to Avoid resolution protocol indicators. Uses a User Interface that will remove characters problematic for well-known protocols. | |
| Does Avoid visual ambiguity and use a well-known character set – implements UTF-8. | |
| Does Define which, if any, pattern matching system they use – the regex system in use is documented. | |
| Delivering Essential PID Functions | Does Issue identifiers – part of the tool’s User Interface and API.
|
Does Store identifiers – the tool uses a database.
| |
| Does Resolve identifiers – if installed as recommended with web server functionality providing access. | |
| Separation from Data Delivery | Inherent: no ability for the system to deliver data. |
| Employing policies for change | Mostly a task for the implementers however:
|
Figure 1
Two simple classes for HTTP URI redirection objects: a) simple URI redirection properties of a source pattern (src), a destination URI (dest) and an HTTP Status Code (type) (Soiland-Reyes 2016a); b) URI redirection for PURLs with some ownership metadata. ‘URI’ objects are valid HTTP URIs according to RFC2616 (Fielding et al. 2016) and ‘Status Code’ objects are valid Status Codes according to the same specification.
Table 2
Examples of data for the class model in Figure 1b (Soiland-Reyes, 2016b).
| id | path | type | target | created | last_modified | status | indexed |
|---|---|---|---|---|---|---|---|
| 1 | /example/path | 302 | http://example.com/redirectedPath | 2016-02-29 T13:08:11 | 2016-02-29 T14:08:11 | OK | 1 |
| 2 | /example/path/deeper | 302 | http://example.com/redirectedDeeper | 2016-02-29 T13:09:11 | 2016-02-29 T14:09:11 | OK | 1 |
Figure 2
Part of the HTTP URI PIM implemented by the PID Service. The ‘URN’ object is a Universal Resource Name (Moats, 1997) and the MappingInstance ‘type’ property has a shorthand notation indicating allowed values of either ‘Regex’ or ‘1-to-1’. The Mapping to Mapping instance relationships which enable a strict Mapping hierarchy are not shown.
Figure 3
An XML serialised instance of the PID Service’s PID PIM for a Mapping. Shown are the default actions (redirection to an HTML page) as well as pattern-based conditional redirects for a pseudo file extension (.ttl) and an HTTP Accept header set to the MIME type text/turtle, both of which redirect to Turtle RDF serialisations (W3C, 2014) of the same resource presented in the HTML default case. ‘Turtle’ is a W3C recommendation for serialialising Resource Description Framework resources.
Figure 4
A proposed Platform Independent Model of a PID’s metadata.
Figure 5
Object Model of the PID PIM for a Geoscience Australia IGSN identifier (igsn:10273/AU239).
Figure 6
Object Model of the PID PIM for a Geoscience Australia HTTP URI identifier (dataset no. 69674).
Table 3
The extent to which the identifier system in Figure 5 at Geosciences Australia implements the four Pillars.
| Pillar | PID Service Implementation |
|---|---|
| Identifier Independence | Does Avoid organisation names – through the implementation of a non-organisation-specific domain name. Does Avoid technology references – by governance of PID patterns. |
| Does Avoid resolution protocol indicators – and implements two resolution protocols. Uses a User Interface that prevents characters problematic for well-known protocols. | |
| Does Avoid visual ambiguity and use a well-known character set – UTF-8. | |
| Does Define which, if any, pattern matching system they use. | |
| Delivering Essential PID Functions | Does Issue identifiers – the implementation’s primary task:
|
Does Store identifiers – the tool uses a corporate database:
| |
| Does Resolve identifiers – using two protocols. | |
| Separation from Data Delivery | Inherent: no ability for the system to deliver data. |
| Employing policies for change | Technology change – the system has been set up with adaption to technology change in mind, as per a corporate policy at GA. As such, the resolver mechanism and the identifier data store are loosely coupled. The identifier data store is mapped to the PIM and exportable according to that data model. |
| Social change – the system has an institutional owner and is thus able to handle individual staffing changes (Custodians). Publisher change catered for to some extent by participation of GA in the IGSN network meaning that copies of the identifiers and a limited version of their metadata are replicated to other organisations (such as CSIRO, two of the authors’ organisation). | |
| Identifier abandonment – identity of each identifier’s Custodian is captured. System admin has access to all. | |
| Financial sustainability – not addressed. The implementation assumes an on-going institutional budget both for internal system management and adherence to the IGSN community. This is a major weakness of this system. | |
| Decommissioning – documented and comprehensive export formats (the XML shown in Figure 3) assist with this and change procedures are in place for each element of the system in accordance with corporate systems policy. |