Appearance
When a nanopublication misbehaves, the cause is nearly always structural: it must contain exactly the three named graphs, assertion, provenance, and publication info, tied together by a head graph, and any missing or empty one makes it invalid. The second most common problem is identity: nanopublications are signed and given trusty URIs (a content hash baked into the identifier), so editing a published one silently produces a different nanopublication rather than updating the original. Diagnose by running a validator first to confirm the graph structure, then check signing and the trusty URI before blaming the network.
What is a nanopublication actually made of?
A nanopublication packages one atomic claim with its evidence and attribution as four linked named graphs in TriG:
trig
@prefix np: <http://www.nanopub.org/nschema#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
:Head {
: a np:Nanopublication ;
np:hasAssertion :assertion ;
np:hasProvenance :provenance ;
np:hasPublicationInfo :pubinfo .
}
:assertion {
<…/object/00041523> dcterms:creator <…/person/vermeer> .
}
:provenance {
:assertion prov:wasDerivedFrom <…/source/inventory-1696> .
}
:pubinfo {
: prov:wasAttributedTo <…/orcid/0000-0002-1825-0097> .
}If a validator rejects your file, this structure is where to look first.
Why does validation fail?
Run the structure through a nanopub validator and match the error to the cause:
| Symptom | Root cause | Fix |
|---|---|---|
| "missing assertion" | Assertion graph absent or empty | Add the claim triple(s) |
| "head does not reference part" | np:hasProvenance/hasPublicationInfo missing | Link all three from the head |
| "not a valid nanopub" | TriG graphs not properly named | Ensure each { } block has its graph URI |
| Empty provenance | No prov: statement | Cite the source the claim derives from |
An empty assertion graph is the sneakiest: the file parses as valid TriG but is not a valid nanopublication.
Should one nanopublication carry many assertions?
Technically yes, conventionally no. The whole point is one atomic, independently citable claim, so a reader can trust and reference it in isolation. If you have three related but distinct facts, mint three nanopublications and let consumers cite each. Stuffing several claims into one assertion graph defeats granular attribution and makes retraction all-or-nothing.
Why did editing my nanopublication not "update" it?
Because nanopublications are immutable by design. Each is signed with your key and assigned a trusty URI whose identifier embeds a cryptographic hash of the content. Change a single character and the hash, and therefore the URI, changes; you have created a new nanopublication, not edited the old one.
text
https://w3id.org/np/RA8ui... (original, hash-based)
https://w3id.org/np/RB9zk... (edited content -> different URI)The correct workflow is to publish a new version and, if needed, a retraction nanopublication that points at the superseded one. Treat them like signed commits, not editable documents.
How do I publish without running infrastructure?
You do not need a server. After signing with your key pair, you submit to the decentralised nanopublication network, a set of replicating servers, and it propagates.
bash
# np tool (nanopub-java / nanopub CLI)
np sign my-claim.trig # signs with your key, mints trusty URI
np publish my-claim.signed.trig # pushes to the networkCommon failures here: no key pair configured (np mkkeys first), or trying to publish an unsigned file. The network rejects anything not signed and trusty-URI'd.
When are nanopublications the wrong tool?
They are overkill for bulk catalogue publication. If you are dumping 100,000 object records with one provenance statement for the whole dataset, a standard RDF dump or a void:Dataset description is far simpler. Reach for nanopublications when individual claims are contested, evolving, or need per-assertion attribution, an attribution dispute, a revised dating, a scholarly disagreement about authorship, where each claim deserves its own provenance, signature and citable identity.
A fast diagnostic routine
- Validate structure: are all three graphs present and non-empty?
- Check the head links all parts.
- Confirm provenance actually cites a source.
- Verify the file is signed and has a trusty URI before publishing.
- If "updating", remember you are minting a new URI; publish a retraction for the old one.
Key Takeaways
- A nanopublication needs three non-empty graphs, assertion, provenance, publication info, plus a head linking them.
- An empty assertion graph parses as TriG but is an invalid nanopublication.
- Keep one atomic, citable claim per nanopublication; bundle related claims as separate ones.
- Trusty URIs embed a content hash, so any edit produces a new nanopublication, not an update.
- Sign with a key pair before publishing to the decentralised network; no server of your own is required.
- Supersede with a new version plus a retraction rather than mutating an existing one.
- Use nanopublications for contested or evolving individual claims, not bulk catalogue dumps.
Frequently Asked Questions
What are the three named graphs in a nanopublication?
Every nanopublication has an assertion graph (the claim), a provenance graph (where the claim came from and how), and a publication info graph (who minted it and when). A head graph ties the three together; missing any of them makes it an invalid nanopublication.
Why does my nanopublication fail validation?
The usual causes are a missing one of the three required graphs, an assertion graph that is empty, or a malformed trig structure where the head does not reference all parts. Run a nanopub validator and check that each named graph is present and non-empty.
Can a nanopublication hold more than one assertion?
It can technically contain multiple triples, but the convention is one atomic, citable claim per nanopublication so it can be referenced and trusted independently. Bundle related but separate claims as multiple nanopublications instead.
How is a nanopublication made immutable and citable?
It is signed and assigned a trusty URI, a cryptographic hash of its content embedded in the identifier, so any change produces a different URI. This makes each nanopublication tamper-evident and permanently citable.
Do nanopublications need their own server to publish?
No. You publish to a decentralised nanopublication network of servers that replicate your signed nanopublication, so it stays available without you running infrastructure, though you do need a key pair to sign.
When are nanopublications overkill for heritage data?
When you are publishing a whole catalogue as a bulk dataset, a standard RDF dump with dataset-level provenance is simpler. Nanopublications shine for individual, contested or evolving scholarly claims that need per-assertion provenance and attribution.