Expasy PURL

Persistent URLs for the Bioinformatics Resources Developed by SIB Swiss Institute of Bioinformatics Groups

Purpose of Expasy PURL

This project aims at providing persistent URLs (PURLs) for the Bioinformatics Resources Developed by SIB Swiss Institute of Bioinformatics Groups.

A PURL works like a regular URL but with one key difference: instead of directly pointing to the location of an internet resource, it points to a resolution service. This service acts as an intermediary, linking the PURL to the actual URL of the resource. When someone uses the PURL, the resolution service redirects them to the resource's actual location. Using PURLs to identify your database entries is essential for fulfilling Principle F1 of the FAIR principles: "(Meta)data are assigned globally unique and persistent identifiers."

Registering a Resource with an Expasy PURL

If you would like to your resource in the form of https://purl.expasy.org/your-resource, follow these steps:

Prerequisites

Ensure you have an SIB GitLab account. If you need assistance:

Steps to Register

  1. Fork the Repository

    Go to the Expasy PURL repository on SIB GitLab (development branch) and fork it.

  2. Add or Update a Redirect Entry

    If this is a new resource:

    • Create a new directory with the URL-friendly name of your project (use lowercase letters, no spaces, or special characters).

    Add or update the redirect entry and commit your changes.

  3. Include Required Files

    If your resource doesn't already have them, create the following files in the directory:

    • .htaccess This file defines the redirection rules for the PURL. It's used by computers to handle redirection (more).
    • README.md This file provides human-readable information about the identifier, including details about your resource and contact information.
    • test.tsv This file is used to test redirection. It should contain a list of URLs to test, structured as a tab-separated file with the following columns: request URL, content type, target URL, and expected status code.

    Refer to htdocs/examples for sample .htaccess, test.tsv and README.md files.

  4. Test Your Changes Locally

    Refer to the README file in the GitLab repository. It contains all the commands needed to build a Docker image on your machine, allowing you to validate your test.tsv before submitting.

  5. Submit Your Changes

    Once your updates are complete, submit a merge request with your changes targeting the development branch.