Choose the observation before choosing columns
Define a consistent observation so the spreadsheet supports review instead of requiring another round of restructuring.
Our public material-register example shows a synthetic report beside downloadable output. Use it to inspect how values and source references travel together. The self-service ParseMill trial is for invoice PDFs; supplier test reports and engineering review need a separate fit discussion.
Keep report-level context separate but linked. Report number, revision, issuer and batch may apply to several observations, while results and methods may vary by row. Do not collapse these different scopes into a single unstructured description field.
Map an invented source table
| Observation key | Sample | Test | Result | Unit | Method |
|---|---|---|---|---|---|
| R61:S1:T1 | S1 | Length | 12.4 | mm | Method L, rev2 |
| R61:S1:T2 | S1 | Mass | 8.2 | g | Method M, rev1 |
| R61:S2:T1 | S2 | Length | 12.7 | mm | Method L, rev2 |
The synthetic register contains three observations, not two sample rows. Each result remains attached to its test and unit. Report R61’s issuer and revision belong in a linked context record. If the source reports a replicate, extend the observation identity rather than overwriting the first result.
W3C: RDF Data Cube Vocabulary distinguishes observation dimensions, measures and qualifying attributes. That model helps separate sample and test identity from the reported value and its context.
Build the row mapping
- Inventory the source’s sample, test and condition headings. Write a sentence defining one destination observation before extracting values.
- Assign a stable internal observation key while preserving every supplier identifier as reported. Include source document and revision in the evidence relationship.
- Map result, qualifier, unit and method to each observation. Keep unknown context explicit and preserve the raw source statement.
- Reconcile destination observations with source cells or rows. Verify that a wide source row expanded into several observations without duplicating or losing a test.
W3C: Provenance model primer records derivation relationships. Keep a mapping from each register observation to the source location that produced it.
Handle exceptions without changing the model silently
A qualitative result such as Present can occupy the result field as text, with a clear result type. A range or less-than value needs its qualifier preserved. A missing test result should remain an explicit state when the source or expected scope requires that observation to be represented.
Do not average repeated tests merely to achieve one row per sample and test. Add a replicate or source-observation dimension when the source contains distinct observations, and keep any summary in a separate derived view.
Check a useful register outcome
For the fixture, S1’s length and mass remain separate, and S2’s length cannot inherit S1’s mass or method accidentally. A reviewer can locate each observation in Report R61 and understand the linked report context. Check that the internal keys remain unique after exporting and reopening the register.
Bring this observation model and a representative supplier report to a scoped workflow discussion. Use the public material example to inspect the source-and-output format first. A wider pilot should agree the required row structure, review work and fee before proceeding.
Put it to work with ParseMill
Check the example against the work you need done
Compare the synthetic report, extracted rows and source references. For your own supplier reports, discuss the document type and review requirements before agreeing to a pilot.
Also working with supplier invoices? Try the invoice-to-Excel workspace. Any wider document pilot needs an agreed scope and fee.
Invoice processing: $49 USD/month · 500 PDF pages · one user. Buy only after you have checked the fit on your own invoices.
Sources and editorial notes
- W3C: RDF Data Cube VocabularyChecked 2026-10-25
- W3C: Provenance model primerChecked 2026-10-25
Written by ParseMill. Worked examples are illustrative process examples, not customer results. Software availability can vary by subscription and region; check the linked documentation for your account. Review decisions and approvals remain with your team.