One experimental heuristic encoded in this project was that x uco-action:results y would imply y prov:wasGeneratedBy x.
I now think this only holds in specific cases, such as where it is also asserted that x a case-investigation:InvestigativeAction and y a case-investigation:ProvenanceRecord. This is tangentially related to CASE Issue 136.
I now think other generation links need to be separately asserted.
One data-driven reason this arose is considering an object that could be encountered multiple times, such as an email address using a content-derived IRI (e.g., an IRI derived from hashing the uco-observable:fullValue).
The data-driven reason leads to a larger philosophical reason this mindset-change arose: that actions will often has as results objects that they do not create, but instead merely encounter. Given a fixed-contents .eml file, email address graph-objects might be created from the from: and to: headers; but, the actual email addresses those objects notate are encountered, not created.
One experimental heuristic encoded in this project was that
x uco-action:results ywould implyy prov:wasGeneratedBy x.I now think this only holds in specific cases, such as where it is also asserted that
x a case-investigation:InvestigativeActionandy a case-investigation:ProvenanceRecord. This is tangentially related to CASE Issue 136.I now think other generation links need to be separately asserted.
One data-driven reason this arose is considering an object that could be encountered multiple times, such as an email address using a content-derived IRI (e.g., an IRI derived from hashing the
uco-observable:fullValue).The data-driven reason leads to a larger philosophical reason this mindset-change arose: that actions will often has as results objects that they do not create, but instead merely encounter. Given a fixed-contents
.emlfile, email address graph-objects might be created from thefrom:andto:headers; but, the actual email addresses those objects notate are encountered, not created.