rudof_lib

rudof_lib centralizes Rudof functionality for programmatic use. At a high level it supports:

• Loading and serializing RDF and PG data.
• Loading, checking, serializing and validating ShEx schemas.
• Loading, serializing and validating SHACL shapes.
• Loading, serializing and validating PGSchemas.
• Loading, running and serializing SPARQL queries and query results.
• Converting and comparing schemas between supported formats.
• Loading and serializing DCTAP and Service Descriptions.
• Generating synthetic data from schemas.

Primary goals:

• Provide a stable, ergonomic entry point (Rudof) that acts as a facade over specialized crates.
• Expose operations via builder-style (fluent) interfaces so integrations can compose and reuse behavior safely.
• Keep a clear separation between the public API, concrete implementations, and shared types/formats/errors.

Architecture and Package Structure

The package structure is organized to make the public API small and stable while keeping implementations modular and testable. Below is a more detailed description of the main files and folders, what to expect inside them and the conventions used by the crate.

• src/lib.rs: crate root and public re-exports (Rudof, RudofConfig, errors and formats).

• src/rudof.rs: the Rudof struct and the builder-returning API. This is the façade object: it holds the runtime state (loaded data, current schemas, etc.) and exposes domain-specific methods that return builders (e.g.load_shex_schema(), validate_shacl(), run_query()). The builders delegate to implementation functions located under src/api/*/implementations.

• src/rudof_config.rs: configuration handling and defaults (RudofConfig).

• src/api/: domain contracts (traits), builders and the bridge to implementations. Each domain (for example data, shex, shacl, query, conversion, etc.) contains three subparts:

  • builders/: the public builder types (*Builder) that callers instantiate via Rudof methods. Builders configure the operation and finally call an implementation function when executed.
  • implementations/: concrete operation code that performs the logic using Rudof and the configured inputs.
  • trait definition (in the domain module): describe the operations offered.

• src/errors/: domain-specific error types and the unified RudofError. Errors are defined per-domain and composed into a top-level error to provide predictable error handling for callers.

• src/formats/: enums for input/serialization formats.

• src/types/: shared domain types (for example Data, QueryResult, shex_statistics, and other cross-cutting structs).

• src/utils/: internal utility helpers.

• src/default_config.toml: embedded TOML configuration used by RudofConfig::new().

• Tests: unit tests are located in the implementations submodules (.../implementations/tests).

Main dependencies

The following dependencies provide the foundational building blocks that rudof_lib composes to deliver its functionality. By delegating specialized tasks to these well-defined components, the library maintains a clean architecture, promotes reuse, and ensures that each concern remains independently extensible.

• dctap
• rudof_iri
• prefixmap
• pgschema
• rdf_config
• rudof_generate
• rudof_rdf
• shacl_ast
• shacl_ir
• shacl_rdf
• shacl_validation
• shapes_comparator
• shapes_converter
• shex_ast
• shex_validation
• sparql_service