6.1 Logical models and physical systems
Knowledge storage has several layers. The logical model describes entities, relationships, and semantics. The physical database determines how records are indexed, traversed, and updated. An application interface decides which operations users or agents can perform. These layers need not map one to one. A graph can combine a document repository, relational metadata, a graph database, and a vector index while presenting a coherent knowledge interface.
RDF stores organize triples or quads and commonly expose SPARQL. Labeled property graphs（标签属性图）represent nodes and relationships with labels or types and attached properties. The choice affects how qualifiers, identifiers, and query patterns are expressed. A property graph can make relationship attributes convenient for application development. RDF can make shared vocabularies and standardized interchange convenient. Neither choice automatically ensures better performance, easier reasoning, or higher data quality. Those outcomes depend on workload, implementation, and governance.
The Research Evidence Graph uses an explicit Claim node even in a property graph because claims have their own provenance, review status, and lifecycle. This makes the model easier to translate between storage technologies. A simpler application might store an edge directly when the assertion is uncomplicated and rarely needs independent metadata. The design decision should follow the information's lifecycle rather than a preference for either maximum normalization or minimum node count.
| Aspect | RDF | Labeled property graph |
|---|---|---|
| Core structure | Triples or quads with IRIs and literals | Nodes and typed relationships with properties |
| Query language | SPARQL | Implementation specific; Cypher is one example |
| Semantics | Can use standardized entailment regimes | Usually application defined; explicit rules can be added |
| Qualification | Named graphs or explicit assertion and event patterns | Relationship properties or explicit assertion and event nodes |
| Design test | Preserve identity, context, provenance, and required query meaning | The same semantic test applies |
A hybrid architecture separates graph structure, retrieval indexes, and source documents while sharing identifiers and policy.
Original figures retain bilingual labels. Read alongside the explanation; open for a larger view.6.2 Query meaning and workload
SPARQL supports graph pattern matching, filtering, aggregation, optional patterns, and other operations over RDF data [9]. A SPARQL query can ask for papers connected to a method through evaluations and then filter by dataset. The query's answer depends on the dataset and any configured entailment regime. Standardization provides a shared language, but applications still need to define named graph usage, identity conventions, and whether inferred statements are included.
Cypher expresses property graph patterns through nodes and directed relationships. Its MATCH clause selects data matching a pattern, and subsequent clauses can filter or transform results [46]. In the proposed local implementation, an evidence retrieval query follows Method to Evaluation to Claim to SourceSpan. The path is deliberately bounded and typed. This makes the intended connection clear and limits expansion. An unrestricted traversal across every relationship can return a large but semantically incoherent neighborhood.
Query design should begin with selectivity. An exact method identifier or document key is usually a better starting point than scanning every node. Indexes accelerate suitable lookups, but their benefit depends on the query planner and data distribution. A common operational mistake is to create many indexes without measuring representative queries. The appropriate evidence is a query plan and observed latency on the actual workload, including realistic data sizes and concurrent users.
6.3 Hybrid storage and source authority
A document store preserves raw and parsed source material. A graph store preserves explicit relationships and identity. A full text index supports lexical matching. A vector index supports similarity retrieval over text or other representations. A relational or analytical store may hold large numeric tables and experiment metrics. Each system contributes a different access pattern. The application should identify which representation is authoritative for each kind of information and how derived copies are refreshed.
For example, the source repository is authoritative for the text of a paper version. The graph is authoritative for the accepted mapping between that version and its extracted claims. The vector index is a derived retrieval aid. If an embedding is stale, the system should regenerate it from the authoritative text; it should not treat the old vector as an independent record of truth. Stable identifiers and version tags are the links that make this separation manageable.
Hybrid retrieval can combine exact entity matching, lexical search, and vector similarity before expanding through graph relations. The order should depend on the question. A query containing a verified DOI can begin with exact identity. A vague conceptual question may begin with text similarity and then resolve candidate entities. The system can retain the retrieval route so that later evaluation shows whether an error came from initial retrieval, linking, graph expansion, or answer generation.
6.4 Transactions consistency and concurrency
A transaction groups related changes so that they succeed or fail together under the database's supported guarantees. Ingestion can create an Evaluation, connect its arguments, and attach its provenance in one transaction. If only part of that operation succeeds, the graph may contain an orphan record that looks valid to a simple query. Validation should therefore include structural integrity, while transactions protect the process that establishes that integrity.
Concurrent writers create additional challenges. Two extraction workers may attempt to create the same canonical entity. A uniqueness constraint on a stable key can prevent duplication, but the application must handle the conflict correctly and retry when appropriate. A generated title is not a reliable key. Nor should workers merge arbitrary records merely to avoid a conflict. The identity policy and the concurrency policy must agree about which records are allowed to collapse.
Distributed representations may update at different times. A graph transaction can complete before the search index has refreshed. The application should define whether temporary inconsistency is acceptable and how users can recognize it. A versioned retrieval request can require matching source and index versions for high assurance tasks. A casual exploration interface might accept a short delay. The important point is to make the consistency requirement explicit instead of assuming that every component changes simultaneously.
6.5 Scale and partitioning
Graph workloads are sensitive to topology. A small number of high degree nodes can dominate traversal cost, while a large graph with selective bounded queries can remain manageable. Partitioning by department or geography may reduce storage and access scope, but relationships crossing partitions can become expensive. Replication can improve read availability while increasing the work required to maintain consistent updates. These tradeoffs should be tested with the actual relationship patterns rather than inferred from total node count alone.
Analytical computation often uses a projection（图投影）of the operational graph. A citation analysis might select only Paper nodes and CITES relationships. A collaboration analysis might derive an undirected graph of coauthors. Each projection changes the meaning of edges and may discard qualifiers. Its definition, source snapshot, and weighting rules should be stored with the result. Otherwise, two centrality scores with the same name can be mistakenly compared even though they were calculated on different graphs.
Large text, images, and binary files generally belong in an appropriate object or document store with graph references, rather than being duplicated in every connected node. This design keeps traversal focused on structure while preserving access to evidence. It also simplifies retention and versioning. The graph should store enough metadata to locate and authenticate the source, including a content hash when exact reproducibility matters.
6.6 Security backup and portability
Access control must apply to both records and derived views. A user who cannot access a confidential experiment should not receive a summary that reveals its result through an unrestricted graph neighborhood. Filtering only the final answer is too late if restricted information has already influenced retrieval or generation. The proposed architecture checks access during candidate retrieval, traversal, and evidence assembly. It also records which policy version governed the request.
Backup quality is demonstrated by restoration. A useful recovery exercise restores the graph, source references, schema, and indexes sufficiently to answer representative questions. Exporting triples or nodes alone may omit identity rules, procedures, or embeddings required by the application. Portability therefore includes both data and interpretation. An exchange package should document identifiers, relationship meanings, datatypes, provenance fields, and version assumptions.
Storage architecture is successful when it preserves meaning while meeting operational requirements. Fast traversal is useful, but an evidence graph also needs correct identity, coherent snapshots, recoverable updates, and understandable access rules. These properties make the stored knowledge dependable enough for the computations and agents discussed in the following chapters.