2.1 Begin with questions and decisions
Schema design starts with the questions a system must answer and the decisions those answers support. A competency question（能力问题）is a concrete test of what the model should express. For the Research Evidence Graph, one question is: “Which studies support the claim that Method M improves retrieval quality on Dataset D, and under what conditions?” Another is: “Which conclusions depend on a paper that has been corrected?” These questions require sources, claims, evaluations, versions, and dependency links. They immediately reveal why a graph containing only Paper, Author, and Topic nodes would be insufficient.
A useful design workshop takes several real questions and writes the evidence path needed for each answer. The team then identifies the minimum concepts required to express those paths. This process avoids two common errors: importing an enormous ontology before understanding the task, and drawing a convenient schema that cannot answer the important questions. Questions should include exceptions. The model must express a withdrawn claim, an unknown author identity, an experiment with multiple datasets, and a result whose numerical score is unavailable.
Different stakeholders may need different views of the same graph. A librarian cares about bibliographic identity; a researcher cares about experimental comparability; an administrator cares about access and ownership. The shared core should contain stable concepts on which they can agree. Specialized views can extend that core without forcing every user to adopt every detail. A schema is most maintainable when it separates common identity commitments from application specific presentation choices.
2.2 Choose the correct unit of representation
Modeling granularity（建模粒度）determines what receives an identity. A research project, a paper, a particular edition of that paper, and a paragraph in that edition are different objects. If a correction changes a paragraph, a graph that identifies only the paper cannot precisely locate the change. If every character receives a permanent node, maintenance may become unnecessarily expensive. The appropriate granularity follows the retrieval and audit requirements. A paragraph can often be stored as a source anchored span without becoming a heavily connected domain entity.
A useful rule is to create a node when an object needs independent identity, relationships, lifecycle, or provenance. Use a property（属性）when a value is naturally attached to one object and does not need independent connections. A publication date can usually be a property. An organization should usually be an entity because authors, projects, contracts, and events may refer to it. A research method may initially be a text property, but repeated questions about versions, families, and evaluations can justify promoting it to a node.
Events（事件）and qualified relations deserve particular care. “Person A worked for Organization B” is a relation that may change over time. Representing an Employment event or association with start and end dates can preserve multiple appointments and conflicting records. In the research example, an Evaluation plays a similar role. It connects several participants and conditions that belong together. A binary edge with many attributes may suffice in a property graph, while an explicit event node can make those attributes independently linkable and easier to exchange across models.
A minimum evidence schema. An Evaluation connects methods and dataset versions; Claims retain source evidence. Relationship names illustrate the proposed design.
Original figures retain bilingual labels. Read alongside the explanation; open for a larger view.2.3 Identity before labels
An identifier（标识符）should remain stable when a display name changes. A paper title is a poor primary key because titles can contain punctuation differences, corrections, translations, or duplicate wording. A DOI is useful when it exists and has been verified, but a system also needs a local identifier for documents without one. Local identifiers should not pretend to be global identifiers. Keeping the namespace explicit makes later reconciliation easier.
Identity policies must specify both merge and split behavior. A merge means that records previously treated separately are now considered to denote the same entity. A split reverses an erroneous merge. If downstream edges are copied without recording their original source, splitting becomes difficult. The Research Evidence Graph keeps mention level provenance and a versioned mapping from mentions to canonical entities. This allows a correction to revise identity links without deleting the underlying documents or losing the history of the mistake.
Names should support multilingual use. An English preferred label, a Chinese preferred label, abbreviations, and historical aliases can all refer to one concept. SKOS provides a standardized vocabulary for concept schemes and labels, including broader and narrower relationships [11]. A practical application can reuse these distinctions even when its storage is a property graph. It should still decide whether two labels are translations of one concept or names for related but distinct concepts. Translation similarity alone does not establish conceptual equivalence.
2.4 Formal semantics and operational validation
RDF Schema offers classes, subclass relationships, and domain and range descriptions [6]. A subtle point is that domain and range declarations support inference about types. They are not equivalent to a database check that rejects every unexpected value. If a property has Person as its domain and a statement uses that property with an unknown subject, an RDFS reasoner can infer that the subject is a Person. A team expecting automatic rejection may therefore obtain behavior different from its operational intention.
OWL adds constructs for richer logical descriptions, including class restrictions and property characteristics. It does not assume that differently named individuals are necessarily different, and many conclusions depend on whether explicit inequality has been asserted [7]. For implementation planning, OWL profiles provide restricted language fragments aimed at different reasoning needs and computational tradeoffs [12]. Choosing an expressive language without a corresponding reasoning strategy can leave a project with declarations that no deployed component actually evaluates.
SHACL（形状约束语言）describes constraints for validating RDF data graphs [8]. An application could require each accepted Evaluation to have a dataset reference and a numeric score with an appropriate datatype. A validation report then identifies records that fail the defined shapes. Such validation concerns conformance to a declared contract. It does not establish that a reported score was measured honestly or that the experiment was well designed. The Research Evidence Graph therefore records validation status separately from scientific confidence.
In a property graph implementation, uniqueness constraints can prevent duplicate identifiers, while application logic can check more complex requirements. Neo4j documents several constraint types with version and edition conditions [45]. A portable design should specify the required invariant first and then identify where it is enforced: database, ingestion service, batch audit, or human review. This prevents the schema diagram from implying protections that exist only as comments in a document.
2.5 Time uncertainty and provenance
Temporal modeling distinguishes valid time（有效时间）, when a statement applies in the modeled world, from transaction time（记录时间）, when the system recorded it. Suppose a correction published in March states that an affiliation ended in January. The affiliation's valid interval changes in January, but the graph learned about the change in March. Keeping both times allows a user to ask what was believed on a past date and what is currently believed about that same past period.
An uncertain claim needs more than a single confidence number. Extraction confidence estimates whether the source was interpreted correctly. Source reliability concerns the origin of the statement. Empirical uncertainty concerns the measurement or statistical result. A fourth dimension may concern whether the statement transfers to a new population. Combining these into one unlabeled score destroys useful information. A graph can store separate fields and require an application to explain which dimensions affect its decision.
Provenance（溯源）links records to sources, activities, and responsible parties. PROV-O offers a vocabulary for entities, activities, and agents and their relationships [10]. The report's proposed implementation records document version, evidence span, extraction run, model version, reviewer, and acceptance decision. This operational extension is a design recommendation rather than a claim that every field is mandated by PROV-O. The aim is to make a statement reproducible and correctable at the level where errors actually occur.
2.6 Schema evolution and governance
A schema changes when users discover a distinction that matters. Initially, a project might treat all relationships between papers as CITES. Later it may need SUPPORTS, CRITIQUES, REPLICATES, and USES_DATA_FROM. Replacing every old citation with one of these finer categories would invent knowledge unless the sources are reexamined. A better migration retains the broad relation, adds specialized relations when supported, and marks which records have been reviewed under the new schema.
Versioning should cover the schema, mapping rules, validation shapes, and query templates. A migration plan explains how existing records remain interpretable and how dependent applications are tested. Deprecating a relation should not silently change its historical meaning. The team can introduce a new relation, maintain a compatibility view for a defined period, and document the semantic difference. These measures protect users who rely on old exports or cached analysis results.
Schema governance is a decision process, not only a technical repository. A domain specialist should resolve whether two concepts are meaningfully distinct. A data steward should own identity and provenance policies. An engineer should verify enforcement and migration feasibility. For a small personal research graph, one person may fill all three roles, but the questions remain distinct. Recording the rationale for a modeling choice helps that person avoid repeating the same debate months later.
The resulting schema should be small enough to explain and rich enough to answer the competency questions. Its quality can be tested through representative records, ambiguous cases, and adversarial examples. A useful review asks whether each node type has a clear identity policy, each relationship has a direction and meaning, and each important constraint has an enforcement location. Once those commitments are stable, extraction and storage become much easier to evaluate.