Services & Use Cases

Enable Discovery

Ekayana connects every registered did:bio into a knowledge graph that can be searched, queried, and traced back to the record a fact came from. The graph indexes metadata and relationships; the data itself stays content addressed on IPFS, under your institutional control.

Why?

Discovery depends on the connections around a record

An identifier makes a dataset citable. What makes it findable is the metadata linking it to people, institutions, concepts, and other outputs.

A dataset behind a registered did:bio is persistent and verifiable. That is not the same as being findable. If nothing records who produced it, what it covers, and what builds on it, the identifier only works for people who already have the reference, and work nobody finds is rarely cited or reused.

Most discovery platforms answer this by centralizing the data itself. Ekayana indexes metadata and relationships instead, while the underlying files stay content addressed on IPFS and pinned where your institution decides. An institution can open its catalog for discovery and still hold custody of the data behind it, which is what European data sovereignty and GDPR obligations require.

The graph is new. It holds what has been registered and what BioAgents has extracted from those deposits, so for a new institution it starts close to empty and fills as records arrive.

What?

The pieces of the discovery layer

A graph that holds the connections, query interfaces over it, a public resolver that makes every identifier actionable, and reporting for members on how their records are used.

The Ekayana knowledge graph

RDF triples and JSON-LD

Datasets, researchers, institutions, and concepts are held in a single graph. Every fact keeps a link back to the did:bio and the source record it was extracted from, so any result can be traced to its origin. How the graph is built

Semantic search and natural language queries

Console, SPARQL, REST

Search from the Ekayana Console, or write graph patterns directly against the SPARQL endpoint. BioAgents also translates plain-English questions into graph queries, so a question can be asked without learning a query language. About BioAgents

Public resolver and gateways

No account required

Every did:bio is dereferenceable by anyone, with no account and no fee. Resolution reads the Solana registry, and IPFS gateways serve the content addressed data the identifier points to. Resolver internals

Citation and usage reports

Member benefit

Members receive knowledge-graph insights and citation and usage reports for their registered outputs, which is the evidence funders, assessments, and repository planning tend to ask for. Member benefits

How?

From registration to query

The graph is populated by ordinary use of the platform. There is no harvesting pipeline to build and no second metadata form to fill in.

  1. Metadata enters the graph at registration

    When you register a did:bio, its metadata record, DID document, and Solana registry anchor are created together, and the record enters the knowledge graph in the same step. There is no separate deposit and no metadata to key in twice.

  2. BioAgents adds entities and relationships

    BioAgents reads deposited papers and datasets, extracts entities and the relationships between them, and writes them into the graph as provenance tracked triples. The data owner reviews every extracted record before it is published.

  3. Query it from the Console, SPARQL, or the API

    Once a record is in the graph, all three interfaces reach it. Results dereference the whole way down: from an answer to a did:bio, and from the did:bio to the data itself on IPFS. Querying guide

Shell: public resolution
# Resolve any did:bio. Public, no account or token required.
curl https://api.ekayana.com/api/did/resolve/did:bio:devnet:2T6zLFvMx7NJ...

# Returns the DID document: verification methods, service endpoints,
# and the metadata record behind the identifier.
JavaScript: natural language query
// Ask the knowledge graph a question in plain English
const res = await fetch('https://api.ekayana.com/api/bioagents/query', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${token}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    query:
      'Which datasets link coral bleaching to ocean temperature anomalies?',
  }),
});

const answer = await res.json();
// Each result carries the did:bio and the source record it came from.
Interfaces

Where the graph can be queried

Public resolution is open to everyone, member or not. The query interfaces need an account, and reporting is a member benefit.

Semantic search
Search the Ekayana Console across the records held in the graph rather than one repository at a time.
Relationship queries
SPARQL patterns traverse the links between records: from a concept to the datasets annotated with it, to the researchers and institutions attached to those datasets, and back to the source each fact came from.
Natural language queries
POST /api/bioagents/query takes a question as JSON. BioAgents translates it into a graph query and returns results with the did:bio and source behind each one. Requires an API token.
Public resolution
GET /api/did/resolve/{id} returns the DID document and metadata record for any did:bio. No account, no token, no fee.
Citation and usage reports (members)
Members see how their identifiers resolve and how their outputs are reused, including datasets that keep their DOIs through the Dataverse and Zenodo bridges.

Datasets bridged from Dataverse or Zenodo keep their DOIs, and the graph links the DOI and did:bio records together so a query covers both. See Integrate Workflows and the Dataverse integration docs.

Keep exploring

Where discovery fits

Discovery is one of six services that share the same stack. Browse all services or review membership fees.

Read how the graph is built

The knowledge graph documentation covers the triple store, JSON-LD, and the SPARQL endpoint. Registration is what puts records into the graph in the first place.