This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

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.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

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.

This text will hopefully be replaced by a useful answer soon.

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.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

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.

This text will hopefully be replaced by a useful answer soon.

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

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

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.

This text will hopefully be replaced by a useful answer soon.

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".

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

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/.

This text will hopefully be replaced by a useful answer soon.

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.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

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.

This text will hopefully be replaced by a useful answer soon.

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.

This text will hopefully be replaced by a useful answer soon.

This text will hopefully be replaced by a useful answer soon.

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.

This text will hopefully be replaced by a useful answer soon.

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.