Promote Reuse
Registering a dataset is the beginning of its useful life. Ekayana makes registered data findable, verifiable, explicitly licensed, and safely shareable, so the outputs your institution publishes can be cited, checked, and built on.
Reuse is the return on research data
A dataset nobody can find, open, understand, or trust will not be reused, and the work that produced it stops paying off once the paper is out. The FAIR principles (Findable, Accessible, Interoperable, Reusable) describe what it takes to change that. Ekayana maps each principle onto platform infrastructure, so FAIR becomes a property of how data is registered. In Europe there is a harder version of the problem: sharing data while staying inside GDPR.
- Findable
- Every dataset gets a resolvable did:bio, anchored in the Solana registry and indexed in the knowledge graph. Records can be retrieved by identifier, by keyword, or by semantic query. See Enable Discovery.
- Accessible
- DID documents resolve through an open resolver over plain HTTP, and content sits on IPFS behind stable CIDs. Private data is reached with an explicit UCAN capability.
- Interoperable
- Metadata follows W3C DID core with a research profile and comes back as JSON from the REST API. Bridges to Dataverse and Zenodo keep existing DOIs working. See Integrate Workflows.
- Reusable
- A license field travels inside the DID document, content addressing fixes provenance, and BioAgents fill in the structured metadata a reuser needs.
What Ekayana provides
Reuse depends on trust: that the metadata is accurate, that the license is explicit, that the bytes are the ones the authors published, and that sharing something private will not cause trouble later. Each of those is a property of a did:bio registration.
Carried by the identifier
- Rich open metadata
- Titles, researchers and their roles, keywords, and related identifiers live in the DID document itself. BioAgents extract and enrich metadata from the underlying papers and datasets, so records stay descriptive without manual re-keying.
- Explicit licensing
- A license field (CC-BY-4.0 and other SPDX identifiers) is part of the DID metadata, so the terms of reuse travel with the identifier. Reusers do not have to guess what they are allowed to do.
- Provenance by content addressing
- Files are stored on IPFS under their CID: identical bytes always produce the same identifier. Anyone can recompute the CID and verify they hold the version that was registered. There are no separate checksums to publish.
- Citation that resolves
- Datasets are citable by their did:bio and resolve through the open resolver for as long as the registry exists. Datasets bridged from Dataverse or Zenodo keep their DOIs, so existing citations and workflows still work.
Added by the platform
- Controlled sharing with UCAN
- Sharing mints a capability token scoped to one resource, one recipient, and one set of actions, with a signed expiry. Consent can be withdrawn by revoking the token.
- Context in the knowledge graph
- Datasets, researchers, and institutions are connected in the knowledge graph, so a reuser can see where data came from, who produced it, and what it relates to before deciding to build on it.
How to make your data reusable
Two habits carry most of the weight: describe the dataset properly when you register it, and put the license in the metadata. Data that cannot be public adds a third step, delegation. The documentation covers each one in detail.
Describe it once, at registration
Register the dataset with a descriptive title, every researcher and their role, and the keywords a stranger would search for. That metadata lives in the DID document and feeds the knowledge graph; it is what makes the record findable later. BioAgents can extract most of it from the paper itself, and the owner reviews the result before it is published.
State the license in the metadata
Put a standard SPDX identifier in the license field: CC-BY-4.0 for attribution, CC0-1.0 for a public domain dedication. Without one, a careful reuser has to assume the data is off limits.
// Mint a did:bio identifier for a dataset
const res = await fetch('https://api.ekayana.com/api/did', {
method: 'POST',
headers: {
Authorization: `Bearer ${token}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({
controller: 'did:bio:devnet:2T6zLFvMx7NJ...',
public_key: 'z6MkfuN2vWAoHermh6vY6TgAJfwhBWZC...',
metadata: {
title: 'Coral bleaching survey 2026',
researchers: [{ name: 'Ada Lovelace', role: 'PI' }],
keywords: ['coral', 'bleaching'],
license: 'CC-BY-4.0', // reuse terms travel with the identifier
},
}),
});
const didDocument = await res.json();Share through delegation, not credentials
Not everything can be open on day one. Embargoes, consent constraints, and personal data are facts of research life. UCAN delegation lets you share anyway: each grant covers one resource, expires on a set date, and can be revoked, which is the shape GDPR compatible consent has to take. See UCAN Authorization for the full model.
Mint a capability
Name the CID, the recipient DID, the allowed actions (usually read), and an expiry. The platform signs a UCAN token scoped to exactly that grant.
Hand over the token
Send the token to your collaborator. The file stays where it is, pinned on IPFS, and nothing becomes public.
They redeem it
The recipient presents their own session together with the UCAN. The server verifies the signature and the proof chain before allowing the named action.
Revoke when you need to
Revocation takes effect on the next use of the token, and it cascades: everything delegated beneath a revoked grant fails with it.
# Grant a collaborator seven days of read access to one file
curl -X POST https://api.ekayana.com/api/share/file \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"cid": "QmXyz...",
"recipient_did": "did:bio:user:7",
"capabilities": ["read"],
"expiration_days": 7
}'
# -> { "token": "ucan.v1...", "token_hash": "3f9c...", ... }
# Keep token_hash: DELETE /api/share/revoke/{token_hash} revokes it.API key compared with UCAN capability
| Property | API key | UCAN capability |
|---|---|---|
| Scope | Whole account | One resource, listed actions |
| Lifetime | Valid until someone rotates it | Signed expiry, checked on every use |
| Delegation | Share the secret | Attenuated re-delegation, chain verified |
What reuse looks like
The same infrastructure serves the reviewer checking a result, the collaborator working under consent constraints, the citation that still has to resolve in ten years, and the repository that wants better provenance while keeping its DOIs.
A reviewer verifies the exact bytes. A peer reviewer downloads a dataset, recomputes its CID, and compares it with the registered identifier. A match confirms the file is the version the authors published.
A collaborator gets bounded access. A partner lab receives a seven day read capability on a single file. When the collaboration ends, or consent is withdrawn, the grant is revoked. The audit trail records who could reach what, and when.
A citation resolves years later. A paper cites a dataset by its did:bio, and resolution does not depend on any single server staying online.
A repository joins without migrating. An institutional repository connects through the Dataverse or Zenodo bridge. Its datasets keep their DOIs and gain content addressed provenance, richer metadata, and knowledge-graph context.
Building tools or repository integrations on top of this? Registered Service Providers connect their platforms to the founding network, and current members shape the roadmap through governance. Fees are published openly on the fees page.
Register a dataset others can build on
Mint a resolvable did:bio with an explicit license and verifiable provenance. Membership brings the same infrastructure to a whole institution.