A repository landing page is built for a human reader: a title, an abstract, a download button, some metadata in a sidebar. A machine agent — a harvester, a PID resolver, a text-and-data-mining crawler, an AI system trying to verify a citation — cannot reliably tell, just by fetching that HTML page, which link on it is the actual content file, which is the metadata record, and which persistent identifier (PID) is authoritative for the object. It would have to guess, or scrape brittle, page-specific markup that breaks the moment a repository redesigns its template.
The FAIR Signposting Profile solves this with a small set of typed Link HTTP headers, sent alongside the landing page itself, that tell a machine agent exactly what it needs to know before it even parses the HTML body. It is one of the more consequential pieces of quiet infrastructure in the persistent-identifier ecosystem: not a new identifier scheme, but a standard way of making the relationships between an identifier, its landing page, its metadata, and its content machine-actionable.
What the FAIR Signposting Profile Is
The FAIR Signposting Profile is a specification, first published in 2020 and most recently revised on October 2, 2023, that defines a small, fixed vocabulary of typed Web Links (RFC 8288) for scholarly and research objects. It is maintained collaboratively, with community feedback tracked via a GitHub issue tracker under a “FAIRSignposting” label, by a group of authors closely associated with both web-architecture standards work and research infrastructure, including Herbert Van de Sompel, Martin Klein, Shawn M. Jones, Michael L. Nelson, Simeon Warner, and contributors from DataCite, euroCRIS, and related organizations. The current specification is published at signposting.org/FAIR.
“Signposting” itself is the general web-architecture idea — using typed links to guide an agent from one representation of a resource to another — that predates this specific profile. The FAIR Signposting Profile is the application of that general idea to the specific problem of research-object discovery: given a URL (which might be a landing page, a persistent identifier that resolves to one, or the content itself), how does a machine work out the rest of the graph — the PID, the metadata, the license, the author identifiers, the actual bytes — without scraping HTML or guessing at URL patterns?
The Problem: Opaque Landing Pages
Most repositories — institutional, disciplinary, and generalist alike — mediate access to a dataset, article, or other output through a landing page rather than linking directly to the file. This is good practice for humans: the landing page carries citation information, licensing, versioning, and context a bare file download would lose. But it creates a structural ambiguity for machines. When a PID resolves, it typically resolves to the landing page, not the content. A crawler, text-and-data-mining pipeline, or automated citation checker following that PID has no standard way to determine:
- Which persistent identifier is the authoritative citation target for what it’s looking at (the
cite-asrelation) - Where the actual content file(s) live, and in what formats (the
itemrelation) - Where structured, machine-readable metadata describing the object can be fetched (
describedby) - Who the authors are, ideally by their own PIDs such as ORCID iDs (
author) - What license governs reuse (
license) - What type of resource this is, expressed in a controlled vocabulary such as schema.org (
type)
Without a standard, each repository platform answers these questions differently, if it answers them in a machine-readable way at all — which is exactly the kind of fragmentation that undermines the “Interoperable” and “Reusable” principles in FAIR even when the underlying data itself is well curated.
How It Works: Typed Link Headers
Signposting’s mechanism is deliberately minimal: it reuses two existing IETF standards rather than inventing a new one. RFC 8288 (Web Linking) defines the HTTP Link header and HTML <link> element syntax for expressing a typed relationship between the current resource and another one. RFC 9264 (Linkset), a newer standard, defines a JSON or text serialization for expressing many such links together as a standalone document, rather than cramming them all into individual HTTP headers.
A repository implementing Level 1 signposting adds HTTP Link headers (and/or equivalent HTML <link> elements) to its landing page response using a fixed set of typed relations:
| Relation | What it points to |
|---|---|
cite-as |
The persistent identifier that should be used to cite this object |
describedby / describes |
A machine-readable metadata record describing the object, and its inverse |
item / collection |
The actual content file(s), and the landing page’s relationship to the item(s) it fronts |
author |
A PID for the object’s author(s), typically an ORCID iD |
license |
The license governing reuse of the object |
type |
A schema.org (or similar) term classifying the resource |
linkset |
A pointer to a full RFC 9264 Linkset document aggregating all of the above |
A minimal, illustrative example of what a repository’s HTTP response headers for a dataset landing page might include (this is a simplified composite for explanatory purposes, not a real repository’s actual output):
Link: <https://doi.org/10.5281/zenodo.1234567> ; rel="cite-as"
Link: <https://example.org/api/records/1234567> ; rel="describedby" ; type="application/vnd.datacite.datacite+json"
Link: <https://example.org/files/dataset.csv> ; rel="item" ; type="text/csv"
Link: <https://orcid.org/0000-0000-0000-0000> ; rel="author"
Link: <https://creativecommons.org/licenses/by/4.0/> ; rel="license"
Link: <https://schema.org/Dataset> ; rel="type"
A machine agent can now retrieve just the HTTP headers with a lightweight HEAD request — no need to download or parse the full HTML page — and immediately know the canonical citation PID, the metadata endpoint, the content file’s location and format, the author’s own identifier, the license, and the resource type.
Level 1 vs. Level 2 Signposting
Level 1 is the baseline described above: a fixed set of typed links conveyed directly as HTTP Link headers and/or HTML <link> elements on the landing page response itself. It requires no new infrastructure beyond adding headers to an existing HTTP response, which is why it’s the level most repository platforms implement first.
Level 2 adds a dedicated Linkset (RFC 9264) document — a standalone JSON or text resource that aggregates a fuller set of typed links than practically fits in HTTP headers, including links to multiple related versions, alternate formats, or additional relations beyond the Level 1 core set. The landing page points to this Linkset document via a linkset relation; the Linkset itself is cacheable and reusable independently of the landing page, which matters for high-volume machine consumption where re-fetching a full landing page response per lookup is wasteful.
Why This Matters for CRIS and PID Interoperability
Signposting sits directly underneath the interoperability work that persistent identifiers and research information systems depend on. A PID graph — the connected web of relationships between researchers, organizations, grants, datasets, and publications that services like DataCite’s PID Graph or Crossref Event Data expose — can only be built and kept current if the individual nodes in that graph (repository landing pages, in this case) expose their outbound relationships in a consistent, machine-readable way. Signposting is the mechanism that makes a landing page a well-behaved node in that graph rather than a dead end a crawler has to scrape around.
It also complements, rather than duplicates, the existing PID and metadata infrastructure covered elsewhere in this cluster. DOI resolution and the Handle System underneath it get a request to the correct landing page; signposting then tells a machine agent what to do once it’s there. DataCite’s metadata schema and other metadata schemas define what a metadata record contains; the describedby relation tells an agent where to fetch that record for a given object. And because the cite-as relation resolves ambiguity about which PID is authoritative for an object that might otherwise be reachable via several different URLs, it directly supports accurate citation and PID graph construction — a concern that also runs through PID federation across research infrastructure more broadly.
Adoption
Signposting has been adopted at the repository-platform level rather than requiring each individual repository to implement it from scratch. DSpace, one of the most widely deployed open-source repository platforms, documents native signposting support starting with DSpace 7.x. InvenioRDM — the repository framework built by CERN and used by Zenodo, among others — likewise documents built-in FAIR Signposting support. The EU-funded FAIR-IMPACT project catalogues signposting as a recommended practice for research-data repositories aiming to meet FAIR machine-actionability requirements, and Invest in Open Infrastructure’s Infra Finder lists it as a discrete, evaluable infrastructure solution. Because adoption happens at the platform layer, an institution running a current version of one of these systems may already be exposing signposting headers without any repository-specific configuration work.
Frequently Asked Questions
Is FAIR Signposting the same thing as the FAIR Guiding Principles?
No, though they’re related. The FAIR Guiding Principles (Findable, Accessible, Interoperable, Reusable) are a high-level set of goals for research data, published by FORCE11 in 2016. The FAIR Signposting Profile is a specific technical mechanism — typed HTTP Link headers — that helps satisfy the Interoperable and Reusable principles by making a repository’s own outputs machine-actionable. A repository can implement signposting without being fully FAIR-compliant in every other respect, and vice versa.
Does signposting replace the need for a DOI or other PID?
No. Signposting assumes a PID already exists and is used to reach the landing page (or the landing page is reached some other way); its job is to expose, via the cite-as relation, which PID is the authoritative one for that object, and to connect that PID to the object’s metadata and content. It’s a discovery and disambiguation layer on top of PID infrastructure, not a replacement for it.
Do I need to check anything special to see if a repository supports signposting?
Yes — because the information lives in HTTP response headers rather than the rendered page, it isn’t visible by simply loading the landing page in a browser. A HEAD or GET request to the landing page URL, inspected with a command-line tool such as curl -I or a browser’s network inspector, will show whether Link headers with signposting relations are present.
Does signposting require any change to how a PID is minted or registered?
No. Signposting operates entirely at the HTTP response layer of the landing page the PID resolves to; it doesn’t change how a DOI, Handle, or other identifier is registered with its PID provider. It’s implemented by the repository platform serving the landing page, not by the registration agency.
