How do people translate W3C PROV-O provenance graphs quickly without rewriting the history of a dataset or report? Keep the RDF resources, their identifiers and their provenance relationships fixed. Add or revise authorized language-tagged descriptions for readers, then test that every entity, activity and agent still has the same role in the evidence chain. A translation is useful when it makes a complex audit trail understandable in another language, not when it produces a tidier but false account of who generated, used or revised information.
PROV-O, the W3C Provenance Ontology, represents provenance with concepts including prov:Entity, prov:Activity and prov:Agent, and properties such as prov:wasGeneratedBy, prov:used, prov:wasAttributedTo and prov:wasDerivedFrom. These graph relations describe more than ordinary sentences. They can feed accountability reviews, scientific reproducibility, data lineage displays and explanations of AI-generated material. A translator must distinguish a literal label shown to people from a machine-readable edge explaining how one resource relates to another.
This guide provides a complete, offline-first workflow using a fictional school rainfall-report graph. It covers extracting natural-language literals, attaching language tags, preserving provenance identity, validating the resulting RDF, diagnosing missing labels and testing a changed-context exercise. The subject is deliberately narrower than general knowledge-graph translation: the reader’s job is to localize an existing provenance record while preserving its historical assertions, not to invent a new ontology or silently change the evidence.
Fast answer: keep the graph, localize selected literals
Begin by saving the canonical graph and listing all resources and triples that define its provenance claims. The same record may be serialized as Turtle, JSON-LD, RDF/XML or another RDF format. Choose the actual serialization used by the project, parse the original and preserve a stable comparison copy. If a public repository is authoritative, obtain authorization before altering it. Translation teams can draft an RDF language overlay offline without modifying the original publication.
Identify strings that are intended for human readers: perhaps rdfs:label, rdfs:comment or a project-specific descriptive property. Those are candidates for translated literals where the data model and publication policy permit them. Resource IRIs, namespace names, timestamps, code identifiers and provenance predicates are not English phrases waiting to be translated. Renaming prov:wasDerivedFrom because its local name looks English changes the vocabulary being used and destroys interoperability.
Set a precise acceptance condition: a Malay-speaking student examining the translated rainfall report should identify the same source spreadsheet, processing activity, software agent, author and derived chart as the English-speaking student. They should understand that a chart was generated by a particular workflow and derived from a recorded dataset, not conclude that a named person personally measured every figure if the provenance only attributes review to that person. This condition keeps translation tied to meaningful inquiry.
Read the PROV-O triangle before extracting strings
A prov:Entity represents something that has relevant identity within a provenance account, such as a document, a dataset or a chart. A prov:Activity represents an action or process occurring over time, such as importing observations or preparing a visualization. A prov:Agent represents something bearing responsibility for an activity, entity or another agent. These categories help the graph distinguish the product from the process and the person or software responsible for it.
Suppose a school project has raw rainfall measurements, a cleaning script, and a plotted report. The raw observations can be an entity. The processing run is an activity. The script or a human analyst may be represented as an agent where the graph’s modeling policy makes that appropriate; the script file itself might also be represented as an entity used by the activity. The derived report is another entity. Replacing all of these with one translated label such as ‘rainfall analysis’ hides the differences a reviewer needs.
PROV-O relations have precise directions. prov:wasGeneratedBy connects an entity to its generating activity; prov:used connects an activity to an entity it used; prov:wasAssociatedWith relates an activity to an agent; prov:wasAttributedTo relates an entity to an agent; and prov:wasDerivedFrom expresses derivation between entities. A reader-facing translation should explain these claims rather than altering them to match the translator’s preferred story.
Labels are literals; identities are resources
An RDF graph can give one resource labels in more than one language. A resource IRI such as https://example.org/provenance/rainfall-chart can have an English label and a Malay label without becoming two unrelated charts. The label is a human-facing description; the IRI provides persistent reference within the data model. This design allows a language switcher to help readers while keeping provenance joins and queries stable.
For example, the following Turtle is a minimal illustrative graph fragment, not a complete audited research record. It is syntactically testable with an RDF parser, and its invented resources are illustrative only:
@prefix ex: <https://example.org/provenance/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
ex:rainfall-chart a prov:Entity ;
rdfs:label "Rainfall chart"@en ,
"Carta hujan"@ms ;
prov:wasDerivedFrom ex:rainfall-data ;
prov:wasGeneratedBy ex:chart-export .
ex:chart-export a prov:Activity ;
rdfs:label "Chart export"@en ,
"Eksport carta"@ms ;
prov:used ex:rainfall-data .
ex:rainfall-data a prov:Entity ;
rdfs:label "Rainfall observations"@en ,
"Pemerhatian hujan"@ms .
Observe what the translated literals do not change. They do not change the chart’s IRI, the activity’s IRI, the classes of the resources or the derivation and usage edges. The labels can be chosen and reviewed without mutating the machine-readable history. In practice, the project’s ontology may use other descriptive properties, and an application’s language negotiation may require explicit configuration. PROV-O does not itself promise that every viewer will automatically choose the right language.
Language tags require accuracy and deliberate fallback behavior
RDF language-tagged strings can carry tags such as en, ms, zh-Hans or a more specific language variant when appropriate. The tag identifies the language of the literal, not the country in which the server runs. If a target-language string is mistakenly marked @en, a language-aware query may choose it as English and hide it from the intended audience. This bug can pass ordinary visual inspection because the string looks correct in the file.
Make one inventory row per label and intended language. Check that the translated literal actually belongs to the tag and that no label is silently copied across languages where it means something different. Consider regional and script differences in the audience. Do not invent hundreds of tags from geographical assumptions; start with the user’s real languages and the fallback behavior the application supports. A short missing label is usually preferable to a fabricated translation with the wrong subject.
Language selection is generally implemented by the consuming query or application. A SPARQL query might filter literals by language tag, while a viewer might choose a preferred language and fall back to English when a localized string is missing. Neither behavior is guaranteed by RDF serialization alone. Test both an exact target tag and a reader whose preference is unsupported. Without this test, a valid multilingual graph may render as a blank node list or show duplicated labels to users.
Identity, time and responsibility are not editorial choices
A provenance graph may associate a chart with a student who prepared it and a teacher who reviewed it. A translation that labels the teacher ‘author of the chart’ where the actual relation describes review responsibility changes the apparent chain of accountability. The dangerous mistake may exist only in the human-facing label; the RDF predicates can remain untouched while the display tells a false story. Semantic QA therefore needs to compare each label against the graph’s relations.
Time is similarly sensitive. A label such as ‘revised report’ should not be used until a revision is documented. PROV-O includes relations describing derivation and revision, and activities may be assigned start and end times. Do not translate a timestamp or infer a precise order of events beyond the graph’s assertions. If the available graph states that an entity was generated by an activity but omits timing details, the target explanation should not pretend the date is known.
Treat uncertainty as a first-class editorial concern. A graph can be incomplete, and an absent edge is not necessarily proof that a person had no role. Descriptive prose should distinguish ‘the record attributes this output to an agent’ from ‘this agent alone created the output’. The translation should not fill provenance gaps using common sense, especially where audit, educational discipline or public accountability is involved.
Make source extraction reversible and compare triples
For a translation job, enumerate literal nodes on approved descriptive predicates and attach a record of subject IRI, predicate IRI, original literal, source language, target language and reviewer decision. Store proposed translations separately until approved. This record can be represented as a CSV or JSON review table without claiming it is part of the PROV-O specification. A stable subject-and-predicate key helps the team reattach the right string to the right resource.
After applying translations, compare the graph before and after. The exact order of RDF triples or blank-node identifiers may differ across serialization, so a simplistic text diff is insufficient. What matters is whether the intended provenance edges and protected resources remain semantically equivalent. If the workflow adds new label triples, the target graph will have more triples than the original; the audit should whitelist those additions and verify that no other unexpected assertions changed.
A parser can catch syntax errors, but it cannot decide whether ‘data reviewer’ is a faithful label for an agent described only as an uploader. Human review must examine role language against the provenance claims and any external project documentation. Keep a separate QA result for syntax, invariants, label accuracy and display behavior. That layered result is more informative than a single ‘translated successfully’ checkbox.
SPARQL can reveal problems that a file preview hides
Readers may encounter the graph through a query interface rather than opening a Turtle file. A developer can query labels in a target language, retrieve connections among an entity, activity and agent, and build a rendered provenance timeline. If the translation team accidentally converts a string into a new resource or drops a language tag, the query may behave differently even though the file remains parseable.
Design tests around the reader job. Ask for the Malay label of the rainfall chart and verify that the returned subject is the same chart IRI as in English. Ask which activity generated that chart; its answer must not change because of localization. Ask which entity the activity used; the answer must still be the raw observations. Then check a fallback for a language not represented. These questions are easy to understand and protect the meaning behind the graph’s technical encoding.
Do not assume all SPARQL implementations apply the same convenient language-selection policy. Some return both localized literals unless a filter is supplied; others rely on application code to choose one. A multilingual QA plan should document the actual query or viewer logic in use. A translation that produces a duplicate label list may be structurally correct, and the repair may belong in presentation code rather than in the ontology.
Keep literal meaning consistent with the ontology’s distinctions
A label should be understandable but not so generic that it erases a relevant distinction. For an activity that combines source tables, ‘merge rainfall datasets’ is more informative than ‘data work’. Conversely, a label must not claim data cleaning if the recorded activity only exported a chart. Translators should inspect the graph and associated workflow description before committing to action verbs. The name of an activity is not always evidence that it performed every imaginable step within the broader project.
Distinguish sources from outputs. If a graph says a chart was derived from a table, a display sentence may explain that connection but should not say the table was derived from the chart. Direction matters. When the graph includes prov:wasRevisionOf, the newer entity and older source must remain in the correct orientation. A translated sentence that reverses them can undermine a reader’s ability to find the original evidence, even if the arrow on the visualization points the right way.
Provenance often involves a chain: a raw file, a normalized file, an aggregated result and a report. Review the labels in sequence, not one at a time, to confirm that they preserve the workflow’s stages. A translation unit that looks acceptable in isolation may cause two separate entities to acquire identical names. If the interface then shows them as indistinguishable, readers can mistake a processed dataset for its untouched source.
Privacy and ethical disclosure are part of the translation boundary
Provenance data can identify people, locations, software services and operational routines. A translated description may make sensitive context easier to find or inadvertently reveal a role that the source deliberately describes generically. Follow the project’s disclosure policy. Do not expand initials, infer full names from nearby metadata or translate pseudonyms into real-world identities. Language access does not create permission to enrich personal data.
An education project may wish to teach attribution using fictional agent names. That can be a good explanatory overlay, but do not replace actual source agents in a research graph without a formal anonymization and data-management decision. If information must be protected, create a separate release whose redactions and provenance are documented. A translation-only patch should not smuggle in de-identification work or new assertions about individuals.
If a label itself contains discriminatory or misleading historical terminology, the team may need more than a literal translation. Preserve what the source record actually said, offer context in a clearly distinct editorial note, and refer decisions about corrected descriptions to the data custodian. The goal is not to freeze every phrase forever, but to distinguish documenting evidence from changing it.
Diagnose failures by following the graph’s layers
A Turtle parsing error often points to quoting, escape characters or punctuation around a literal. A wrong label appearing in the interface may be caused by a language tag or query filter. A broken graph relation may indicate that a resource IRI or predicate was edited. A misleading statement about responsibility may be a semantic error in a human label despite correct RDF. Treat these as separate failure classes and choose the corresponding repair.
When a graph’s source data changes, version the localized label set against the source snapshot. Some updates affect only commentary; others change relationships and make previous descriptions false. The translator should not mechanically reuse a label that says ‘final approved chart’ when the new entity is a preliminary export. Maintaining a dependency between translations and described resources is more efficient than restarting from zero but safer than blindly copying everything forward.
The most effective workflow ends with reader testing. Give a student two differently localized interfaces and ask them to identify which document was derived from which dataset, who is documented as responsible and what process generated the output. If the answers differ despite the underlying graph being identical, the localization has failed at the human interpretation layer. Better language access must preserve the same evidence story.
Ten provenance-label cases with distinct failure mechanisms
Case 1: A software agent is presented as a human contributor
The rainfall data pipeline was run by a scheduled software service, but the translated display label calls the service ‘a data scientist’. The RDF may still type the resource as a software agent, but readers now attribute judgment and personal responsibility to a human who did not appear in the record. This is especially misleading in a school research project where the distinction between an automated calculation and an expert’s interpretation matters.
Inspect the agent’s recorded type and association with the activity. Translate the label as a software service or automatic processing agent where that is what the record establishes. Do not invent a person’s name or imply that human review took place. The test is a question to the target-language reader: was the chart exported by a scheduled process, personally calculated by a teacher, or checked by a named reviewer? Their answer should match the provenance assertions and the documentation, rather than the connotations of one attractive phrase.
Case 2: The source and derived file exchange places
The graph contains a raw observation file and a corrected file, with a derivation edge from the corrected entity to the raw entity. A translated figure caption describes the raw file as the output ‘based on’ the corrected one. The screenshot still has two boxes and an arrow, so a quick visual test may not reveal that the prose reverses causality. A user studying reproducibility might seek the wrong file as the original evidence.
Reconstruct the chain from the direction of prov:wasDerivedFrom rather than from the left-to-right layout of a diagram. Give source and derived entities different approved labels, and verify the translated explanatory sentence against both IRIs. Ask the reader which file existed before the documented correction activity and which one depends on the other. If the label cannot support that answer, the caption or node descriptions require revision.
Case 3: ‘Attributed to’ is made into ‘generated by’
A chart entity has prov:wasAttributedTo pointing to a student editor who accepted responsibility for the published output. The target-language label says ‘produced automatically by the student’, which conflates attribution and generation and introduces an unsupported method. A provenance graph can represent different forms of responsibility without specifying each mechanical step. Making the label more vivid can therefore create a fact the graph never asserted.
Use terminology that matches the relation. A plain-language label may say ‘chart attributed to the student editor’, with optional explanatory notes about the nature of attribution where project policy defines it. Do not introduce an automatic process unless a generating activity or workflow record supports it. A reviewer should be able to distinguish who is accountable for the entity from which process generated it. Preserve both distinctions even if everyday conversation often uses the word ‘made’ for both.
Case 4: A date label assumes more temporal precision
An activity’s provenance gives a start time but no verified end time. The localization team writes ‘completed at 14:00’ because the graph is displayed in a report generated that afternoon. The proposed sentence gives a false completion timestamp. It may undermine audit integrity when two versions of a dataset were produced in nearby runs. The absence of a stop time is not a license to estimate one in public metadata.
Translate what is present: ‘processing started at…’ with the original time zone and documented precision. If a source has only a calendar date, do not invent an exact clock time. When a duration is described, distinguish observed duration from a later editor’s estimate. Compare the translated timeline with the protected temporal triples and the project’s process logs, if authorized. The correct outcome may be a visibly incomplete timeline, because the underlying provenance is incomplete.
Case 5: Missing translation is mistaken for a missing entity
The English graph has labels for three entities; only two have Malay labels. A viewer filters exclusively for @ms and removes any unlabeled resource from its diagram. The missing node appears as though the corresponding data file never participated in the process. An RDF localization has now become an evidence-omission problem through presentation behavior, despite no provenance triple being deleted.
Repair the viewer by preserving all resources regardless of label availability and defining an explicit fallback to an approved source-language label or an identifier. A missing translation should be marked as missing, not as evidence that the resource does not exist. Test the output with one deliberate missing target literal. The full provenance graph should remain visible and queries for derivation or usage should produce the same bindings in both language modes.
Case 6: A namespace prefix is translated as a glossary word
A translator sees the prefix prov: and attempts to replace it with a target-language abbreviation throughout a Turtle file, assuming that this local-looking notation belongs to prose. In RDF, a prefix declaration abbreviates IRIs. Changing a prefix name is technically possible if its expansion is kept consistent, but doing so offers no language benefit and can easily break parsing if only some appearances are changed. Editing the namespace IRI itself is more serious because it changes the vocabulary.
Leave the standardized namespace and predicate IRIs unchanged. Focus on the literals selected for human display. If a project intentionally changes prefix conventions for readability, treat it as a serialization operation and verify RDF graph equivalence, not as translation. A useful diagnostic is to parse source and target files into triples and compare predicate IRIs. The human-facing explanation can translate the meaning of a property without modifying the property’s machine identifier.
Case 7: A revision is described as a quotation
One entity has a provenance relation indicating that it revises an earlier document, but the localized label describes it as a quotation from that document. A quotation may reproduce some wording while a revision can involve edits and changed claims. Different provenance categories affect what a reader should expect when comparing versions. If a teacher uses the translated diagram to discuss corrections, the category error obscures the very reason version history exists.
Review the actual predicate and compare the source and revised artifacts when available. Choose a term conveying revision, not reproduction, unless the provenance explicitly uses a quotation relation. If the graph lacks enough detail to explain the extent of change, the label can state that it is recorded as a revision without asserting the nature of every edit. Ask the reader whether they expect two materially identical excerpts or a later modified record. The answer should be guided by the provenance, not the translator’s assumption.
Case 8: The same label is assigned to two different processing stages
A raw sensor file and an aggregated monthly summary are both translated as ‘rainfall data’. The labels are not literally false, but their uniformity makes a diagram incomprehensible: the user can no longer tell where preprocessing ended and aggregation began. A search engine may also surface the wrong dataset for a user who needs direct observations. Over-generalization can damage discoverability without changing the graph’s formal semantics.
Write differentiating labels grounded in the resources, such as ‘raw hourly rainfall readings’ and ‘monthly rainfall summary’, if those descriptions are supported. Avoid introducing unsupported temporal resolution. Test by giving a learner the translated interface without English hints and asking which file should be used to reproduce the aggregation. If two nodes remain interchangeable to the reader, the translation needs more informative vocabulary or accompanying descriptions.
Case 9: A label reveals personal information absent from the source
The source graph identifies an agent through a project pseudonym. A bilingual editor recognizes the person’s likely real name from classroom knowledge and expands the localized label. The new string discloses information that the published provenance did not disclose. The editor may believe that a complete name helps accountability, but provenance authorization and identity disclosure are separate questions.
Restore the pseudonym or use an approved neutral description. If the research project genuinely needs attribution to a named person, its custodian should authorize and document that change through the appropriate data process. A translation review should inspect whether any label unexpectedly increases identifiability, especially in small groups. Preserving a pseudonym across languages is not an incomplete translation; it is an appropriate boundary when the underlying disclosure is intentionally limited.
Case 10: A translated correction note becomes a changed graph claim
A dataset owner corrects an erroneous label explaining an analysis step. The translator responds by changing prov:used to prov:wasDerivedFrom in the RDF graph, hoping the new predicate matches the new wording. That edit changes the modeled relation and may attach the wrong domain and range concepts. The problem originated in prose, but the repair alters provenance. A second tool consuming the graph can now reach different conclusions about data lineage.
Stop and determine whether the correction concerns only the human description or the underlying provenance assertion. If the graph was genuinely wrong, it needs a documented curation change by the authorized data owner, with validation and versioning. If only a label was misleading, revise the literal and leave the provenance edges fixed. Compare before-and-after triple sets, not just rendered sentences. Translation work should not silently function as ontology maintenance.
Changed-context transfer: provenance for an AI-assisted classroom report
A class produces a science report using a dataset, a spreadsheet formula, a text-generation assistant and a teacher’s corrections. The provenance graph records the raw source, a spreadsheet calculation activity, a draft paragraph attributed to a software agent, and a final edited report attributed to the teacher. The planned target-language exhibit simply states: ‘The teacher wrote the entire report from original measurements.’ It also displays the draft and final document using the same label, and omits the software agent from the diagram because its name has no translation.
Explain three defects before reading the answer. What responsibility does the graph actually record? Which distinction between draft and final report matters? Why must a missing label not cause an agent to disappear? How can the language editor make this provenance accessible to parents without announcing unsupported facts about how much work the teacher or student performed?
Worked answer
Do not claim full authorship or direct measurement from an attribution relation that does not support that conclusion. Preserve the raw source, calculation, AI-assisted draft, human revision and final entity as distinct resources with distinct roles. Translate the available labels and provide a source-language fallback for any missing one. If the project wants to add details about the teacher’s actual editorial contribution, require verified evidence and authorized provenance updates rather than inventing them in a caption.
The transfer test should ask a parent to identify where the numeric results came from, which part was generated with software assistance and which version received final review. The target-language account must allow the same supported answer as the source graph. Check that language switching never changes resource IRIs, provenance predicates, actor identities or the number of displayed entities. This is the same principle as the rainfall example, now applied to the practical problem of explaining human and AI contributions honestly.
Review checklist, limitations and final lesson
Check the source graph’s identity and version; retain the same entity, activity and agent IRIs; freeze provenance predicates, referenced resources and temporal facts; add only approved descriptive literals with correct language tags; verify that labels do not overstate roles, conclusions or identity; parse the output; compare protected triples semantically; run language-aware queries and fallbacks; and test the actual reader interface. Record any intended graph curation separately from localization.
PROV-O records can be incomplete, and vocabulary constraints vary among projects. No parser can establish that a descriptive label accurately recounts history, nor can a multilingual interface create provenance that was never collected. A translation team cannot independently decide an agent’s legal responsibility, a dataset’s authenticity or whether an inference is factually warranted. Escalate disputed claims to the data custodian.
Reliable localization makes the history easier to follow without altering what the history says. When the graph and its documented evidence remain stable, readers using different languages can ask the same questions, find the same origins and distinguish explanation from invention.
A classroom audit protocol that checks meaning, not just syntax
Split the review into three deliberately different roles. The technical reviewer receives the two RDF graphs and a protected-triple rule; they identify exactly which statements have changed beyond the approved label additions. The bilingual reviewer receives the source and target literals plus context around each resource; they explain what a target-language reader would believe. The project owner receives the displayed lineage narrative and confirms whether its claims about responsibility and processing are supported by the actual workflow. Agreement across the three roles is more meaningful than a single green parser result.
Use an adversarial test in which each reviewer is given a plausible but wrong description. The technical reviewer should catch a changed resource IRI even when the chart remains visible. The bilingual reviewer should catch ‘created’ replacing ‘reviewed’ even when the code and grammar are flawless. The owner should catch a previously correct label that becomes misleading after a new processing stage is added. This test makes the quality gate robust against the natural tendency to accept polished output.
Store outcomes in a durable ledger with a resource IRI, property, language, reviewer, source graph version, resolution and date. A disagreement should have an explicit state such as ‘needs evidence’ rather than being forced into either approved or rejected. On the next translation cycle, only re-evaluate the literals whose dependency or source documentation changed, alongside a sampled full-chain sanity check. That is a realistic way to improve speed without making the provenance story less trustworthy.
When translation should stop and data curation should begin
Sometimes a translated label exposes a flaw in the original graph. An editor notices that a chart appears generated by two incompatible activities, or that a document was attributed to an agent who had already left the project. These findings matter, but the translator should not alter the graph on their own. Record the suspected inconsistency, quote the relevant triples, identify the source evidence needed and route the issue to whoever maintains provenance. The translation can remain pending while curation investigates.
If the maintainer corrects the underlying record, create a new governed source version and rebase the labels against it. This differs from silently repairing an untranslated English phrase. A corrected provenance statement may force several language labels to change, because what an output means now depends on a different documented activity or agent. Keep the distinction visible in history: the provenance itself was revised by an authorized custodian, and its readable descriptions were subsequently localized.
The benefit is institutional trust. A user should be able to tell whether the words changed, whether the evidence changed, or whether both changed for documented reasons. That distinction supports scientific reproducibility and responsible use of AI output. It also gives students a useful concept: language is a lens on a record, not the source of the record’s truth.
Frequently asked questions
1. Is a translated rdfs:label a different provenance entity?
No. Multiple language-tagged labels may describe the same IRI. They do not create separate entities unless the project explicitly creates new resources and relations. Keep resource identity distinct from human display language.
2. Does PROV-O require every resource to have multilingual labels?
No. PROV-O defines provenance concepts and relations. Labels may be supplied through RDF vocabulary or application-specific descriptive properties, but automatic multilingual user-interface behavior is not guaranteed by PROV-O.
3. Can we translate prov:used or prov:wasGeneratedBy in source files?
Explain these terms in user-facing documentation, but do not translate their namespace IRIs as though they were prose. Those are formal properties whose identity allows independent systems to interpret provenance consistently.
4. Why can a grammatically perfect translation be misleading?
A label may overstate who performed an action, reverse a derivation or invent a completion time. Syntax and fluency cannot establish the truth of a provenance claim. Compare each description with the graph and underlying evidence.
5. How do language tags affect search and display?
A tag identifies the language of a literal. Queries and interfaces can use it to select or prioritize labels, but the project must implement and test the actual fallback rules. An incorrect tag may hide a valid translation from its audience.
6. Is adding a second language always safe?
Not automatically. It may disclose context, create ambiguity or conflict with the schema or the application’s expectations. Confirm the predicates intended for display, disclosure policy and target software behavior.
7. How should a translator handle missing provenance facts?
Describe the record’s known assertions without filling gaps through speculation. Missing evidence may warrant a curation request, but an untranslated or incomplete graph should not be made to sound certain for stylistic reasons.
8. Can we validate the new Turtle with ordinary RDF tools?
Yes, an RDF parser can check syntax and a graph diff can audit changed triples. Additional project constraints may be validated using appropriate shape or application rules. Semantic fidelity of labels still needs human review.
9. What is the difference between a translation fix and graph correction?
A translation fix changes a human-readable literal to represent the same underlying claim. A graph correction changes modeled resources, relationships or facts and requires authorization, provenance and potentially a new version.
10. When should multilingual provenance labels be updated?
When source terminology, provenance edges, resource identity or associated documentation changes in a way that affects the truth of a label, or when reader testing exposes a misleading translation. Use version-aware review rather than blindly copying labels.
Authoritative current specification sources
- W3C PROV-O: The PROV Ontology, W3C Recommendation, 30 April 2013: https://www.w3.org/TR/prov-o/
- W3C PROV-DM: The PROV Data Model, W3C Recommendation, 30 April 2013: https://www.w3.org/TR/prov-dm/
- W3C RDF 1.1 Concepts and Abstract Syntax: https://www.w3.org/TR/rdf11-concepts/
- W3C SPARQL 1.1 Query Language: https://www.w3.org/TR/sparql11-query/
The fictional chart graph is a teaching fragment. Actual projects may require additional ontology terms, shapes, trust requirements or disclosure controls; test against the authoritative project data model.
Verified internal connections
- What Is a Provenance Trail? for a beginner-friendly account of revision and source tracing.
- Translate | Names, Numbers, Dates and Units for preserving exact reference facts.
- The Gold Standard of Ecological Informatics for a related evidence-management setting.