WIPO ST.96 10.0 patent-abstract translation QA is a method for producing an understandable translation of an invention summary while keeping the patent application’s identifiers, filing history, component structure, technical claims and source provenance intact. The immediate answer is to freeze the official patent record, translate the appropriate narrative component in a controlled derivative, review technical terminology against the description and claims, and validate any resulting XML against the correct ST.96 10.0 schemas and office-specific implementation rules before exchange.
A patent abstract is short compared with a full specification, but it can contain the invention’s mechanism, materials, measurement ranges and relationships between components. The translator can damage the reader’s understanding with a single change from “may comprise” to “must comprise,” from “at least” to “more than,” or from a particular component reference to a different one. The challenge is to communicate the same technical disclosure without implying that a translated research aid is a legally authoritative amendment to the application.
The fast reliable workflow begins by identifying the patent publication and its exact XML release, extracting the abstract with its language and source reference, resolving terminology against the description, drawings and claims, translating without touching bibliographic identity fields, and running distinct checks for XML structure, technical content and legal-status provenance. A valid XML file is not the same as an accurate patent translation, and a fluent translation is not permission to change a filing record.
Why this particular standard needs careful handling
WIPO Standard ST.96 provides an XML approach for exchanging intellectual-property data. It has common components and domain components for patents and other IP areas. Annex II supplies a data dictionary; Annex III publishes XML schemas; annexes for implementation and transformation help organizations apply the schemas. As of October 2026, the WIPO ST.96 10.0 schema listing identifies a release approved by the XML4IP Task Force on 1 April 2026. That date and version matter because an IP office may use a particular ST.96 version or a country-specific implementation rather than the newest release.
The patent domain includes abstract components, titles, claims, bibliographic records and other information with distinct purposes. The fact that several fields contain words does not make them interchangeable. A publication number identifies a document; a priority claim locates an earlier filing in the legal chronology; an abstract summarizes technical disclosure; the numbered claims define a different, legally significant layer of text. Translating a summary without looking at the claims can introduce a technical inconsistency even if the XML fields are left untouched.
A source document also has a language context. A publication may provide original-language and translated materials under specific office policies. A translator must know which version is authoritative for the requested use: a classroom explanation, a search index, an examiner-facing exchange or a formal translation for legal proceedings. These purposes have different evidential requirements. This article describes a structured quality workflow, not legal advice and not an instruction to modify official filings. Formal submission rules need jurisdiction-specific professional review.
The speed of modern translation tools can create a false sense of simplicity. A full-text machine translation may produce attractive prose in seconds, yet a technical domain often uses ordinary words with unusually precise meanings. “Substrate,” “carrier,” “charge,” “lead,” “bias” and “claim” all have meanings that depend on the invention. A bilingual reviewer should make a concept map of the device or method before deciding on final equivalents. This reduces the risk of applying one dictionary translation to several different technical roles.
Freeze the document’s identity and version
Create a source record that identifies the patent application or publication, office, document number, kind code, relevant dates, source language, ST.96 release and source XML checksum. Record whether the abstract came from an official publication, an internal draft or an intermediate transformation. The translator should not infer legal status merely from a title, or assume that a file with a WIPO namespace is itself a certified publication. Provenance is a factual chain that can be verified later.
A patent number or application number may contain letters that resemble ordinary language abbreviations. They are not candidates for translation. The same principle applies to kind codes, country codes, identifiers for citations, schema namespace URIs and XML element names. These bytes are used to match records and validate exchange messages. Preserve them unless a documented data-migration operation has been separately authorized. Localized user interfaces can explain their meaning alongside the unchanged values.
Version locking must include the schema package and the office profile. An XML instance could conform to an international schema and still violate local filing business rules, or it could be valid against an older release but incompatible with a new receiving system. Record both checks rather than report a generic “schema passed.” If an office’s implementation extends or constrains ST.96, the QA plan should test those constraints explicitly. Do not invent an XML example and present it as validated simply because its tags appear similar to component names on the WIPO website.
Maintain a content digest for the source abstract and a separate revision for the translated prose. When the original publication receives a correction, retranslation may be necessary even if only one technical term changed. An immutable source pointer lets the reviewer find the exact wording used at translation time. This is especially important in patent families with multiple related publications, continuations or amendments. Two documents can share an invention title while containing different claims, figures or revisions.
Locate the true narrative boundaries
The WIPO data dictionary and schema component index help an implementation distinguish a Patent Abstract from a patent title, claims or a general description. The translation queue should be built from the actual XML component paths in the particular implementation, not from a broad regular expression that selects all tags containing the word “Text.” Some text fields identify parties, procedural states or formal notices; changing them could alter the official record. A scope document should name the approved abstract component and explain what nearby text is out of scope.
Within the abstract, preserve references to figure numbers, materials, ranges and component relationships. These may appear as plain words but function as technical anchors. When an abstract says a sensor is “disposed adjacent to” a membrane, a translation saying “inside” the membrane changes the physical arrangement. The translator needs the drawing and description to see the difference. A quick review can mark every relational expression—above, between, coupled to, configured to, selectively, upstream of—and ask what it means mechanically.
Some patent publications contain several language variants or a translated abstract already produced by an office. Do not overwrite or silently supersede an existing variant. Identify the target language, provenance and intended authority of each record. A new translation might be suitable only as a non-official research aid. A reader interface should distinguish “original abstract,” “office-supplied translation” and “editorial translation” when those categories apply. That label is not decoration; it tells users how much legal reliance they may place on the displayed wording.
The document’s surrounding classification and citation data should remain available to the reviewer. Technical fields such as IPC or CPC classifications can help explain the domain, but a classification symbol is not a substitute for understanding a claim. If the invention spans two areas, a reviewer should avoid importing a translation that is familiar in one field but wrong in the other. Source context should inform terminology without being copied uncritically into the abstract.
Establish a concept-level terminology sheet
Before drafting, identify each object, process step and measurable property described in the abstract. Give each concept a stable internal ID for the review, then record the source phrase, intended meaning, approved target equivalent and an example from the description or figure. This is not an attempt to add invented IDs to the patent itself. It is a working glossary that helps editors see whether the same component was translated differently in adjacent sentences.
For a fictional low-cost water sensor, the glossary might distinguish a sensing electrode, a reference electrode, a permeable membrane, a housing and an alarm controller. “Reference” could describe an electrode or cite an earlier document; translating both identically might be grammatically possible but semantically confusing. The glossary should include negative examples showing when a target term must not be used. A linguist can then choose fluent target grammar while preserving the device’s parts and causal relationships.
Patent language also uses logical qualifiers. “At least one,” “one or more,” “not greater than,” “less than,” “approximately,” “selected from” and “optionally” each constrain an assertion in a different way. A translator should preserve the distinction and should not replace all cautious formulations with a generic statement that an invention “uses” a component. A review table can include the source operator, target construction and a truth-condition test. For example, “at least two sensors” includes two, whereas “more than two sensors” excludes exactly two.
For method claims or abstracts describing processes, verbs deserve the same attention. “Comprising” a step does not necessarily prescribe a complete chronological order. “Following,” “before,” “in response to” and “while” can impose different temporal relations. A translation can accidentally introduce sequencing that the source did not require. Draw a small flowchart of the physical or logical process and compare it with the target sentence. This visual test is often more effective than checking each word with a bilingual dictionary.
Translate cautiously when claims and abstract differ
An abstract is a summary, not a replacement for the claims. A translator may find a broader phrase in the abstract than in the numbered claims, or an example in the description that is more specific than the summary. Do not automatically harmonize them by rewriting the abstract to mirror claim wording. That would be an editorial or legal change outside a normal translation task. Instead, flag the difference and ask the relevant subject expert whether the target wording accurately reflects the source abstract as written.
Suppose an abstract says a “light detector” but a claim specifies a photodiode. The translation should not silently replace every instance of light detector with photodiode merely because the claim uses that example. The abstract may intentionally refer to a broader class of sensor. Conversely, if the source abstract explicitly names a photodiode, reducing it to an unspecified optical device may lose material information. Record such choices with the supporting source phrase and the reason the target term was selected.
The legal effect of a translation can vary by jurisdiction and filing purpose. A machine-assisted summary on a public information site is not equivalent to a certified translation submitted to a patent office. Include a provenance label and avoid claims such as “official English version” unless an authoritative source establishes that status. Where formal filing is contemplated, obtain jurisdiction-specific review. The translation process can supply traceable evidence to professionals, but it cannot replace the rules governing amendments, priority and language of proceedings.
A controlled sidecar example for reviewers
The following JSON is an original editorial review record. It is deliberately not presented as a WIPO ST.96 XML instance, because an official instance must follow the exact schema and any receiving-office profile. The sidecar records a source identifier, source and target language, original abstract excerpt, target excerpt, and the fields frozen by the translator. Its syntax can be parsed independently and it can support a comparison audit without changing the original patent XML.
{
"reviewRecord": "abstract-review-0007",
"sourceDocument": {
"publicationId": "DEMO-2026-007-A1",
"sourceLanguage": "en",
"schemaRelease": "ST.96 V10_0",
"sourceDigest": "example-only-not-a-production-checksum"
},
"translation": {
"targetLanguage": "fr",
"sourceExcerpt": "The apparatus includes at least two sensing electrodes.",
"targetExcerpt": "L'appareil comprend au moins deux électrodes de détection.",
"status": "editorial-review"
},
"frozenFields": ["publicationId", "sourceDigest", "schemaRelease"]
}The invented identifier begins with DEMO to discourage any confusion with a real patent publication. A correct review does not merely check that the French sentence is grammatical. It tests the quantifier “at least two,” the physical component “sensing electrodes” and the relationship “includes,” using an approved terminology sheet. The fictitious sourceDigest is intentionally not a cryptographic claim; a real pipeline should calculate a genuine hash from the exact source bytes and record which canonicalization policy, if any, was applied.
When the target wording is approved, a receiving application may need to create a language-bearing component in an ST.96-compliant message or maintain the translation as an external derivative, depending on the project and office rules. That implementation must be verified against WIPO’s authoritative data dictionary, schema package and any local implementation profile. A sidecar’s well-formed JSON does not prove the XML exchange is correct. Keeping these validation boundaries explicit protects both technical trust and legal provenance.
How to review technical numbers and relationships
Create an invariant register from the original abstract. Record every number, unit, range, chemical formula, reference numeral and expressed relationship. If the source says a sensor operates from ten to thirty degrees Celsius, verify the target expresses the same inclusive or exclusive range where stated. A translation that writes “above thirty” instead of “up to thirty” changes the operating envelope. Keep original numeric values visible during review rather than asking a linguist to remember them from prose.
Decimals and separators are another source of risk. Target-language typography may display a decimal comma, but the underlying numerical meaning must remain the same. For a machine-readable patent exchange, numeric fields should follow their schema and office conventions, not localized prose habits. A human-readable editorial translation may present a familiar separator if it cannot be mistaken for a list delimiter. The reviewer should check both the code representation and the visible number, especially in measurement ranges with several comma-separated values.
Chemical names can require specialized terminology and symbols. A molecular formula is not an ordinary sentence and should not be translated by changing element symbols. Likewise a reference numeral such as “valve 12” relates the sentence to a drawing and must still point to the same component. A domain expert should check whether the target language preserves a term’s breadth. If the description uses “polymer” broadly, translating it as a named polymer without evidence narrows the invention. If a material is expressly limited, replacing it with a general category may overstate scope.
The reviewer should also test negation and modality. “Does not require an external supply” is not the same as “does not use an external supply.” “Can be configured” is not the same as “is always configured.” Use a two-case truth test for each logical sentence: name a scenario where the source statement is true and one where it is false, then see whether the target sentence yields the same result. This catches subtle changes that a sentence-level similarity score may miss.
Failure mode: bibliographic identity is translated as prose
A translator sees a country code, publication kind code or application identifier near the abstract and rewrites it into a target-language phrase. The resulting document may be impossible to match with an official record or may no longer validate. A casual reader could assume the localized label is harmless because it resembles a human-readable name. The diagnostic is a field-by-field comparison of the source and candidate XML, with identifiers and schema names excluded from the translation allowlist.
The repair is to restore the exact source identifiers and provide localized explanations in display components or approved narrative fields. If a document already circulated with modified identifiers, it should be quarantined for review rather than treated as a valid office record. Trace which systems consumed the incorrect values and whether any citations or imports now point to the wrong publication. Translation is not a mechanism for changing legal identity.
Failure mode: qualifiers broaden or narrow the invention
A source abstract says a system contains “one or more” valves, but the target says it contains “several” valves. The translated text implies more than one in ordinary usage. Or a source says a filter “may include” a particular coating, while the target states it “includes” it without qualification. Both changes alter the described set of devices. The diagnostic is to highlight quantifiers and modal verbs across the source and target, then test boundary cases with a domain reviewer.
The repair is to choose target constructions preserving the logical conditions, even if they sound less elegant. A patent translation is not an advertising rewrite. It should remain readable while allowing a technically competent reader to distinguish optional, necessary and example components. Where the source itself is ambiguous, record the ambiguity and seek authorized clarification rather than invent a confident interpretation.
Failure mode: component numbers drift between text and figures
A patent abstract refers to a chamber as component 14 in the drawing. A translation accidentally refers to chamber 41 or describes a different part because its local name is similar. The prose can remain plausible, especially in a device with several chambers. The diagnostic is a cross-reference table pairing each source numeral with a source term, target term and figure location. A reviewer should be able to follow the relationship without relying on memory.
The repair is to correct the reference, recheck every occurrence of the component, and verify that all relationship statements still point to the same physical structure. Do not replace drawing numerals with target-language numbering styles or restart the numbering sequence. If a figure label itself needs translation, treat it as an associated artwork or formal-document task subject to the intended publication rules, not as a side effect of editing the abstract.
Failure mode: a patent family member is mistaken for the source
Two related publications share almost the same invention title. A translator receives an abstract copied from one while the project metadata names another. A terminology review may pass because the inventions are related, but the translation’s provenance is false. The diagnostic is to compare publication numbers, dates, kind codes and source checksums before work begins, then repeat the identity check at export. Similar titles are not sufficient evidence that two records are interchangeable.
The repair is to halt the affected derivative, identify its actual source, and decide whether a new translation is required. Keep a clear record of which translation belongs to which family member or amendment. If content has already been published as a research aid, label the provenance correction plainly and avoid silently swapping text under the old citation. The problem is record ownership, not merely a style inconsistency.
Failure mode: an XML schema is assumed from a namespace
A developer sees familiar ST.96 namespace strings and concludes a generated XML document is valid. But a namespace tells a parser how names are qualified; it does not prove that required elements, cardinalities, component versions and office constraints are satisfied. The resulting message can be rejected at an exchange boundary. The diagnostic is to identify the exact ST.96 schema release, validate with its official XSD set and run any receiving-office checks separately.
Repair the output using the approved implementation mapping rather than inventing nodes by analogy with HTML or generic XML examples. Track which schema errors were corrected and whether the transformed document still refers to the same original abstract. An XML tree might parse beautifully while a field sits in the wrong component or a required language marker is omitted. Format QA and linguistic QA must remain independent gates.
Failure mode: source uncertainty is translated into false certainty
A source abstract contains a term that might refer to two mechanisms, or a scan has a damaged word. A translation system may choose the more common meaning, producing a smooth technical sentence. That can be especially dangerous when the choice changes a physical component or condition. The diagnostic is to flag terms whose meaning cannot be resolved from the abstract alone and consult the description, drawings, claims or authoritative family record.
When ambiguity remains, use a carefully documented neutral translation or an editorial note appropriate to the product. Do not alter an official filing simply to clarify a modern reader’s question. The QA report should say what evidence was available, which possible readings were considered and why the chosen phrase was approved. Transparency can be more useful than an unqualified assertion of accuracy.
A reliable translation and validation pipeline
Begin with source selection. Obtain the exact patent XML and accompanying material from an authoritative channel, identify its ST.96 release and office profile, and record identifiers and checksums. Decide whether the output is an internal research translation, a public explanatory derivative or a formal submission. This choice determines the approval path. Record an out-of-scope list for bibliographic identifiers, dates, codes, element names and unrelated legal status data. The resulting translation queue should contain only explicitly approved narrative content.
Build a terminology sheet from the abstract and enough supporting disclosure to understand its mechanism. Include quantities, compounds, components, actions, qualifiers, dates and figure references. For each target-language draft, compare those invariants manually or with an assisted diff. A machine translation model can accelerate wording suggestions, but it must not make unreviewed decisions about legal quantifiers or claim scope. In high-stakes contexts, a second technically qualified reviewer should evaluate the final translated text independently.
Next, validate technical packaging. If producing only an editorial sidecar, verify its schema and references and clearly label it non-official. If producing ST.96 XML, validate the message against the exact WIPO XSD release and applicable office business rules; confirm that non-translatable fields are unchanged and that language metadata is correct. Repeat identity checks after any transformation. A test harness should include an invalid schema fixture to prove that rejection works rather than trusting a pipeline that always returns a green result.
Then perform reader-facing review. Display the target abstract beside the source, show the corresponding figure where available and ask the reviewer to reconstruct how the invention works. A clear translation should preserve what is novel or claimed without exaggerating scope, hiding uncertainty or introducing marketing language. Read it aloud in the target language if the product will use speech, but keep the written technical wording as the audit reference. Finally, archive the reviewed version, source digest, glossary and decision log so a later correction can be traced and reversed.
Changed-context transfer exercise: a chemical filtration device
A fictional patent abstract describes a filtration device containing at least one replaceable membrane, a valve upstream of the membrane and an optional sensor that measures pressure. The document’s drawings identify the membrane as 10 and the valve as 12. The target-language draft says the device has multiple permanent membranes, describes the valve as downstream, and treats the sensor as mandatory. The JSON review sidecar is syntactically valid and its publication identifier matches the source. Determine whether the translation should pass and what evidence is needed to repair it.
The answer is no. Structural integrity of the sidecar does not repair changes in technical meaning. “At least one” allows a single membrane; “multiple” excludes that case. “Replaceable” does not mean permanent. Upstream and downstream reverse the spatial or flow relation, and the optional sensor has become a required feature. A reviewer should compare each target phrase with source wording and the figure, restore the logical conditions, then record a corrected glossary entry. The figure references 10 and 12 must remain attached to the correct parts.
Now transfer the method to a software patent in which a process may cache one or more results before performing a verification step. The precise words differ, but the same QA principle applies: preserve cardinality, optionality, sequencing and identity. A translation that says “always caches all results after verification” could invert the described method. The reviewer should draw a state diagram and test a case with no cache, one cached result and several cached results, depending on what the source actually permits. The exercise works because its diagnostic focus is on logical relationships, not on a memorized glossary.
Practical review checklist
- Obtain the exact authoritative patent XML, source abstract and relevant supporting materials.
- Record publication and application identity, kind codes, dates, jurisdiction and source version.
- Confirm the applicable ST.96 10.0 or office-specific schema package before exchange.
- Freeze IDs, namespaces, component names and nontranslatable bibliographic fields.
- Create a concept-based glossary with technical and negative examples.
- Compare quantifiers, modality, ranges, units and figure references line by line.
- Distinguish official source text from editorial and office-supplied translations.
- Parse and schema-validate resulting XML where the delivery requires it.
- Run receiving-office business rules separately from generic XML validation.
- Preserve source digest, translator decision log, reviewers and corrected revisions.
- Keep formal filing approval with the responsible legal and technical professionals.
Limits of the workflow
This article is not a patent-filing manual, a guarantee of legal equivalence or a substitute for local procedural advice. The correct language and required scope of a formal translation depend on the jurisdiction, stage of proceedings and governing rules. A technically accurate abstract translation may not be legally sufficient for national-phase entry, amendment or litigation. Offices can also use different versions or implementation profiles of ST.96. Always verify requirements for the actual intended transaction.
An XML validator cannot decide whether a translator changed the scope of a scientific statement. A linguistic reviewer cannot establish schema conformance by reading a rendered page. A checksum cannot prove the source was authoritative unless its provenance is trusted. These are different assurance layers, and none should be claimed merely because one automated test passed. The practical benefit of the workflow is that each layer has a named owner, inspectable evidence and a repair route.
Summary: make the abstract readable without changing the record
Reliable WIPO ST.96 patent-abstract translation starts with document identity and technical meaning. Freeze the official record, translate the appropriate narrative, preserve quantities and relationships, validate the intended technical format and state the translated text’s authority accurately. A fast translation that loses a quantifier, component reference or source identifier is not a useful shortcut. A carefully reviewed derivative helps readers understand an invention while leaving the filing evidence available for inspection.
Use negative examples to protect technical breadth
A terminology sheet is most reliable when it says not only what a target word means but also what it must not imply. Consider an abstract describing a coating “configured to resist moisture.” One candidate translation describes a waterproof barrier; another describes a coating that reduces exposure to moisture. Those statements may differ in strength. The source does not necessarily promise absolute impermeability. A reviewer should ask what physical test or threshold the original phrase commits to, then reject a target phrase that claims more than the source supports. The same method applies to “substantially,” “selectively,” and “responsive to,” which sound like ordinary prose but can determine technical interpretations.
Negative examples also help prevent inconsistent treatment of singular and plural. Some languages express number differently from English, and grammatical singular does not always have the same logical force as “one and only one.” A translator should keep track of explicit numerical conditions independently from grammar. If the abstract describes a plurality of channels and later refers to “a channel,” the intended reference may be to an individual member of that plurality. The reviewer should reconstruct the component model from surrounding disclosure instead of assuming every article or classifier defines a new component. When necessary, a professional with technical subject-matter knowledge should settle the ambiguity.
An illustrative rejection test can compare three target interpretations of a fictional device: one sensor required, one sensor optional, and exactly two sensors required. The original says “at least one sensor may be coupled to the housing.” A faithful target must preserve the possibility that a sensor is absent and, when present, that one or more may be coupled, subject to the precise syntax of the source. If the source itself is legally or technically ambiguous, record that uncertainty rather than pretending a truth table can resolve drafting intent without expert review. The point of the test is to expose where translation has introduced certainty that was not there.
Protect cross-language search without rewriting publication data
Patent archives are searched using a mixture of formal identifiers, technical classifications and natural-language queries. A multilingual discovery system may want to index an editorial translation of an abstract beside the original. That is useful, but the translated wording must be labeled so that a search hit does not imply the target-language phrase appears in the original filed document. Store the language, source abstract reference and editorial status with each indexed field. A result card should distinguish official publication data from machine-assisted or human-edited translations, especially when the search term has several possible equivalents.
A technical term can have synonyms across languages, and one source concept might be expressed by a phrase rather than a single target word. A retrieval system can maintain multilingual synonyms and concept mappings in the search layer; it should not alter publication numbers or overwrite the original abstract to make queries easier. When a search result is opened, let readers inspect the source alongside the translation and the provenance note. This is more defensible than silently replacing the official record with whichever translation happened to rank best in a search engine.
The QA team should measure the intended reader job rather than claim that every translation improves SEO. A useful acceptance test asks a reader to find the correct fictional invention using a target-language description, verify that the result links to the right publication, and distinguish an editorial abstract from a certified office version. Another test uses two related family members with similar titles to catch cross-record contamination. Those tests address discovery integrity, not popularity or ranking forecasts. They help ensure that accessible language and reliable patent identity reinforce one another.
Frequently asked questions
Is ST.96 a machine translation system?
No. It is a structured XML standard for intellectual-property information. Translation is a separate language and editorial workflow that may use ST.96 components as source or output.
Is ST.96 10.0 the only version an office can accept?
No. The relevant receiving office or exchange arrangement may use a different release or local implementation. Verify the specific version before preparing deliverables.
Can an abstract be translated without the claims?
It can be drafted, but terminology and scope review often require context from the claims, description and figures to avoid changing technical meaning.
Are publication numbers and kind codes translatable?
No. They identify records and should remain unchanged. Display explanations can be localized separately.
Why do words such as “at least” matter so much?
They define logical boundaries. “At least two” includes exactly two, whereas “more than two” does not. The target must preserve those truth conditions.
Does valid XML prove that the invention was translated accurately?
No. XML validation establishes structural requirements. Technical semantic review is a different task and must be documented separately.
Can the example JSON sidecar be submitted as ST.96 XML?
No. It is explicitly an editorial review fixture, not an ST.96 instance or an office filing message.
What should happen when a source term is ambiguous?
Consult related disclosure and authoritative records, document uncertainty, and seek qualified review rather than inventing an unqualified target meaning.
Is a translated abstract automatically an official patent text?
No. Authority depends on its origin and the applicable procedural rules. An editorial derivative should be labeled as such.
Can machine translation be used as a first draft?
Yes, with appropriate confidentiality controls and expert review of logic, terminology, numbers, relationships and provenance before use.
Authoritative sources
- WIPO ST.96 Version 10.0 annexes — applicable international data model materials.
- WIPO ST.96 10.0 Annex III patent XML schemas — official schema release approved 1 April 2026.
- WIPO ST.96 10.0 schema technical specification — schema implementation reference.
- WIPO Pearl multilingual technical terminology — terminology search and specialist concepts.