Persistent Identifiers for Semantic Artifacts

# Before requesting a PURL

Before requesting a new PURL in the PIDA system, please check the PIDA repository (opens new window) for already-existing PURLs. We also advise checking popular terminology services such as NCBO Bioportals (opens new window) or ontology lookup service (OLS) (opens new window) for namespace abbreviations that are currently in use. Choosing a unique abbreviation for your identifier and ontology reduces overlap and ambiguity between semantic artifacts.

# Manage PURLs

Requesting or updating a PURL in PIDA is straightforward and we provide multiple options to accommodate your requirements. You have the option to choose one of the following three options to obtain your PIDA PURL:

  1. Submit an issue to our repository
  2. Fork the repository & push your .htaccess file
  3. Send us an email Please note that all methods involve a review by PIDA admins, meaning that a human is involved in the process! While we are committed to resolving tickets and requests promptly, we cannot guarantee immediate availability of your PURL.

# 1. Submit an issue

You can request a newPURL by creating a New-PURL issue template (opens new window) to ensure that you supply all required information. If you need to add more information, please add it to the issue thread. We will evaluate the input and issue the namespace once we have all the required information.

# 2. Fork the repository and push your .htaccess file

You can fork the repository, create your own .htaccess file and push the changes to the main repository through a pull request. For this follow the following steps:

  1. Fork (opens new window) the PIDA repository (opens new window).
  2. Prepare your .htaccess (opens new window) file. When creating the .htaccess the following information is mandatory to be provided through the header of the .htaccess file:
# Contact person name: registrar name
# Contact person email: registrars email address
# Artifact: abbreviation of artifact 1, abbreviation of artifact 2, abbreviation of artifact n
# Artifact Name: full name of artifact 1, full name of artifact 2, full name of artifact n
# Resource location: full URL of artifact 1, full URL of artifact 2, full URL of artifact n
  1. Add or update your redirection rules and commit (opens new window) your changes.
  2. Submit a pull request (opens new window) for your changes. Upon submission of the pull request, we will review your changes and integrate them into the PIDA system.

Please help us to issue PIDA PURLs effectively by following GitHub's good practices:

  • test your links and .htaccess syntax locally.
  • squash (opens new window) multiple commits into one commit before a pull request. This helps to ensure a cleaner merge history.
  • provide descriptive commit details (e.g. resource name, what changes made, etc.).

# 3. Send us an email

Do you feel the above seems daunting and the steps are unclear or ambiguous? No problem! Contact us via email, describe your case as well as you can, and we will support you in getting your PIDA PURL.

# HTAccess mandatory metadata & PURL health checks

The following metadata is mandatory to be included at the beginning of each HTAcess file:

key explanation possible values
# Contact person: name of registrar string
# Contact person email: email of registrar email address
# Artifact: abbreviated name of artifact, e.g. “HDO” comma separated list of strings
# Artifact name: full name of artifact, e.g. “Helmholtz Digitization Ontology” comma separated list of strings
# Resource location: URL(s) to be checked during automated health checks comma separated list of URLs

The URLs defined under Resource location are tested during regular health checks. If the value in this field is empty PIDA will check purls.helmholtz-metadaten.de/[namespace] by default. Registrars will be notified via email if problems with dereferencing to a resource location are detected.

# Testing content negotiation

Here are some further tips on testing the PIDA content negotiation: Content negotiation can be tested using the curl command-line utility to specify a particular representation of a resource to the same URI. For example:

To request the HTML document describing the scientific events ontology (opens new window):

curl -L -H "Accept: text/html" https://purls.helmholtz-metadaten.de/seo

To request the RDF file of the ontology, the following command could be used

curl -L -H "Accept: application/rdf+xml"  https://purls.helmholtz-metadaten.de/seo

You will get results that look like:

HTTP/ 1.1 303 See Other
Date: Tue, 22 Feb 2022 14:18:54 GMT
Server: Apache/2.4.29 (Ubuntu)
Access-Control-Allow-Origin: \*
Location: https://saidfathalla.github.io/.../index.html
Content-Type: text/html; charset=iso-8859-1

Windows users can get cURL binaries from here (opens new window).

Contact us via email or by submitting an issue (opens new window) if you require more information!