Repository navigation
What do you use for 'Case number' in typical imaging tools? #191
Description
(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:
Acquiry parameters required, please provide the necessary input
Image path and filename without extension: outfile
Case number: mycase1
Description: this is my case
Evidence number: mycase/ev1
Examiner name: Examiner1
Notes: Some notes
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
- Tracking in Jira ticket OCCASE-504
- Administrative review completed, proposal announced to Ontology Committees (OCs) on 2026-09-23
- Requirements to be discussed in OC meeting, 2026-10-TBD
- Requirements Review vote has not occurred
- Requirements development phase completed.
- Solution announced to OCs on TODO-date
- Solutions Approval to be discussed in OC meeting, date TBD
- Solutions Approval vote has not occurred
- Solutions development phase completed.
- Backwards-compatible implementation merged into
developfor the next release -
developstate with backwards-compatible implementation merged intodevelop-2.0.0 - Backwards-incompatible implementation merged into
develop-2.0.0(or N/A) - Milestone linked
- Documentation logged in pending release page
- Prerelease publication: CASE
developbranch updated to track UCO's updateddevelopbranch - Prerelease publication: CASE
develop-2.0.0branch updated to track UCO's updateddevelop-2.0.0branch
Activity
vulnmaster commentedon Jul 9, 2026
We need a caseNumber property on the CASE Investigation class. We also need a mechanism to show relationships between investigations with different case numbers.
chrishargreaves commentedon Jul 9, 2026
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
vulnmaster commentedon Jul 9, 2026
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:
TS-2026-88041,CT-2026-1234567,ICAC-AK-2026-0113,2026-004567,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.
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: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 graphinvestigation:Investigation(via SHACL property shape on theInvestigationshape; multiple values permitted, since one organization may assign several identifiers to one case)xsd:stringThis directly answers the mapping table in the opening comment:
investigation:caseIdentifier(proposed) on theinvestigation:Investigationnodeuco-core:descriptioninvestigation:exhibitNumberuco-core:nameon theinvestigation:Examinerrole / identityuco-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:uco-core:Relationshipwhosesourceandtargetareinvestigation:Investigationnodes.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.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
caseIdentifierrefinesuco-core:externalIdentifier; relating investigations reusesuco-core:Relationship. Minimal new surface area.caseNumberlocally for want of a CASE parent; other domain ontologies will follow.Risks
caseIdentifiervscaseNumber. Mitigation: committee choice; askos:altLabel "case number"preserves findability either way.Investigation: one property, subproperty of an existing core term — minimal.kindOfRelationshipvalues between investigations. Mitigation: publish the recommended values as a semi-open vocabulary (the same approach asInvestigationFormVocab), leaving room for domain values.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).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
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
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
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
caseNumber(asrdfs:subPropertyOf uco-core:externalIdentifier) for want of a CASE parent; it would re-parent toinvestigation:caseIdentifier.Referralproduces a related investigation with a new case number.uco-core:externalIdentifier.Pre-submission testing
SPARQL query testing
Graph validation
Unresolved issues
caseIdentifiervscaseNumbernaming, and typed-subclass vs documentation-only for Requirement 2, are committee decisions; the example uses aproposed:placeholder namespace.kindOfRelationshipvalues should become a formal semi-open vocabulary (likeInvestigationFormVocab) is left to committee preference.chrishargreaves commentedon Jul 9, 2026
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.
SOLVE-IT-DF/solve-it#504
"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"
],
prosch88 commentedon Jul 9, 2026
ALEX and UFADE do not currently assign a case number for the CASE output, since assigning a case number during Backup is currently optional.
chrishargreaves commentedon Jul 9, 2026
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.
eoghanscasey commentedon Jul 9, 2026
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/
Also shown in some illustrative CASE-Examples:
https://github.com/casework/CASE-Examples/blob/master/examples/illustrations/Oresteia/Oresteia.json
vulnmaster commentedon Jul 9, 2026
@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.
eoghanscasey commentedon Jul 10, 2026
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?).
chrishargreaves commentedon Jul 10, 2026
Preference for something like caseIdentifier if this progresses since they aren't always numbers.
joachimmetz commentedon Jul 23, 2026
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
plbt5 commentedon Aug 25, 2026
An
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".ajnelson-nist commentedon Sep 18, 2026
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?
InvestigationtoInvestigationwould further be aprov:Quotation.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.
ajnelson-nist commentedon Sep 23, 2026
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).
ajnelson-nist commentedon Sep 23, 2026
PR 212 filed.