SHARE 2.0

Live

The live scoring rubric that measures what is present when data are deposited. It replaces five popularity and attention outcomes with five practical signs that a deposited package is ready for another person to inspect and reuse.

SHARE 2.0 · Specification 2.0.0 · Validation 0.6.0

Published scores: SHARE 2.0 has passed a preregistered Zenodo association test and a four-repository implementation audit. The active score release applies the SHARE 2.0 rubric to its frozen evidence corpus and identifies its version and digest in every score response.

What changes

SHARE 1.0 includes views, downloads, citations, derivatives, and community attention in its R bucket. Those outcomes are shaped by time, field size, and visibility after deposit. SHARE 2.0 keeps the same 25-signal, five-bucket structure but replaces only R1–R5 with deposit-time evidence. S, H, A, and E keep their SHARE 1.0 meanings.

Views, downloads, citations, derivatives, and mentions are still reported. They are evidence about what happened after deposit, not points in the SHARE 2.0 score.

SHARE 1.0 and 2.0 compared

	SHARE 1.0	SHARE 2.0
R bucket	Reuse outcomes: views, downloads, citations, derivatives, and community attention	Reusability at deposit: documentation, code, manifests, transparent packaging, and filenames
What changes	Five outcome-based R signals	Only R1–R5 change; S, H, A, and E keep their 1.0 meanings
Outcome measures	Contribute to the displayed score	Reported separately and used as evidence, never as score inputs
Scoring math	25 signal IDs across five buckets	25 binary signals × 4 points; unsupported or non-evaluable = 0; denominator stays 25
Current status	Scored live on this site	Live rubric with versioned published scores

The 25 SHARE 2.0 signals

Each signal is worth four points. Unsupported or non-evaluable signals earn zero, and the denominator stays fixed at 25.

Stewardship

Is the dataset responsibly described in its research context?

Geographic Context

Geographic context is documented through geospatial coordinates, a named place, spatial terms, or geographic coverage.

Temporal Context

A collection period, study period, temporal range, or other temporal coverage beyond a bare publication date is documented.

Contributor Roles

A contributor role, contributor-type distinction, or named data steward is documented beyond a bare creator list.

Subject Classification

Subjects, keywords, tags, categories, recognized classification codes, or a discipline or topic are present.

Ethical Transparency

An ethics, consent, data-use, sensitive-data, or explicit no-approval-required statement is documented.

Harmonization

Can people and machines interpret the record consistently?

Methods Documentation

Methods or procedures are documented in a methods section, protocol, procedural README or wiki, methodology field, data dictionary, or codebook.

Contributor PID

At least one contributor has an ORCID, ISNI, or other recognized persistent person identifier.

Organization PID

At least one affiliation has a publicly resolvable organization identifier, directly or after deterministic entity resolution.

Bibliographic References

A references list, structured citation relationship, or bibliography is present.

Description Quality

A substantive, non-boilerplate abstract or description contains at least 100 meaningful characters after markup normalization.

Access

Can someone obtain the data and understand the reuse terms?

Open Access Status

A public or open flag, accessible data endpoint, explicit open-access field, or authoritative unrestricted-access repository policy proves open access.

License Clarity

An SPDX identifier, recognized license name or URL, or unambiguous rights statement deterministically identifies a data license.

License Permissiveness

The identified license is a recognized open-reuse license and is not restrictive, custom, missing, noncommercial, or no-derivatives.

No Embargo

The data are marked not embargoed or available now, or the embargo date is absent or in the past.

Format Openness

At least one actual data file uses an open or non-proprietary format, or a source-backed declaration identifies such a data format.

changed in 2.0

Reusability

Could a stranger inspect and work with the deposited package?

Documentation Artifact

A README, documentation file, docs folder, data dictionary, codebook, user guide, protocol file, or project wiki is present.

Analysis Code Shipped

A recognized source-code or notebook file, scripts or code folder, or linked code repository is present.

Package Manifest

A recognized dependency, environment, container, package, lock, build, or declared package manifest is present.

Transparent Packaging

Files are individually listed or archive members are browsable or extractable with visible contents rather than an opaque undocumented blob.

Meaningful Filenames

At least one human-readable descriptive filename has a basename of four or more characters and is not generic, hashed, UUID-like, or accession-only.

Engagement

Is the dataset connected to publications, data, funding, and standards?

Related Publication

A linked article DOI, publication relationship, or journal reference is present.

Related Data

A linked dataset, data relationship, or derivation or part-of relationship to another dataset is present.

Funding Information

A funder name, grant or award number, funding statement, or persistent funder identifier is present.

Version Tracking

A version field, versioned DOI series, revision history, or changelog is present.

Community Standard Compliance

A domain standard, repository-enforced standard, or source-backed standardized metadata profile is documented.

The new Reusability signals

All five decisions use depositor-visible filenames. Repository-generated MIME types, file sizes, checksums, and usage statistics do not earn points.

Documentation Artifact

Decision: A README, documentation file, docs folder, data dictionary, codebook, user guide, protocol file, or project wiki is present.

Why it matters: A README, codebook, or guide gives a new user an entry point into the deposit.

Analysis Code Shipped

Decision: A recognized source-code or notebook file, scripts or code folder, or linked code repository is present.

Why it matters: Shipping analysis code makes the work inspectable and easier to reproduce.

Package Manifest

Decision: A recognized dependency, environment, container, package, lock, build, or declared package manifest is present.

Why it matters: A package inventory records what belongs in the deposit and supports integrity checks.

Transparent Packaging

Decision: Files are individually listed or archive members are browsable or extractable with visible contents rather than an opaque undocumented blob.

Why it matters: At least one inspectable file prevents the whole deposit from being hidden in an opaque archive.

Meaningful Filenames

Decision: At least one human-readable descriptive filename has a basename of four or more characters and is not generic, hashed, UUID-like, or accession-only.

Why it matters: Descriptive filenames let a user navigate the package without guessing what every file contains.

What the evidence shows

Preregistered association: PASS

2.36× odds per 10 points

Across 154,569 Zenodo datasets, a 10-point higher SHARE 2.0 score was associated with 2.36 times the odds of a verified derivative within three years (95% CI 1.419–3.915, p=0.00093).

Important comparison

The new R bucket did not improve AUC

SHARE 2.0 AUC was 0.7381; the 20-signal deposit-time comparator was 0.7947. The result supports a leakage-free score and a positive association, not a claim that each replacement R signal adds predictive value.

Can repositories measure the same five decisions?

A preregistered, outcome-blind audit used public file manifests only.

Repository	Usable public file manifests	Portability gate
Zenodo	99/100	PASS
Dryad	97/100	PASS
Figshare	93/100	PASS
Harvard Dataverse	100/100	PASS

What remains unresolved

The full-cohort result is a retrospective association. It does not show that raising a score causes reuse.
The five replacement R signals remove outcome leakage, but they did not improve AUC over the 20 deposit-time signals alone.
Portability shows that four repository APIs expose the same file-manifest decisions. It is not cross-repository predictive validation.
Repository support ceilings and record-level scores remain separate evidence products.
SHARE 1.0 remains available as a legacy framework for comparison.

Observed reuse stays visible

These outcomes remain useful for research and reporting, but none contributes points to a SHARE 2.0 score.

views: reported, not scored

downloads: reported, not scored

citations: reported, not scored

derivatives: reported, not scored

mentions: reported, not scored

How to identify this release

Public pages identify this as SHARE 2.0. API release receipts keep the immutable scoring-contract identity so issued score responses remain reproducible.

Semantic contract SHA-256

18a7ad85ce8e31cee4d5a9d1b8149bb3a41eea6c82e60eb3cf9cc5a0cd156779

Open implementation work

The Foundation repositories publish the versioned rubric, reference scorer, and repository pledge format.

SHARE Framework Reference implementation Repository pledges

SHARE 1.0 remains available

Browse today's scored datasets with their current rubric, or review the live signal definitions.

SHARE 1.0 signals Browse SHARE 2 scores

SHARE 2.0

Live

SHARE 2.0 · Specification 2.0.0 · Validation 0.6.0

What changes

Views, downloads, citations, derivatives, and mentions are still reported. They are evidence about what happened after deposit, not points in the SHARE 2.0 score.

SHARE 1.0 and 2.0 compared

	SHARE 1.0	SHARE 2.0
R bucket	Reuse outcomes: views, downloads, citations, derivatives, and community attention	Reusability at deposit: documentation, code, manifests, transparent packaging, and filenames
What changes	Five outcome-based R signals	Only R1–R5 change; S, H, A, and E keep their 1.0 meanings
Outcome measures	Contribute to the displayed score	Reported separately and used as evidence, never as score inputs
Scoring math	25 signal IDs across five buckets	25 binary signals × 4 points; unsupported or non-evaluable = 0; denominator stays 25
Current status	Scored live on this site	Live rubric with versioned published scores

The 25 SHARE 2.0 signals

Each signal is worth four points. Unsupported or non-evaluable signals earn zero, and the denominator stays fixed at 25.

Stewardship

Is the dataset responsibly described in its research context?

Geographic Context

Geographic context is documented through geospatial coordinates, a named place, spatial terms, or geographic coverage.

Temporal Context

A collection period, study period, temporal range, or other temporal coverage beyond a bare publication date is documented.

Contributor Roles

A contributor role, contributor-type distinction, or named data steward is documented beyond a bare creator list.

Subject Classification

Subjects, keywords, tags, categories, recognized classification codes, or a discipline or topic are present.

Ethical Transparency

An ethics, consent, data-use, sensitive-data, or explicit no-approval-required statement is documented.

Harmonization

Can people and machines interpret the record consistently?

Methods Documentation

Methods or procedures are documented in a methods section, protocol, procedural README or wiki, methodology field, data dictionary, or codebook.

Contributor PID

At least one contributor has an ORCID, ISNI, or other recognized persistent person identifier.

Organization PID

At least one affiliation has a publicly resolvable organization identifier, directly or after deterministic entity resolution.

Bibliographic References

A references list, structured citation relationship, or bibliography is present.

Description Quality

A substantive, non-boilerplate abstract or description contains at least 100 meaningful characters after markup normalization.

Access

Can someone obtain the data and understand the reuse terms?

Open Access Status

A public or open flag, accessible data endpoint, explicit open-access field, or authoritative unrestricted-access repository policy proves open access.

License Clarity

An SPDX identifier, recognized license name or URL, or unambiguous rights statement deterministically identifies a data license.

License Permissiveness

The identified license is a recognized open-reuse license and is not restrictive, custom, missing, noncommercial, or no-derivatives.

No Embargo

The data are marked not embargoed or available now, or the embargo date is absent or in the past.

Format Openness

At least one actual data file uses an open or non-proprietary format, or a source-backed declaration identifies such a data format.

changed in 2.0

Reusability

Could a stranger inspect and work with the deposited package?

Documentation Artifact

A README, documentation file, docs folder, data dictionary, codebook, user guide, protocol file, or project wiki is present.

Analysis Code Shipped

A recognized source-code or notebook file, scripts or code folder, or linked code repository is present.

Package Manifest

A recognized dependency, environment, container, package, lock, build, or declared package manifest is present.

Transparent Packaging

Files are individually listed or archive members are browsable or extractable with visible contents rather than an opaque undocumented blob.

Meaningful Filenames

At least one human-readable descriptive filename has a basename of four or more characters and is not generic, hashed, UUID-like, or accession-only.

Engagement

Is the dataset connected to publications, data, funding, and standards?

Related Publication

A linked article DOI, publication relationship, or journal reference is present.

Related Data

A linked dataset, data relationship, or derivation or part-of relationship to another dataset is present.

Funding Information

A funder name, grant or award number, funding statement, or persistent funder identifier is present.

Version Tracking

A version field, versioned DOI series, revision history, or changelog is present.

Community Standard Compliance

A domain standard, repository-enforced standard, or source-backed standardized metadata profile is documented.

The new Reusability signals

All five decisions use depositor-visible filenames. Repository-generated MIME types, file sizes, checksums, and usage statistics do not earn points.

Documentation Artifact

Decision: A README, documentation file, docs folder, data dictionary, codebook, user guide, protocol file, or project wiki is present.

Why it matters: A README, codebook, or guide gives a new user an entry point into the deposit.

Analysis Code Shipped

Decision: A recognized source-code or notebook file, scripts or code folder, or linked code repository is present.

Why it matters: Shipping analysis code makes the work inspectable and easier to reproduce.

Package Manifest

Decision: A recognized dependency, environment, container, package, lock, build, or declared package manifest is present.

Why it matters: A package inventory records what belongs in the deposit and supports integrity checks.

Transparent Packaging

Decision: Files are individually listed or archive members are browsable or extractable with visible contents rather than an opaque undocumented blob.

Why it matters: At least one inspectable file prevents the whole deposit from being hidden in an opaque archive.

Meaningful Filenames

Decision: At least one human-readable descriptive filename has a basename of four or more characters and is not generic, hashed, UUID-like, or accession-only.

Why it matters: Descriptive filenames let a user navigate the package without guessing what every file contains.

What the evidence shows

Preregistered association: PASS

2.36× odds per 10 points

Across 154,569 Zenodo datasets, a 10-point higher SHARE 2.0 score was associated with 2.36 times the odds of a verified derivative within three years (95% CI 1.419–3.915, p=0.00093).

Important comparison

The new R bucket did not improve AUC

Can repositories measure the same five decisions?

A preregistered, outcome-blind audit used public file manifests only.

Repository	Usable public file manifests	Portability gate
Zenodo	99/100	PASS
Dryad	97/100	PASS
Figshare	93/100	PASS
Harvard Dataverse	100/100	PASS

What remains unresolved

The full-cohort result is a retrospective association. It does not show that raising a score causes reuse.
The five replacement R signals remove outcome leakage, but they did not improve AUC over the 20 deposit-time signals alone.
Portability shows that four repository APIs expose the same file-manifest decisions. It is not cross-repository predictive validation.
Repository support ceilings and record-level scores remain separate evidence products.
SHARE 1.0 remains available as a legacy framework for comparison.

Observed reuse stays visible

These outcomes remain useful for research and reporting, but none contributes points to a SHARE 2.0 score.

views: reported, not scored

downloads: reported, not scored

citations: reported, not scored

derivatives: reported, not scored

mentions: reported, not scored

How to identify this release

Public pages identify this as SHARE 2.0. API release receipts keep the immutable scoring-contract identity so issued score responses remain reproducible.

Semantic contract SHA-256

18a7ad85ce8e31cee4d5a9d1b8149bb3a41eea6c82e60eb3cf9cc5a0cd156779

Open implementation work

The Foundation repositories publish the versioned rubric, reference scorer, and repository pledge format.

SHARE Framework Reference implementation Repository pledges

SHARE 1.0 remains available

Browse today's scored datasets with their current rubric, or review the live signal definitions.

SHARE 1.0 signals Browse SHARE 2 scores