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 curated paper records loaded from JSON-LD, not records extracted from deposits, so its coverage grows as curated sources are added.

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

Published papers, their authors, and their subject concepts are held in a SPARQL triple store as JSON-LD, one named graph per DOI. Records are loaded from curated sources, so every result traces to a DOI. How the graph is built

Semantic search and natural language queries

Console, REST

Search from the Ekayana Console, or call the typed knowledge graph routes by concept, author, or DOI. BioAgents also plans searches from plain-English questions, 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 is public at registration

    When you register a did:bio, its metadata record, DID document, and Solana registry anchor are created together, and the record resolves publicly from then on. A registered paper is also indexed into the BioAgents knowledge base, and a DOI lets its record be enriched from the knowledge graph.

  2. BioAgents answers questions over it

    BioAgents plans searches against the graph, combines the results with the knowledge base of registered papers, and writes a synthesis that cites the papers it found. Registering a paper with a DOI also fills empty fields of its record from the graph.

  3. Query it from the Console or the API

    Once a record is in the graph, both interfaces reach it. A registered paper links its DOI to a did:bio, and the did:bio to its sealed file on IPFS. Querying guide

Shell: public resolution
# Resolve any did:bio. Public, no account or token required.
curl https://api.ekayana.io/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.io/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
Typed routes find papers by concept, by author narrowed by concept, or by DOI. The plugin builds each SPARQL query from those inputs; the API does not expose a raw SPARQL endpoint.
Natural language queries
POST /api/bioagents/query takes a question as JSON and returns an answer with the DOIs it cited. POST /api/bioagents/kg/ask returns the synthesis, the papers, and the search plan. Both require a session 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 bridge.

Datasets bridged from Dataverse keep their DOIs, and the did:bio record carries the DOI so discovery works from either identifier. 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 typed query routes. Curated records are what the graph is loaded from.