0.12.0

New features:

• case-utils 0.16.0 is now adopted.

0.11.0

New features:

• case-utils 0.15.0 is now adopted.

0.10.0

This is a maintenance release, primarily issued to bump adoption of case-utils to 0.14.0 and incorporate a behavior change in handling SHACL Qualified Shapes.

The newest tested version of Python is now 3.12.

0.9.1

This is a maintenance release, not revising any user user-facing features or interfaces.

• "Supply chain" review was scheduled for nightly refreshes. This is now done instead as a pre-release check for this repository.
• The CASE-Examples repository now uses case-prov, so the dependency this repository had on CASE-Examples became circular, and is now removed.

0.9.0

New features:

• case-utils 0.13.0 is now adopted.

Requirement updates:

• The minimal required Python version is now 3.9.

Maintenance updates:

• CASE example data is now brought in through direct submodule tracking of CASE-Examples and the CASE website repository.

0.8.0

New features:

• case-utils 0.11.0 is now adopted.
• OWL-Time is now incorporated into the inferencing logic of case_prov_rdf and case_prov_dot, following the non-normative PROV-O alignment suggestions of OWL-Time Section 5.7. The case-prov README documents the illustration and inference effects.
  • To have time objects (time:Intervals and their boundary time:Instants) be visibly displayed, rather than only invisibly influencing layout, pass --display-time-links to case_prov_dot.
• Timestamps used on case-investigation:InvestigativeActions now have a visual timeline behavior in case_prov_dot.
  • Those timestamps can also be used for timelining analysis from time:Instants inferred by case_prov_rdf. For example, an investigative action that has a uco-observable:File as a result induces a time:Instant representing the instant the file was created, which might or might not eventually receive a timestamp in an analyst's workflow, but the timestamp is asserted to be time:before the ending time:Instant of the investigative action.
  • A caveat on timestamp ordering: Only timestamps with a timezone will be cast into time:inXSDDateTimeStamp. (At the time of the 2022-11-15 OWL-Time draft, time:inXSDDateTime is deprecated.) This is left to the user as a UCO data preparation responsibility. time:Instants will still be inferred and topologically linked for timestamps without timezones.
  • Another caveat on timestamp ordering: Currently, only timestamps with a timezone (i.e. ending with either +00:00 or Z) will influence timeline sorting by case_prov_dot. Help is welcome to implement general timezone sorting in a future case-prov release.
• On an investigative action, a uco-action:endTime timestamp is treated as a designation the action has an end. In general, an investigative action is not assumed to have an end, though all investigative actions are assumed to have a beginning.
• case_prov_dot and case_prov_dot now have some generated effects that can be influenced from UUID randomization. A flag --use-deterministic-uuids is now provided for these commands.
• Using the inherence functions from case-utils 0.11.0, prov:Influences (Association, Attribution, etc.) and prov:InstantaneousEvents (Generation, Start, etc.) are now handled in Python code rather than SPARQL CONSTRUCT queries. This is to avoid generating blank nodes, and to also incorporate run-time requests to use non-deterministic UUIDs or not (whether through inherence in case_utils.inherent_uuid, or the "demo" nonrandom UUIDs from case_utils.local_uuid).
• (Also a bug fix.) Node labels from case_prov_dot are no longer limited to a single label string (e.g. if there were two rdfs:comments, only one would display).
• Node labels from case_prov_dot now preserve the annotating predicate as part of the label's line ordering.
• case_prov_rdf now carries forward uco-core:description rather than casting its contents to an rdfs:comment.
• case_prov_rdf now carries forward uco-core:name, and case_prov_dot now displays it, for UCO nodes inferred to be prov:Activitys, prov:Agents, or prov:Entitys.

Maintenance updates:

• Documentation for modules now includes doctests (inlined code samples) for functions.
• case_prov is now type-reviewed with mypy --strict.
• The project's home page link from PyPI has been fixed.
• case_prov_dot's code flow has been nearly totally reordered and inline-documented.

0.7.0

New features:

• case-utils 0.10.0 is now adopted.
• case-prov now reviews data using CASE ontology version 1.2.0.
• Python 3.8 is now the earlist version of Python reviewed.

Maintenance updates:

• pre-commit module versions are now reviewed nightly.
• Some type signatures have been revised to accommodate a recent update in RDFLib.

0.6.0

New features:

• case-utils 0.9.0 is now adopted.
• case-prov now reviews data using CASE ontology version 1.1.0.
• Node IRIs are now shortened using prefixes defined in the graph (e.g. with @prefix statements in Turtle, and @context dictionary members in JSON-LD). This was previously done using a hard-coded prefix, but now uses the qname built into RDFLib's NamespaceManager.
• The mappings for the CASE properties investigation:wasDerivedFrom and investigation:wasInformedBy now also generate class assertions for the subject and object of each triple - prov:Entity and prov:Activity, respectively.

Test updates:

• Python 3.11 is now the latest version of Python reviewed.
• The examples review now includes synchronization code to ensure new tests added to CASE-Examples or the CASE website are reviewed as part of case-prov CI.
• Examples' PROV-O mappings have been regenerated to reflect many node IRI updates throughout CASE-Examples and the CASE website.
• pre-commit has been refreshed.
• case_prov_* Python tools now use the RDFLib PROV DefinedNamespace to catch concept IRI typos.

0.5.0

New features:

• case-utils 0.7.0 is now adopted. case-prov now reviews data using CASE ontology version 1.0.0.

0.4.0

New features:

• case_prov_check has been added to review graphs mapped from CASE to PROV-O.
  • Breaks in the chain of custody are treated as sh:Warning-severity violations (i.e. will raise a validation error, but can be accepted for passing validation with --allow-warnings).
  • Incorrect usage of PROV concepts, according to OWL disjoint-class statements, is now checked and treated as a sh:Violation-severity violation (i.e. will raise a validation error).