Examples
Worked examples
- Is an instance
The title, authors with ORCID iDs, affiliations with ROR IDs, references, and funder/award data deposited with a Crossref DOI.
- Is an instance
The DataCite landing-page URL, creators, contributors, related identifiers, and rights statement on a DataCite DOI.
Counter-examples
Looks similar, but isn't
- Not an instance
A landing-page HTML title tag is not PID metadata until it is registered with the PID provider.
- Not an instance
Tags added to a paper in a personal reference manager are not PID metadata.
- Not an instance
The bare identifier string itself, with no accompanying registered record, is not PID metadata — metadata is the descriptive record attached to it.
Editorial commentary
Every PID scheme defines a metadata schema that registrants must populate. Crossref uses its own schema (with mandatory and optional fields per content type). DataCite uses the DataCite Metadata Schema (current version 4.x). ORCID uses an XML/JSON record schema. The richer and more accurate the PID metadata, the more useful the identifier is for downstream discovery and graph-building. PID metadata is the substrate of the PID graph.
Mandatory vs. optional, and why the split matters
The DataCite Metadata Schema, for example, defines a small set of mandatory properties — Identifier, Creator, Title, Publisher, PublicationYear, and ResourceType — without which a DataCite DOI cannot be minted at all, alongside a much larger set of recommended and optional properties (Contributor, Description, Subject, RelatedIdentifier, Rights, GeoLocation, and more) that a registrant can choose to populate. A DOI minted with only the mandatory minimum resolves and citations still work, but it is essentially invisible to relationship-based discovery — it can’t appear in a PID graph traversal for “funded by X” or “related to Y” if that relationship was never recorded.
“Thin” vs. “rich” metadata in practice
A thin record typically has title, creators, and a resolvable URL, but omits funder/award information, affiliation identifiers (ROR), contributor ORCID iDs, and related-identifier links to other outputs from the same project. A rich record populates all of these, which is what makes a persistent identifier genuinely FAIR-enabling (Findable and Interoperable, per the FAIR principles) rather than merely resolvable — the persistence of the identifier and the richness of its metadata are separate properties, and a PID can be perfectly persistent while still being metadata-thin.
References
- DataCite Metadata Working Group, ‘DataCite Metadata Schema 4.x’ (schema.datacite.org).
- Crossref, ‘Schema library’ (data.crossref.org/reports/help/schema_doc/index.html).
Also known as
Identifier metadata
Machine-readable encodings
Use in your systems
<role vocab="credit"
vocab-identifier="https://casrai.org/dictionary/"
vocab-term="PID metadata"
vocab-term-identifier="https://casrai.org/dictionary/term/pid-metadata" />{
"@context": "https://schema.org",
"@type": "DefinedTerm",
"@id": "https://casrai.org/dictionary/term/pid-metadata",
"name": "PID metadata",
"identifier": "https://casrai.org/dictionary/term/pid-metadata",
"description": "The descriptive metadata registered with a PID provider at the time of identifier minting, and updated thereafter, that describes the identified entity — its title, creators, dates, types, related identifiers, and so on — and that is exposed by the provider's APIs alongside the identifier itself.",
"inDefinedTermSet": "https://casrai.org/dictionary/domain/persistent-identifiers#set",
"url": "https://casrai.org/dictionary/term/pid-metadata",
"sameAs": [
"Identifier metadata"
],
"license": "https://creativecommons.org/licenses/by/4.0/",
"publisher": {
"@id": "https://casrai.org/#organization"
},
"author": {
"@id": "https://casrai.org/#editorial-team"
},
"datePublished": "2026-05-21T02:11:57",
"dateModified": "2026-08-22T15:38:23",
"inLanguage": "en-GB",
"isAccessibleForFree": true
}
