Import & Export RDF Ontologies

Scrydon can validate an RDF/Turtle (OWL/RDFS) schema, place the resulting declarations in a review branch, and export either a published ontology or a branch overlay back to deterministic Turtle. Import never publishes or changes the main ontology automatically.

Import

1. Select the target ontology identifier and provide Turtle text (or a .ttl, .rdf, or .owl file through a client that reads it as text).
2. Validate with client.rdf.import({ ontology, rdf, dryRun: true }). Validation reports object types, link types, properties, aliases, and bounded warnings, and performs no writes.
3. Import with client.rdf.import({ ontology, rdf }). The response includes the new draft branchId.
4. Review the branch through client.branches or any schema read that accepts { branch }, then submit and publish it explicitly when it is ready.

Retrying the same content as the same actor replays the same branch and completed declaration chunks. A failed later chunk leaves a draft that the same request can safely resume.

What gets imported

Individuals (instance data) — e.g. ex:Alice a ex:Person — are not imported. Only the schema (classes and properties) is created. The validation preview reports how many individuals were ignored.

If a datatype property's domain does not resolve to a declared class, it is skipped and listed as a warning. Blank-node schema declarations and object properties with unsupported multi-endpoint domains or ranges fail closed instead of being flattened.

Input is limited to 5 MiB of UTF-8 text, 50,000 RDF quads, 100 warnings, and 10,000 compiled declarations. Each declaration chunk must also fit the kernel action-input limits. All limits are checked before the draft branch is created.

Export

Use client.rdf.export({ ontology }) for the current published view, client.rdf.export({ ontology, revisionId }) for a pinned revision, or client.rdf.export({ ontology, branch }) for a review overlay. revisionId and branch are mutually exclusive. Object types export as owl:Class, properties as owl:DatatypeProperty, link types as owl:ObjectProperty, and aliases as SKOS or named Scrydon alias resources. Output is deterministic and limited to 5 MiB.

Knowledge-base taxonomies (SKOS)

Taxonomies live in the scrydon-knowledge-taxonomies ontology and use SKOS rather than OWL. client.rdf.import refuses that ontology; use the taxonomy routes instead.

Export. client.rdf.export({ ontology: "scrydon-knowledge-taxonomies" }) adds, to the Turtle above, each taxonomy you can see as a skos:ConceptScheme, each kind as a skos:Concept (skos:inScheme its scheme, skos:broader its parent kind, skos:definition), and each term as a skos:Concept typed scrydon:TaxonomyTerm whose skos:broader is its kind, with skos:altLabel and skos:hiddenLabel for its variants. Only what your clearance allows is exported: a term of a taxonomy you cannot see is left out, and a term whose kind you cannot see has no skos:broader. Terms are exported as they are now, even for a pinned revisionId.

Import. An organization admin can import a SKOS concept scheme as a taxonomy:

const result = await client.taxonomies.import({
  name: "glossary",
  rdf: turtle, // a skos:ConceptScheme with its skos:Concept members
  marking: { schemeId: "default", rank: 0 }, // applies to the whole import
  idempotencyKey: crypto.randomUUID(),
});
// result: { revision, branchId, concepts, terms, warnings }

The scheme named like name is imported, or the only scheme in the file. Its concepts become the taxonomy's kinds; concepts typed scrydon:TaxonomyTerm become terms. The taxonomy is published at once with source: "imported", and re-importing replaces it: kinds the file no longer declares are retracted. You cannot import over a taxonomy that was not imported (409, TAXONOMY_NOT_IMPORTED), or use a name starting with kb- (400, TAXONOMY_NAME_RESERVED), and the marking may not exceed your clearance. Retrying with the same idempotencyKey returns the same result. Terms the file no longer lists are not removed by a re-import.