Not in the traditional pre-publication sense: there is no gatekeeper who approves a nanopublication before it becomes visible. Anyone with an identity and key pair can publish. Instead of anonymous pre-publication review, the system relies on cryptographic attribution — every nanopublication is signed, so it is always clear who stands behind a claim, and that reputation travels with it.

Review and quality assessment happen after publication, and can themselves take the form of nanopublications: an assessment, endorsement, or dispute is published as a signed nanopublication referring to the one under review. This makes reviews transparent, attributable, and citable first-class citizens of the same ecosystem, rather than hidden reports. Communities can organize whatever review workflow they like on top of this — the nanopublication infrastructure supports such processes but does not prescribe one.

Consumers, in turn, never have to take the network as an undifferentiated whole: queries can filter by author, by community, or by trust relations, so each application can apply exactly the level of scrutiny its use case requires.

Yes. At the most basic level, RDF triples are language-agnostic — they relate resources identified by URIs, which carry no inherent natural language. For human-readable content (labels, descriptions, and the like), RDF supports language-tagged literals such as "Hund"@de, which can appear in the assertion, provenance, or publication info of a nanopublication just as in any other RDF graph. Note, however, that language-tagged literals are not yet fully supported when publishing through Nanodash.

In practice, the great majority of nanopublications are in English. This mirrors the reality that scientific communication is overwhelmingly conducted in English — a convention that, despite its drawbacks, brings real benefits in terms of global reach, shared vocabularies, and interoperability. Nanopublications tend to follow the same convention for the same reasons.

A license is not technically mandatory, but the nanopublication network requires that published nanopublications be openly shareable and replicable, so any license that is declared should be compatible with that. In practice, most nanopublications point to a permissive license via the dct:license predicate in their publication info — typically CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/) or CC0 (https://creativecommons.org/publicdomain/zero/1.0/). Because the license is part of the signed, immutable nanopublication, it travels with the content and is verifiable by anyone who later retrieves it.

The main entry point for finding nanopublications by criteria is Nanopub Query — a service that exposes published SPARQL query templates as REST API endpoints. Anyone can publish a new query as a nanopublication and immediately use it via the API; existing templates cover common needs such as finding nanopublications by author, type, topic, or content. For fully custom searches, direct SPARQL queries can also be issued against the type-specific or full nanopublication endpoints. For interactive use, Nanodash offers a Query tab that lets you browse and run all published query templates, and pre-built views are also available on user, space, and resource pages.

By default, tools that present nanopublication authorship (such as Nanodash) identify authors by their ORCID. To have a human-readable name shown alongside or in place of the ORCID, you need to publish a small nanopublication that declares a foaf:name for your ORCID.

The easiest way to do this is through the Nanodash profile page. After logging in with your ORCID, this page lets you enter your display name and publish an introduction nanopublication in a single step. The introduction nanopublication contains a triple of the form orcid:0000-0000-0000-0000 foaf:name "Your Name" in its assertion, and at the same time registers the public key you use to sign nanopublications.

Once published, any tool that resolves authorship through the nanopublication network — Nanodash, resource pages, query results, and so on — will display your name in place of (or together with) the bare ORCID. You can update the displayed name at any time by publishing a new introduction nanopublication that supersedes the previous one.

Nanopublications are designed for automation. Libraries are available in several programming languages (for example for Java, Python, and Rust), along with command-line tools, which take care of creating, validating, signing, and publishing nanopublications programmatically. This is how large collections, such as database exports, are published as nanopublications in practice.

Authentication of automatically created nanopublications works exactly as it does for humans (see "How do users authenticate in the nanopublication system?"): software agents (bots) get their own identity IRI and their own key pairs, declared in an introduction nanopublication that also links the bot to its owner. Every nanopublication the bot publishes is then verifiably attributable to it — and through the ownership link, to the person or organization responsible — keeping automated contributions just as transparent and accountable as manual ones.

Authentication in the nanopublication system is based on digital signatures. Each user owns one or more RSA key pairs, and every nanopublication is signed with one of the user's private keys. The signature and the corresponding public key are included in the nanopublication itself (in its publication info graph), so anyone can verify that a nanopublication was indeed created by the holder of that key and was not modified afterwards. Users do not need to manage these keys manually: tools like Nanodash take care of generating and handling the key pairs behind the scenes.

The link between a key pair and a user identity is itself established with a nanopublication: an introduction nanopublication declares that a given public key belongs to a given agent, identified by an IRI. A user can thereby have several key pairs linked to the same identity, for example one per tool or device. Typically the identifier is an ORCID ID, and Nanodash currently requires an ORCID login. Nanopublications in general, however, are not restricted to ORCID: any IRI denoting an agent can be used, as is the case for example for software agents (bots) publishing under their own identities and keys.

Whether other users should trust an identity is a separate concern, handled by the network's trust layer, where users endorse each other's introductions and services compute from this who is part of the trust network.

As of mid-2026, the current (second-generation) Nanopub Registry tracks roughly 80,000 signed nanopublications, with the count growing continuously; the live total is shown on the registry's homepage. Different registry instances may report slightly different totals depending on which nanopublications they accept (for example, by trusted agents or by type), so a single number should be understood as a snapshot of one particular registry. In addition, the earlier first-generation nanopub-server network still preserves the historical, mostly unsigned nanopublications accumulated over the past decade — currently around 11 million. This legacy network no longer plays an active role in the current ecosystem but remains accessible as an archive.

Every nanopublication has a globally unique, content-based Trusty URI, made persistently resolvable through w3id.org (for example, https://w3id.org/np/RA...). This URI is the canonical citation: it permanently identifies the exact, immutable content of the nanopublication, can be verified by anyone who retrieves it, and resolves to a viewable rendering. When listing a nanopublication in a reference list, treat the trusty URI as the URL and use the metadata from the publication info for the rest: dct:creator (typically an ORCID) for the author, rdfs:label for the title, and dct:created for the date. Because the trusty URI is immutable, no version, hash, or access date is needed — even if the nanopublication is later superseded or retracted, the citation still points unambiguously at the original version. For example, the nanopublication at https://w3id.org/np/RAiBSheuO17iqJacTs9aSeK3k80vf4BswE5BNQ-UR9MG0 could be cited as:

Kuhn, T. (2026). Night train to Vienna [nanopublication]. https://w3id.org/np/RAiBSheuO17iqJacTs9aSeK3k80vf4BswE5BNQ-UR9MG0

If it is your own nanopublication, you can retract it or supersede it. A retraction is itself a small nanopublication, signed with the same identity, stating that the earlier one no longer stands. Superseding works the same way but additionally provides a corrected version that declares itself the successor of the old one. In both cases the original is not deleted — nanopublications are immutable — but services and user interfaces recognize the retraction or new version and act accordingly, for example by hiding the outdated one from listings. Tools like Nanodash offer this with a few clicks.

If the nanopublication is somebody else's, you cannot retract it, as retractions are only valid when signed with the same identity as the original. What you can do is publish your own nanopublication that comments on, disputes, or corrects the claim, which then becomes part of the public record alongside the original. You can also contact the author, who can then retract or supersede it themselves. This mirrors how corrections work in science generally: errors are not silently edited away, but addressed transparently and attributably.

Since every nanopublication has a stable, resolvable identifier, nanopublications can reference each other just like web pages link to each other — and these references are themselves machine-readable. An assertion can build on a concept or claim introduced in another nanopublication, the provenance graph can declare that an assertion was derived from earlier ones, and comments, reviews, or disputes can point to the nanopublication they are about. The result is a growing, decentralized network of interlinked small knowledge units.

Some combination patterns have dedicated support. Indexes are nanopublications that list other nanopublications as elements, turning a set of them into a citable collection, such as a dataset. Superseding and retraction links chain versions of the same content together, so the history of a claim stays navigable. And shared reference points, expressed with properties like is part of, let independent nanopublications jointly form a larger resource: this FAQ, for example, is simply the set of all nanopublications declaring their entries to be part of the FAQ page.

Reference libraries for working with nanopublications are currently available in four programming languages:

• Java — the original and most complete implementation, including the nanopub command-line tool used for validating, signing, publishing, and retracting nanopublications.
• Python — a client for fetching, creating, signing, and publishing nanopublications.
• JavaScript / TypeScript — for use in browser-side and Node.js applications.
• Rust — a more recent implementation focused on performance and portability.

Beyond these libraries, larger components of the ecosystem are written predominantly in Java, including Nanodash (the main web interface), the Nanopub Registry, and Nanopub Query. Since the Registry and Query services expose HTTP REST APIs, nanopublications can also be fetched, queried, and inspected from any programming language with a basic HTTP client — no dedicated library required.

Yes, though the sandbox is currently minimal. A dedicated test instance of the Nanopub Registry is running at test.registry.knowledgepixels.com, where you can publish, retrieve, and inspect nanopublications without affecting the live network. There is no matching test deployment of Nanopub Query or Nanodash at the moment, so the test Registry on its own is best suited for low-level experimentation with the publishing pipeline — signing, posting, and resolving by Trusty URI. A fuller test environment that also includes Query and Nanodash is in the works.

Alternatively, you can publish straight to the live network while clearly marking a nanopublication as an example by adding the type npx:ExampleNanopub in its publication info. Such nanopublications are conventionally filtered out of substantive query results but still let you exercise the full live ecosystem. In Nanodash, this is done by clicking "show more" at the bottom of the publish form and then selecting "Example" from the "add element..." drop-down under "Publication info".

A nanopublication consists of three main parts: (1) an assertion, (2) information on the provenance of the assertion, (3) bibliographic metadata about the nanopublication itself. For further details, see https://nanopub.net/.

The "nano" refers both to granularity and to formal structure. A nanopublication is the smallest publishable unit of information — a single assertion bundled with its own provenance and metadata — and it is expressed entirely in RDF, with every part machine-readable and individually citable.

Micropublications, introduced by Clark, Ciccarese, and Goble (2014), target a related goal — fine-grained, machine-readable scholarly communication — but with a more narrative, paper-like orientation, mixing natural-language text with semantic annotations within a single document.

Nanopublication identifiers are trusty URIs: each contains a cryptographic hash computed from the nanopublication's own content. This makes the link between identifier and content permanent and verifiable — given a nanopublication and its identifier, anyone can check that the content has not been changed, and a given identifier can never end up pointing to different content. Nanopublications are therefore immutable: corrections are published as new nanopublications with new identifiers, linked to the old version rather than replacing it in place.

Resolution of the identifiers does not depend on a single server. The https://w3id.org/np/ identifiers are persistent redirects run by the w3id.org initiative, backed by a community commitment to keep them stable, and they can be redirected to whatever services are current. Behind them, the nanopublication network consists of multiple independent registry servers that each hold full copies of the published nanopublications, so no single party can lose or withhold them. Since the identifier itself verifies the content, a nanopublication retrieved from any source — a registry, a mirror, or a local archive — can be trusted to be authentic.

The nanopublication ecosystem is built entirely on standard RDF and Semantic Web technologies. Each nanopublication is an RDF dataset of four named graphs, typically serialized as TriG. Identifiers are Trusty URIs — content-based hashes that make every nanopublication immutable and self-verifying — and integrity and authorship are protected by RSA digital signatures recorded in the publication info. In practice, Trusty URIs are commonly made persistently resolvable through w3id.org, and authors are commonly identified by ORCID, but neither is a technical requirement of the format. At the network level, the Nanopub Registry stores and serves nanopublications through an HTTP REST interface, while Nanopub Query provides SPARQL endpoints and additionally exposes published SPARQL templates as REST APIs. Reference libraries are available in Java, Python, and Rust, and user-facing tools such as Nanodash are built on top of these.

The concept of nanopublications was introduced by Barend Mons and Jan Velterop in 2009, in their paper Nano-Publication in the e-science era. The paper proposed atomic, machine-readable assertions with their own provenance and metadata as a new unit of scholarly communication.

Concrete nanopublications followed in subsequent years, most of them unsigned, accumulating in the first-generation nanopub-server network. The earliest dated trusty-URI nanopublications discoverable there are from 16 June 2014, part of a corpus of unsigned biomedical assertions extracted from NCBI's GeneRIF database by the Krauthammer Lab at Yale — for example, RAdBeVv56ZiRgSdbHMEk0J4C3iV5mDNBSlwo87B5P-u9c. The earliest signed entry preserved in the current (second-generation) Nanopub Registry dates from 18 August 2015: RATNbqwXNo6aO3T7BdCquQSdqZjXeisoSSTudO3qJ9KwY, an index of three example nanopubs produced while validating the signing infrastructure.

The most direct way is via Nanodash, the public web interface to the nanopublication ecosystem. Nanodash renders individual nanopublications in a readable form, lets you browse the latest contributions across the network, and organizes domain-specific content into spaces — curated areas covering topics from FAIR workflows and biomedical datasets to community FAQs. Within a space, dashboards aggregate related nanopublications and the resources they describe, making it easy to see what kinds of statements are being made, by whom, and how they connect to each other.

For development-related questions — bugs, feature requests, API specifics — the best place is the GitHub issue tracker of the relevant project, such as Nanopub Registry, Nanopub Query, Nanodash, or one of the client libraries.

For broader questions, discussions, or simply getting in touch with the community, several channels listed at nanopub.net/contact are active: a public Matrix chat, the nanopub-users mailing list, the @nanopub Mastodon account, and the association@nanopub.net email address of the Nanopublication Association.

Nanopublications are RDF, so they can be exported and re-imported in any standard RDF serialization (TriG, N-Quads, TriX, JSON-LD, Turtle, RDF/XML) without loss, using whatever RDF library is at hand. Beyond that, dedicated tooling is available in several languages: the nanopub Java library, which also runs as a command-line tool for checking, signing, publishing, and format conversion; a Python library; a JavaScript library; and a Rust library. These cover loading nanopubs from local files or URLs, signing and verifying, and submitting to the registry.

For interactive use, Nanodash provides a web interface that exposes individual nanopublications in any of these RDF formats via direct download links. Programmatic access is provided by the Nanopub Registry's HTTP REST API and by Nanopub Query's SPARQL endpoints, which together are well suited for bulk export.

Anyone can create nanopublications. Technically, only a user identifier and an RSA key pair are needed. In practice, when using a tool like Nanodash, you don't have to deal with keys yourself — it generates and manages them on your behalf, and you simply sign in. Nanodash currently requires an ORCID, while the nanopublication format itself accepts any persistent user identifier; using ORCID is strongly recommended in any case, as it makes attribution interoperable across the scholarly ecosystem. If you publish locally (for example via the nanopub command-line tools), you do need to generate and manage your own key pair.