Files, Graphs, And Ontologies

ShrikeDB can work with raw application records, graph relationships, RDF-like triples, and ontology files. The right ingestion path depends on whether you need the data copied into ShrikeDB storage or queried where it sits.

Graph And KV Writes

Use graph edges for relationships and provenance. Use KV for payloads that are too large or too document-shaped for graph properties. Use vector indexes for embeddings.

entity UID
  -> graph edges for relationships
  -> KV payload for record body
  -> vector entries for semantic or image similarity

Keeping the same UID across these modalities makes later multimodal queries straightforward.

See Load Data for complete public API requests.

CSV And TSV

For CSV/TSV, begin with a small sample:

  • verify headers;

  • check delimiter and encoding;

  • identify stable IDs;

  • identify relationship columns;

  • check null and dirty-key rates;

  • decide which columns become graph concepts versus payload fields.

Follow Import a dataset for a runnable inspection and upload example.

If the goal is semantic chat, do not stop at loading rows. Import or build a profile that tells ShrikeDB how users will ask about those rows.

RDF And Turtle

RDF-like sources can be loaded as triples. After loading, smoke-test with a small SPARQL query:

SELECT ?s ?p ?o WHERE {
  ?s ?p ?o .
}
LIMIT 10

Use this to confirm whether predicates are compact names, full IRIs, or dataset-specific URNs.

OWL And Ontology Imports

Ontology imports help semantic plans reason over classes, subclasses, and mapped concepts. Use ontology grounding when questions need meaning beyond direct edge names.

Examples:

  • mapping cyber signals to D3FEND techniques;

  • checking whether a class is a descendant of an allowed root;

  • explaining why a result matches an ontology-grounded family.

Ontology import is not the same as blindly applying an ontology to every database. Load ontology context into the database/profile where it belongs.

Validation Checklist

Before handing a dataset to users:

  • row or triple counts match source expectations;

  • representative semantic lakehouse queries return the expected source rows;

  • profile-backed semantic questions compile and execute;

  • unsupported questions return boundaries instead of invented answers;

  • identifiers, types, units, and relationship direction match the intended application model.