Repository navigation
What do you use for 'Case number' in typical imaging tools? #191
Description
Activity
We need a caseNumber property on the CASE Investigation class. We also need a mechanism to show relationships between investigations with different case numbers.
Ok in some ways I'm glad it's missing, not that I couldn't find it.
@prosch88 Not sure if you hit this too with your CASE/UCO output from ALEX/UFADE
Change proposal written with the assistance of AI in response to the question opening this issue. The example graph and SPARQL queries below are CASE SHACL validated (see Pre-submission testing).
Target release
Target: CASE 1.5.0
Background
The question opening this issue — what does "Case number" from a typical imaging tool map to? — currently has no good answer, and the gap is deeper than one property:
-
No case number property.
investigation:InvestigationhasinvestigationForm,investigationStatus, andfocus, but no identifier property. Adjacent terms don't fit:investigation:exhibitNumberidentifies evidence items, not cases;uco-core:nameis a display name, not an identifier;uco-identity:IdentifierFacetis scoped to identities ("uniquely and specifically identifies an entity" withinidentity:Identity);uco-core:externalIdentifierhas the right semantics ("an identifier for some information defined external to the UCO context") but is generic, undiscoverable, and not associated withInvestigationin any shape or documentation — which is why tool authors end up asking this question. -
No mechanism for relating investigations that carry different case numbers. Real matters routinely span organizations, each of which opens its own case. A concrete ICAC example:
- A technology platform's trust & safety team opens internal case
TS-2026-88041, - files a NCMEC CyberTipline report, which receives report ID
CT-2026-1234567, - NCMEC routes it to a state ICAC task force, which opens case
ICAC-AK-2026-0113, - the task force refers it to a local police department, which opens case
2026-004567, - local police seize an encrypted smartphone and submit it to the state crime laboratory, which opens lab case
SCDL-26-0892.
Five organizations, five case numbers, one investigative continuum. Today CASE cannot express that these cases are related, in what way, or in what direction — so a graph assembled from all five organizations' records (exactly the cross-tool interchange CASE exists for) cannot be traversed from CyberTip to lab report.
- A technology platform's trust & safety team opens internal case
The same pattern appears far beyond ICAC: incident response cases escalating to regulator cases, corporate internal investigations referred to law enforcement, task-force cases spawning per-defendant prosecutions, lab submissions, and mutual legal assistance requests between jurisdictions.
What we achieve for whom and why it matters: Tool authors get a direct, documented answer for the ubiquitous "Case number" field; investigators and analysts get a standard way to stitch multi-agency case chains into one traversable graph; and application-domain ontologies (CAC Ontology and others) inherit both concepts from CASE instead of minting their own — the CAC Ontology has already had to propose a local
cacontology:caseNumber(CAC-Ontology #41) precisely because CASE offers no term to inherit.Relationship to other proposals: This complements the three legal process and procedure namespace proposals (#192 criminal, #193 civil, #194 corporate): case numbers identify matters in all three arenas (police case numbers, court dockets, corporate matter numbers), and a #194
Referralhanding a corporate matter to law enforcement is exactly the event that produces a related investigation with a new case number. It is orthogonal to #138 (Investigation as Event specialization) and to #189 (process meta-model), both of which would benefit from — but do not conflict with — these terms. UCO #554 (work ticket concept) covers the analogous ticket-number pattern for help-desk workflows and could align with the sameexternalIdentifiergrounding.Requirements
Requirement 1 —
investigation:caseIdentifierAdd a datatype property to the
investigation:namespace:- Name:
caseIdentifier(suggested;caseNumberis the colloquial term but many systems issue non-numeric identifiers) rdfs:subPropertyOf uco-core:externalIdentifier— inheriting UCO's identifier semantics: the value is assigned by a case-management authority external to the graph- Domain:
investigation:Investigation(via SHACL property shape on theInvestigationshape; multiple values permitted, since one organization may assign several identifiers to one case) - Range:
xsd:string
This directly answers the mapping table in the opening comment:
Imaging tool field CASE/UCO term Case number investigation:caseIdentifier(proposed) on theinvestigation:InvestigationnodeDescription uco-core:descriptionEvidence number investigation:exhibitNumberExaminer name uco-core:nameon theinvestigation:Examinerrole / identityNotes uco-observable:NoteRequirement 2 — Related-investigation representation
Standardize how investigations with different case identifiers are related, using the existing
uco-core:Relationshipmachinery rather than new object properties:- Document (and optionally subclass) the pattern: a
uco-core:Relationshipwhosesourceandtargetareinvestigation:Investigationnodes. - Recommend an open vocabulary for
uco-core:kindOfRelationshipbetween investigations, e.g.:Referred_To(matter handed to another organization),Escalated_To,Spawned(parent case opens child case, e.g. per-defendant prosecutions),Merged_Into,Parallel_To(concurrent related cases),Evidence_Submitted_To(lab submission),Successor_Of. - Optionally, add
investigation:InvestigationRelationship rdfs:subClassOf uco-core:Relationshipwith SHACL constrainingsource/targettoinvestigation:Investigation, so tools can find inter-case links without inspecting every Relationship. The committee may prefer the documentation-only variant; either resolves the gap. The example below uses the typed subclass.
Requirement 3 — Non-prescriptive and inheritable
Both terms carry no workflow or jurisdictional commitments. Application-domain ontologies specialize them, e.g.
cacontology:caseNumber rdfs:subPropertyOf investigation:caseIdentifier(re-parenting the CAC-Ontology #41 proposal), or a lab-domain ontology declaringlab:SubmissionRelationship rdfs:subClassOf investigation:InvestigationRelationship.Risk / Benefit analysis
Benefits
- Answers a real, recurring tool-mapping question — the imaging-tool field prompting this issue is present in essentially every acquisition and case-management tool (FTK Imager, Cellebrite, Magnet AXIOM, lab LIMS).
- Multi-agency traversal — one SPARQL query walks the CyberTip-to-lab chain across five organizations' graphs.
- Grounded in existing UCO semantics —
caseIdentifierrefinesuco-core:externalIdentifier; relating investigations reusesuco-core:Relationship. Minimal new surface area. - Stops downstream forking — CAC-Ontology Ont 251 #41 already had to propose
caseNumberlocally for want of a CASE parent; other domain ontologies will follow. - Composes with the 1.5.0 agenda — investigator roles (Addition of Investigator Subclasses #178/Issue 178 addition of CASE investigation:Investigator subclasses #183/Add Analyst Role to CASE #187), legal process namespaces (Add Criminal Process and Procedure Namespace (Stub Concepts) #192–Add Corporate Process and Procedure Namespace (Stub Concepts) #194), and the Adopting CASE Investigation Ontology by Communities with Defined Business Rules #189 process meta-model all produce or consume case identifiers and inter-case links.
Risks
- Naming:
caseIdentifiervscaseNumber. Mitigation: committee choice; askos:altLabel "case number"preserves findability either way. - Property proliferation on
Investigation: one property, subproperty of an existing core term — minimal. - Vocabulary drift in
kindOfRelationshipvalues between investigations. Mitigation: publish the recommended values as a semi-open vocabulary (the same approach asInvestigationFormVocab), leaving room for domain values. - Overlap concern with
uco-identity:IdentifierFacet: that facet identifies identities; a case identifier identifies a compilation of investigative context. Documentation should state the distinction (it is the very confusion the opening comment raises). - The submitter is unaware of other risks.
Competencies demonstrated
Competency 1
Scenario: The five-organization ICAC chain above: platform trust & safety case
TS-2026-88041→ NCMEC CyberTipCT-2026-1234567→ state ICAC task force caseICAC-AK-2026-0113→ local police case2026-004567→ state lab caseSCDL-26-0892(encrypted phone submission).Competency Question 1.1
Given the local police case number
2026-004567, what related cases exist across all organizations, with what case identifiers, and how are they related?Result 1.1
Case Identifier Relation to chain Platform T&S internal investigation TS-2026-88041 Referred_To NCMEC CyberTip intake NCMEC CyberTipline report handling CT-2026-1234567 Referred_To state ICAC task force case State ICAC task force case ICAC-AK-2026-0113 Referred_To local police case Local police case 2026-004567 Evidence_Submitted_To state lab case State lab examination case SCDL-26-0892 (terminal node) Competency Question 1.2
Which investigations in the graph carry which case identifiers (the imaging-tool "Case number" lookup)?
Result 1.2
All five investigations return their
caseIdentifiervalues in one query, regardless of which organization's tooling produced each subgraph.Draft SPARQL
PREFIX investigation: <https://ontology.caseontology.org/case/investigation/> PREFIX uco-core: <https://ontology.unifiedcyberontology.org/uco/core/> PREFIX proposed: <http://example.org/ontology/proposed/investigation/> SELECT ?sourceCase ?kind ?targetCase WHERE { ?rel a proposed:InvestigationRelationship ; uco-core:source ?src ; uco-core:target ?tgt ; uco-core:kindOfRelationship ?kind . ?src proposed:caseIdentifier ?sourceCase . ?tgt proposed:caseIdentifier ?targetCase . } # --- PREFIX investigation: <https://ontology.caseontology.org/case/investigation/> PREFIX uco-core: <https://ontology.unifiedcyberontology.org/uco/core/> PREFIX proposed: <http://example.org/ontology/proposed/investigation/> SELECT ?investigationName ?caseId WHERE { ?inv a investigation:Investigation ; uco-core:name ?investigationName ; proposed:caseIdentifier ?caseId . }
Example instance data
The example graph is available as a standalone file (
change_proposals/case-number-and-related-investigation-representation.jsonld) for validation and SPARQL testing. Proposed terms use aproposed:placeholder namespace pending committee decisions. I am fine with my examples being transcribed and credited.{ "@context": { "kb": "http://example.org/kb/", "proposed": "http://example.org/ontology/proposed/investigation/", "case-investigation": "https://ontology.caseontology.org/case/investigation/", "uco-core": "https://ontology.unifiedcyberontology.org/uco/core/", "xsd": "http://www.w3.org/2001/XMLSchema#" }, "@graph": [ { "@id": "kb:investigation-platform-ts", "@type": "case-investigation:Investigation", "uco-core:name": "Platform trust & safety internal investigation", "proposed:caseIdentifier": "TS-2026-88041" }, { "@id": "kb:investigation-ncmec-cybertip", "@type": "case-investigation:Investigation", "uco-core:name": "NCMEC CyberTipline report handling", "proposed:caseIdentifier": "CT-2026-1234567" }, { "@id": "kb:investigation-state-icac", "@type": "case-investigation:Investigation", "uco-core:name": "State ICAC task force case", "proposed:caseIdentifier": "ICAC-AK-2026-0113" }, { "@id": "kb:investigation-local-pd", "@type": "case-investigation:Investigation", "uco-core:name": "Local police department case", "proposed:caseIdentifier": "2026-004567" }, { "@id": "kb:investigation-state-lab", "@type": "case-investigation:Investigation", "uco-core:name": "State crime laboratory examination (encrypted smartphone)", "proposed:caseIdentifier": "SCDL-26-0892" }, { "@id": "kb:rel-ts-to-ncmec", "@type": "proposed:InvestigationRelationship", "uco-core:source": { "@id": "kb:investigation-platform-ts" }, "uco-core:target": { "@id": "kb:investigation-ncmec-cybertip" }, "uco-core:kindOfRelationship": "Referred_To", "uco-core:isDirectional": true }, { "@id": "kb:rel-ncmec-to-icac", "@type": "proposed:InvestigationRelationship", "uco-core:source": { "@id": "kb:investigation-ncmec-cybertip" }, "uco-core:target": { "@id": "kb:investigation-state-icac" }, "uco-core:kindOfRelationship": "Referred_To", "uco-core:isDirectional": true }, { "@id": "kb:rel-icac-to-local", "@type": "proposed:InvestigationRelationship", "uco-core:source": { "@id": "kb:investigation-state-icac" }, "uco-core:target": { "@id": "kb:investigation-local-pd" }, "uco-core:kindOfRelationship": "Referred_To", "uco-core:isDirectional": true }, { "@id": "kb:rel-local-to-lab", "@type": "proposed:InvestigationRelationship", "uco-core:source": { "@id": "kb:investigation-local-pd" }, "uco-core:target": { "@id": "kb:investigation-state-lab" }, "uco-core:kindOfRelationship": "Evidence_Submitted_To", "uco-core:isDirectional": true } ] }Solution suggestion
@prefix investigation: <https://ontology.caseontology.org/case/investigation/> . @prefix uco-core: <https://ontology.unifiedcyberontology.org/uco/core/> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix skos: <http://www.w3.org/2004/02/skos/core#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . investigation:caseIdentifier a owl:DatatypeProperty ; rdfs:subPropertyOf uco-core:externalIdentifier ; rdfs:label "caseIdentifier"@en ; skos:altLabel "case number"@en ; rdfs:comment "An identifier assigned to an investigation by the organization or case-management authority conducting or tracking it, e.g. a police case number, CyberTipline report ID, laboratory submission number, or court docket number. An investigation may carry multiple case identifiers. Distinct organizations investigating related matters each assign their own case identifiers; relate such investigations with an InvestigationRelationship."@en ; rdfs:range xsd:string . investigation:InvestigationRelationship a owl:Class ; rdfs:subClassOf uco-core:Relationship ; rdfs:label "InvestigationRelationship"@en ; rdfs:comment "An investigation relationship is a grouping of characteristics unique to an assertion of an association between two investigations, typically conducted by different organizations under different case identifiers. Recommended kindOfRelationship values (open vocabulary): 'Referred_To', 'Escalated_To', 'Spawned', 'Merged_Into', 'Parallel_To', 'Evidence_Submitted_To', 'Successor_Of'."@en .
Plus a SHACL property shape adding
caseIdentifierto theinvestigation:Investigationnode shape, andsh:class investigation:Investigationconstraints onuco-core:source/uco-core:targetofInvestigationRelationship. If the committee prefers not to add the subclass, Requirement 2 can be met with documentation of the plainuco-core:Relationshippattern;caseIdentifier(Requirement 1) stands alone either way.Related proposals and references
Reference Relevance This issue (CASE #191) The tool-mapping gap this proposal fills. CAC-Ontology #41 CAC had to propose a local caseNumber(asrdfs:subPropertyOf uco-core:externalIdentifier) for want of a CASE parent; it would re-parent toinvestigation:caseIdentifier.CASE #192 / #193 / #194 — legal process namespace stubs Criminal dockets, civil actions, and corporate matters all carry case identifiers; a #194 Referralproduces a related investigation with a new case number.CASE #189 — process meta-model Workflow runs and gates operate within cases identified and chained by these terms. CASE #178 / #183 / #187 — roles Different investigator roles sit at different links of the case chain (T&S analyst, LE investigator, lab examiner). CASE #138 — Investigation as Event Orthogonal; no conflict with either superclass decision. UCO #554 — Work ticket concept The analogous ticket-number pattern; both ground in uco-core:externalIdentifier.NCMEC CyberTipline Real-world referral pipeline motivating the multi-organization scenario. Pre-submission testing
SPARQL query testing
Query Tested Expected results match Notes CQ 1.1 — case chain with identifiers and relation kinds Yes Yes 4 results: TS→CyberTip→ICAC→local PD (Referred_To ×3), local PD→lab (Evidence_Submitted_To) CQ 1.2 — caseIdentifier lookup per investigation Yes Yes 5 results, one per organization Graph validation
$ make test-proposal PROPOSAL=case-number-and-related-investigation-representation case_validate --built-version case-1.4.0 --inference rdfs --allow-info \ --ontology-graph change_proposals/case-number-and-related-investigation-representation.ttl \ change_proposals/case-number-and-related-investigation-representation.jsonld Validation Report Conforms: TrueUnresolved issues
caseIdentifiervscaseNumbernaming, and typed-subclass vs documentation-only for Requirement 2, are committee decisions; the example uses aproposed:placeholder namespace.- Whether the recommended inter-investigation
kindOfRelationshipvalues should become a formal semi-open vocabulary (likeInvestigationFormVocab) is left to committee preference. - Human-readable IRIs are used in the example for readability; production data should use UUID-based IRIs.
-
For into it came up developing this technique for reading embedded metadata within forensic containers. Most mapped sensibly but with an obvious omission in case number.
"CASE_output_classes": [
"https://ontology.caseontology.org/case/investigation/exhibitNumber",
"https://ontology.unifiedcyberontology.org/uco/core/name",
"https://ontology.unifiedcyberontology.org/uco/observable/Note",
"https://ontology.unifiedcyberontology.org/uco/core/description",
"https://ontology.unifiedcyberontology.org/uco/types/Hash"
],Ok in some ways I'm glad it's missing, not that I couldn't find it.
@prosch88 Not sure if you hit this too with your CASE/UCO output from ALEX/UFADE
ALEX and UFADE do not currently assign a case number for the CASE output, since assigning a case number during Backup is currently optional.
Ok in some ways I'm glad it's missing, not that I couldn't find it.
@prosch88 Not sure if you hit this too with your CASE/UCO output from ALEX/UFADEALEX and UFADE do not currently assign a case number for the CASE output, since assigning a case number during Backup is currently optional.
Ah ok thanks. But if we get this in, if it that field was completed during export then it could go in this property. It's very helpful to have real examples of where it would be used.
CASE Investigation currently uses "uco-core:name" for this type of case/investigation identifier.
See examples on website:
https://caseontology.org/examples/asgard/
https://caseontology.org/examples/crossover/
https://caseontology.org/examples/owl_trafficking/{ "@id": "kb:bundle-5715fcf3-6bc8-4996-8f7f-fdf289f31649", "@type": "uco-core:Bundle", "uco-core:description": "Evidence in illegal trafficking of owls", "uco-core:object": [ { "@id": "kb:investigation-555e5fbb-ba09-449d-af77-8a210d016fd7", "@type": "case-investigation:Investigation", "uco-core:name": "OWL_2017_0206001", "case-investigation:focus": "Illegal trafficking (owls)", "uco-core:description": "The subject mcavoy was arrested on suspicion of illegal trafficking of owls. His computer and smartphone were preserved as evidence.", "rdfs:comment": "TODO - uco-core:object to list more IRIs.", "uco-core:object": [ { "@id": "kb:lge-device-eee670c6-01d4-4e42-bb6b-ebeca149b168" } ] } ] },Also shown in some illustrative CASE-Examples:
https://github.com/casework/CASE-Examples/blob/master/examples/illustrations/Oresteia/Oresteia.json
@eoghanscasey uco-core:name is just a subjective label. You could name the investigation "dog", "vehicle-investigation", or any other random string. We need a dedicated caseNumber property that is defined for this purpose.
That shouldn't be hard, just need to clearly document the change so that past CASE data can be migrated from "uco-core:name" to caseNumber (or caseIdentifier?).
Preference for something like caseIdentifier if this progresses since they aren't always numbers.
As an example from an imaging tool:
That output looks familiar :D
For context the imaging tool here, matches common metadata based on reference implementation(s).
I would also indicate "evidence" in the context of related tooling/format, IMHO is not the appropriate nomenclature, but again aligns with the reference implementation(s) (at least at the time).
How I used "case number" previously, is mostly as a reference, e.g. a tracking ticket/case/investigation number/reference/identifier. Definitely not bound to a numeric only value
Also note that in the context of specifically DFIR, terminology like "investigation" might refer mostly to insider threat related cases versus intrusions. Where a case might be used as synonym that includes a (tracking) tickets for intrusion alerts and/or a (legal/ediscovery) matters
Reacted by Chris HargreavesAn
investigation:caseIdentifieris defined as "An identifier assigned to an investigation". With such definition, clearly we should speak aboutinvestigation:investigationIdentifier. Vice versa, when reasons exist to maintain the property nameinvestigation:caseIdentifier, then clearly the definition should read "An identifier assigned to a case".I have not been able to review the entirety of this thread yet, so, apologies for a brief and possibly context-skipping response:
I think this proposal will hinge on the identity (as in "soul", for lack of a better word) of an investigation, before discussing the identity-numbering property.
Cory's comment with a draft proposal has a background with a scenario where an investigation "moves" through several organizations.
When an investigation "moves" from one group to another, is it the same investigation? We need to answer this first. On a practical point, if this proposal is boiling down to adding a single datatype property, we need to decide its upper cardinality being 1 or unlimited. If we're adding an identifier-object (akin to a name tag) to an investigation---handy for, say, representing when the identifier was created---then we also need to decide the linking property's upper cardinality being 1 or unlimited.
Say, Smalltown Police Department (SPD) transfers an investigation to the FBI. They transfer the materials and provenance within the investigation thus far. But is the investigation a new one once it hits the FBI? And further, is it a new one, derived from the investigation as it existed within SPD's authorities?
- In PROV-O modeling, this derivation from
InvestigationtoInvestigationwould further be aprov:Quotation. - In CASE modeling, I imagine all non-
Actionobjects linked withuco-core:objectwould be in the newInvestigation, because actions taken in the prior investigation were not taken in whatever the current investigation is.
I think it would also be helpful to consider the investigation, or investigations, versus the overarching event (i.e.,
uco-core:Event) of the investigation being pursued. In my view, there is only one event here, that starts when the investigation (/first investigation) is created, and concludes when the investigation is concluded, paused, or discontinued.The event view opens up some access to representing the partial periods in which each "owning" organization of the investigation is a participant in the pursuit of the investigation's goals. Maybe some transfers are complete and sever participation of prior investigators, some are permissive in contact with prior investigators.
In Tuesday's meeting, I'd like to discuss this question about between-organization transfers and whether that is investigation motion or creation.
- In PROV-O modeling, this derivation from
In yesterday's meeting, we concluded from the experience of those on the call (noted in the minutes) this resolution to my question on whether there was 1 investigation or 5 in Cory's example (also, that example was Cory's, not AI generated): There is 1 investigation per organization. They are able to operate in parallel. Investigations have an underlying authority backing them, which in "Official" (e.g., government) investigations would be legal authority. So, for example, an investigation started by a local police department that then "transfers" to a federal agency would result in two investigations. There may be other nuances we could explore, but it seems we have enough for an answer on cardinality of the case identifier: max-count 1.
I also asked if the investigation number should be a datatype property (just bearing a literal), or an object property (reifying the identifier, placing the string into that new object as one level of indirection). The advantage of doing the object property is it could be clarified whether an investigation number changed; if it did, when; was it assigned well after the investigation started. On the call, we decided this was not necessary, so we will suggest a datatype property.
Summary: A draft solution will be coming in a PR momentarily, and will help us decide on the Requirements Review vote (which is still to be scheduled).
- linked a pull request that will close this issueIssue 191: Add investigationIdentifier #212
on Sep 23, 2026 PR 212 filed.
(Edited by @ajnelson-nist : The initial Issue posting is going to be edited to manage some GitHub user interface logistics. The actual proposal is in this comment.)
As an example from an imaging tool:
Case number -> ???
Description -> https://ontology.unifiedcyberontology.org/uco/core/description
Evidence number -> https://ontology.caseontology.org/case/investigation/exhibitNumber
Examiner name -> https://ontology.unifiedcyberontology.org/uco/core/name
Notes -> https://ontology.unifiedcyberontology.org/uco/observable/Note
Case number could just be text, but it feels like something fundamental that should have a type? Am I missing something? uco-identity:IdentifierFacet maybe?
Coordination
developfor the next releasedevelopstate with backwards-compatible implementation merged intodevelop-2.0.0develop-2.0.0(or N/A)developbranch updated to track UCO's updateddevelopbranchdevelop-2.0.0branch updated to track UCO's updateddevelop-2.0.0branch