{"id":"226bcb0a-6309-4ff4-8c58-fdf42c5df11f","arxiv_id":"2607.27840","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A knowledge-graph data catalog that ties manufacturing sensor datasets to the workflow steps that produced them, using an alignment of DCAT, PROV, SSN/SOSA, and WiLD ontologies.","lead":"This paper presents the Virtual Process Dossier (VPD), a knowledge-graph-based data catalog that links sensor datasets to the steps of a multi-stage manufacturing workflow using FAIR metadata. It combines four existing ontologies—DCAT, PROV, SSN/SOSA, and WiLD—to record both the planned workflow and what actually happened during each production run.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"WiLD state semantics are not honored in VPD-O instantiation: sensor activity instances are typed as sosa:Observation/prov:Activity without wild:state wild:done, breaking the provenance chain.","rationale":"The reader's weakest assumption pinpoints the same WiLD state-semantics issue, and my reading of §4.2.1, footnote 5, and the §5.2.1 SPARQL template confirms it. This is the most load-bearing concern because the paper's central claim is that VPD captures workflow provenance by linking datasets to the activity instances that generated them. If the linked instance is not entailed as a prov:Activity, the prov:wasGeneratedBy triple is semantically invalid, so the provenance claim fails. The issue is easily fixable by adding wild:state wild:done, so a conditional-accept verdict with a required fix is appropriate. Other issues (e.g., using dcat:theme for a non-concept resource, lack of FOOPS! output) are secondary and do not change the verdict.","tokens_in":12045,"tokens_out":7575,"duration_ms":64242,"concrete_test":"Execute the SPARQL/Update template from §5.2.1 on a triple store loaded with WiLD, SOSA, and VPD-O axioms; then query for `?instance a prov:Activity` after applying WiLD's state-based inference. If the instance is not entailed as prov:Activity (or the reasoner reports an inconsistency), the template is missing the required state assertion and the provenance graph is incomplete. Also run the same check with an explicit `wild:state wild:done` triple to confirm it resolves.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim relies on linking each dataset to the specific activity instance that generated it via prov:wasGeneratedBy. VPD-O declares vpd:SensorActivityInstance a subclass of both wild:ActivityInstance and sosa:Observation. However, WiLD's semantics (per footnote 5) make wild:ActivityInstance a prov:Activity only when its state is wild:done. The SPARQL template in §5.2.1 and the example in §4.2.1 instantiate vpd:SensorActivityInstance without asserting wild:state wild:done, and they also do not set it to wild:running or any other state. Consequently, under WiLD's semantics, the instance is not a prov:Activity, so the triple `<D> prov:wasGeneratedBy <A>` is not a valid PROV generation from an activity. This undermines the FAIR provenance claim and makes the example graph inconsistent with the referenced ontologies. The fix is straightforward (add wild:state wild:done in the template and example), but as written the central provenance chain is not semantically grounded.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes the Virtual Process Dossier (VPD), a knowledge-graph-based data catalogue for multi-stage manufacturing environments. The VPD ontology aligns DCAT, PROV, SSN/SOSA, and WiLD to link sensor datasets to specific workflow instances and activity instances, thereby capturing both prospective and retrospective workflow provenance. The paper also contributes a framework for instantiating the ontology in production environments and a user interface for browsing and updating the resulting knowledge graph. The approach is illustrated with a running example of a two-step manufacturing process for fiber-reinforced plastic parts. The authors claim that VPD makes manufacturing sensor data FAIR by providing findable, accessible, interoperable, and reusable metadata with explicit provenance.","tokens_in":12375,"tokens_out":5962,"duration_ms":58100,"significance":"If the semantic issues are resolved, this is a useful contribution to industrial data management and provenance research. The reuse of published and standardized ontologies (DCAT, PROV, SSN/SOSA, WiLD) is good practice, and the open-source availability of the ontology and UI is commendable. The paper addresses a real gap: generic data catalogues do not capture stage-specific workflow provenance, which is essential for downstream AI-based optimization. The explicit alignment between sensor observations and workflow activities is a promising idea. However, the paper's central provenance claim is currently weakened by an underspecified and partly inconsistent instantiation semantics, and the FAIR claim lacks direct substantiation. The strengths of the design and its potential applicability justify further work, but the manuscript needs revision before it can be accepted.","major_comments":[{"comment":"The central provenance chain is not semantically grounded as written. The paper's footnote 5 states that a wild:ActivityInstance represents a prov:Activity only when its state is wild:done. However, the sensor-activity example in §4.2.1 and the SPARQL/Update template in §5.2.1 instantiate vpd:SensorActivityInstance without asserting wild:state wild:done. Under WiLD's semantics, the instance is therefore not a prov:Activity, so the triple `<D> prov:wasGeneratedBy <AI_a>` is not a valid PROV generation from an activity. This is load-bearing because the paper's main contribution is precisely linking datasets to the specific activity instance that generated them. The fix is straightforward—add wild:state wild:done to the template and examples—but without it the example graph is inconsistent with the referenced ontologies.","section":"§4.2.1, footnote 5; §5.2.1"},{"comment":"The class hierarchy itself needs clarification. vpd:SensorActivityInstance is declared a subclass of both wild:ActivityInstance and sosa:Observation. Since sosa:Observation is a subclass of prov:Activity (via the SSN/SOSA PROV alignment), any instance of vpd:SensorActivityInstance is unconditionally a prov:Activity. Yet WiLD's state semantics, as acknowledged in footnote 5, make wild:ActivityInstance a prov:Activity only when wild:state wild:done. These two constraints are in tension. The authors should either restrict the subclass relationship (e.g., make vpd:SensorActivityInstance a subclass of wild:ActivityInstance only when done, or model the state explicitly as a necessary condition) or clarify that WiLD's 'only when' is not a formal necessary condition for the class. As it stands, the alignment is under-specified and could allow inconsistent entailments.","section":"§4.2.1, Fig. 3"},{"comment":"The paper repeatedly claims that VPD 'provides datasets in a FAIR manner,' but no direct evidence is presented. The ontology engineering section mentions the FOOPS! tool, yet no results are reported, and no systematic mapping of the design to the FAIR principles is given. Given that FAIRness is a central advertised contribution, the authors should either include a concrete FAIR assessment (FOOPS! output, or a principle-by-principle mapping with justifications) or temper the claim to 'supports FAIR metadata' rather than asserting full compliance.","section":"§1, §4.1"}],"minor_comments":[{"comment":"The sensor activity instance is typed as wild:SensorActivityInstance, but the ontology introduces vpd:SensorActivityInstance as the dedicated class. This is presumably a typo and should be corrected to vpd:SensorActivityInstance; otherwise the example does not demonstrate the VPD ontology.","section":"§4.2.1, line 4 of the example"},{"comment":"The SHACL snippet uses the prefix fofa: (e.g., fofa:pressForce) without declaring it. This makes the example not machine-readable and unclear. Either declare the prefix or use a fully specified IRI.","section":"§4.2.2, SHACL example"},{"comment":"The Turtle snippets are typeset with spaces between letters (e.g., 'wild : W o r k f l o w M o d e l'), which is unusual and reduces readability. Using a standard monospaced code style would make the examples easier to parse.","section":"Throughout"},{"comment":"The SPARQL/Update template inserts the dataset and provenance in a single INSERT DATA block. If the sensor reading is collected before the activity is completed, the state should be set to wild:running initially and updated to wild:done later. The framework should specify when the state transition occurs, especially since the paper emphasizes an event-driven approach.","section":"§5.2.1"},{"comment":"The conclusion claims the approach scales to 'manufacturing workflows of arbitrary complexity', but no complexity analysis or experimental validation is provided. A short discussion of limitations or future evaluation would be appropriate.","section":"§8"}],"recommendation":"major_revision","confidential_remarks":"The paper's reuse of WiLD, co-authored by the senior author, is a self-citation but does not appear to be a circularity problem: the contribution is the VPD-O alignment and framework, not the WiLD ontology itself. The main issue is the missing wild:state wild:done in the instantiation examples, which directly affects the correctness of the provenance graph. The fix is local and does not change the overall architecture, so I see no reason for rejection; a major revision is appropriate to resolve the semantic inconsistency and provide at least a minimal FAIR evaluation."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The thing to know: this is a design paper, not a demonstration paper. The genuinely new piece is VPD-O, an alignment that combines the WiLD tree-based workflow ontology with DCAT catalogs and SOSA observations so each manufacturing sensor dataset can be tied to the exact activity instance that generated it. No prior work does that for physical multi-stage manufacturing. The related-work discussion is honest and useful, especially the comparison to PKO and D-PROV. The framework is clearly structured, the UI is open source, and the ontology/code are on GitHub, which is more than many papers in this space ship.\n\nThe soft spots are real but mostly addressable. The stress-test note is correct. Footnote 5 says a WiLD ActivityInstance is a PROV activity only when its state is wild:done, yet the sensor-activity example and the SPARQL insert template in 5.2.1 instantiate a vpd:SensorActivityInstance without asserting any wild:state. Since that class is a subclass of both wild:ActivityInstance and sosa:Observation, the instance is not yet a prov:Activity under the cited semantics, which makes the prov:wasGeneratedBy link from the dataset dangle. The fix is small—set wild:state wild:done—but as written the central provenance chain is not semantically grounded. There is also an undeclared fofa: prefix in the SHACL example, and the FOOPS! evaluation mentioned in 4.1 is never reported. No user study, no integration test, no performance numbers. These are addressable, but they mean the FAIR claim is asserted, not demonstrated.\n\nThe citation pattern is fine. WiLD is a self-citation of a senior author, but it is an independent, published ontology with executable semantics, and the contribution here is the alignment itself, not the workflow model. The circularity concern does not land.\n\nBottom line: this deserves a serious referee. It needs a semantics fix, clean machine-readable examples, and at least one real instantiation with a query result before the FAIR claim can stand. As a design proposal with a novel alignment and a clear application, it is worth reviewer time, not desk rejection.","headline":"A solid ontology-alignment design for process-aware manufacturing catalogs that deserves referee time, but the state-semantics gap and lack of evaluation need to be fixed before the FAIR claim rests.","tokens_in":12853,"tokens_out":3088,"would_cite":false,"duration_ms":31757,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The VPD data catalog makes manufacturing sensor data FAIR by linking each dataset to the exact workflow step and observation that generated it.","keywords":["data catalog","workflow provenance","FAIR data","knowledge graph","ontology alignment","sensor observation","Industry 4.0","manufacturing"],"falsifier":"Run the paper's SPARQL/UPDATE template for a sensor activity onto a triple store with the WiLD and SSN/SOSA ontologies loaded, then query whether the inserted activity instance is entailed to be a prov:Activity; if it is not (because the instance's state is missing or not set to wild:done) or if it violates SOSA's observation constraints, the VPD alignment is inconsistent and the provenance graph it produces is not sound.","tokens_in":11980,"feed_emoji":"🏭","tokens_out":4418,"duration_ms":41299,"temperature":0.7,"pith_summary":"The paper proposes the Virtual Process Dossier (VPD), a knowledge-graph data catalog that captures both the planned structure of a manufacturing workflow and the actual events of its execution. Its central claim is that by aligning four existing ontologies—DCAT for datasets, PROV for provenance, SSN/SOSA for sensor observations, and WiLD for workflow structure—each sensor dataset can be traced to the specific activity instance within a specific workflow run that generated it. This makes the data FAIR (findable, accessible, interoperable, reusable) in a way that generic catalogs cannot, and it directly answers questions like 'during which step was this recording captured?' The paper also provides a framework for automatically instantiating the knowledge graph during production, and a user interface for browsing and updating it. If right, it gives data scientists in multi-stage manufacturing a reliable way to select data by production step, machine, and parameter configuration.","feed_headline":"One ontology ties each sensor dataset to its exact workflow step","feed_subtitle":"VPD makes manufacturing data FAIR by linking datasets to the run, step, and observation that created them.","key_machinery":"The VPD-O ontology, a lightweight alignment layer that reuses WiLD's tree-based workflow model, PROV's activity and agent vocabulary, SSN/SOSA's observation structure, and DCAT's catalog and distribution classes. Its central element is the class vpd:SensorActivityInstance, defined as a wild:ActivityInstance and a sosa:Observation, which ties a discrete workflow step to a sensor reading and, through PROV, to the dataset that stores it. The ontology introduces only a few new classes—SensorActivity, MachineActivity, Machine, Parameterization, Product, Material—whose job is purely to align the four reused vocabularies.","core_discovery":"The core discovery is an ontology alignment that makes workflow provenance and sensor observation equivalent for the purpose of cataloguing datasets. VPD-O defines vpd:SensorActivityInstance as a subclass of both wild:ActivityInstance and sosa:Observation, so that an executed sensor activity is simultaneously a step in the workflow and an observation. Through standard subclass relations, this instance is also a prov:Activity, and a dcat:Dataset can be linked to it via prov:wasGeneratedBy. The same pattern is applied to machines: vpd:Machine is both a prov:Agent (responsible for activities) and a sosa:FeatureOfInterest (the thing sensors observe), and parameterizations are prov:Plans attached","pith_inferences":["The same alignment recipe—making an activity instance also an observation and an agent also a feature of interest—could generalize to other workflow-driven domains, such as scientific experiments or logistics, where sensor data needs to be tied to process steps.","One testable extension is to run a VPD instance on a real or simulated multi-stage production line and measure whether downstream AI models trained on provenance-filtered data outperform those trained on unfiltered data.","The paper leaves open how the catalog handles workflow evolution; a natural next step is adding explicit WiLD versioning or a new class for evolution provenance at the workflow-model level.","The catalog's value depends on every actor in the production environment actually possessing its assigned IRI; a field deployment could reveal how much manual setup this demands for heterogeneous legacy machinery."],"forward_implications":["Every sensor dataset in a VPD catalog carries an explicit link to the workflow instance and atomic activity instance that produced it, so 'which step was this data from?' becomes a single SPARQL query.","Because vpd:SensorActivityInstance is also a sosa:Observation, dataset provenance inherits the sensor, observed property, and feature of interest without extra modeling.","The WiLD/PROV bridge means prospective provenance (the planned workflow tree) and retrospective provenance (the actual run) are connected, so queries can compare what was supposed to happen with what happened.","Distribution metadata via DCAT gives each dataset a persistent, machine-readable location and download URL, satisfying the Findable and Accessible FAIR requirements.","The framework can be embedded in the manufacturing control system with a two-phase handshake that distributes IRIs before a run and inserts provenance via SPARQL/UPDATE during the run."],"fun_headline_variants":["One ontology ties every dataset to its workflow step","Sensor data gets a workflow home","Data catalogue maps each dataset to its exact process step","Provenance and observation unified in one ontology","Workflow steps and sensor data now speak the same language"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing premise is that an activity instance can be classified as both a WiLD activity instance (which only denotes a completed activity once its state is wild:done) and a SOSA observation at insertion time, without violating the semantics of either ontology.","fun_headline_variants_meta":{"raw":{"variants":["One ontology ties every dataset to its workflow step","Sensor data gets a workflow home","Data catalogue maps each dataset to its exact process step","Provenance and observation unified in one ontology","Workflow steps and sensor data now speak the same language"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000687,"raw_usage":{"total_tokens":2904,"prompt_tokens":649,"completion_tokens":2255,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":393,"completion_tokens_details":{"reasoning_tokens":2184}},"tokens_in":393,"tokens_out":2255,"duration_ms":14614,"temperature":1.0,"reasoning_tokens":2184,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T00:26:50.658369+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the paper's SPARQL/UPDATE template for a sensor activity onto a triple store with the WiLD and SSN/SOSA ontologies loaded, then query whether the inserted activity instance is entailed to be a prov:Activity; if it is not (because the instance's state is missing or not set to wild:done) or if it violates SOSA's observation constraints, the VPD alignment is inconsistent and the provenance graph it produces is not sound.","supporting_citations":[],"review_version":1}