crimes against children change proposal

[suatgungor]

Background

Crimes against children, such as child exploitation and abuse, represent a significant portion of criminal activities investigated by law enforcement agencies. Currently, the Unified Cyber Ontology (UCO) lacks specific concepts that represent the unique aspects and entities involved in these investigations. By adding these concepts, we can enhance the ontology to better support data representation and sharing in investigations involving crimes against children. This change aims to improve the accuracy, efficiency, and interoperability of data exchange between various agencies handling such sensitive cases.

Requirements

Requirement 1

Introduce a new class ChildExploitation to represent crimes involving child exploitation.

Requirement 2

Add properties to capture specific details related to child exploitation cases, such as exploitationMethod, victimAge, and digitalEvidence.

Risk / Benefit analysis

Benefits

Enhanced Representation: Improved data representation for crimes against children, aiding in investigations and data sharing.
Specificity: More specific entities and properties tailored to the unique nature of these crimes.
Interoperability: Enhanced interoperability between different law enforcement and child protection agencies.
Risks
Complexity: Increased complexity in the ontology due to the addition of new classes and properties.
Maintenance: Additional effort required to maintain and update the ontology as the field evolves.

Competencies demonstrated

Competency 1

The ontology can accurately represent and support investigations related to crimes against children.

Competency Question 1.1

How can we represent a case of child exploitation in the ontology?

Result 1.1

The ontology now includes a ChildExploitation class with properties such as exploitationMethod, victimAge, and digitalEvidence.

Competency Question 1.2

How do we capture specific details related to child exploitation cases?

Result 1.2

The new properties related to ChildExploitation allow for detailed representation of the exploitation method, the age of the victim, and any digital evidence associated with the case.

Solution suggestion

Define New Class: Introduce a new class ChildExploitation in the ontology.
Add Properties: Add properties exploitationMethod, victimAge, and digitalEvidence to the ChildExploitation class.
Update Relationships: Update existing classes to define relationships with ChildExploitation.
Testing and Validation: Conduct thorough testing to validate the integration of the new class and properties.
Documentation and Training: Update system documentation to reflect the changes and provide training for maintenance and monitoring of the new system components.
I am fine with my examples being transcribed and credited.

[ajnelson-nist]

This proposal was posted as part of the DFRWS-USA 2024 Rodeo event, which comprised of a set of forensic capture-the-flag challenges. I did not suggest or develop this challenge, but I did agree to judge submission completeness. The challenge prompting this proposal read:

Category: Project Vic

Title: Shape_The_Future

Create and submit a change proposal to the Unified Cyber Ontology project on Github that presents a new or updated concept related to crimes against children investigations. Submit link to the change proposal in Github as the flag.

Link to the Unified Cyber Ontology: https://github.com/ucoProject/UCO/tree/master/ontology/uco

Link to the project's Change Request template: https://github.com/ucoProject/UCO/issues/new?assignees=&labels=change+request&projects=&template=change-request.md&title=

You will need a GitHub account to login and submit the change proposal.

To get credit for the flag, the change proposal form needs to be completely filled out.

[ajnelson-nist]

Hello @suatgungor ,

Thank you for posting this proposal.

It is too close in our review cycle for discussion in tomorrow's CDO Ontology Committees call, but I will try to review the proposal later this week for discussion in the August 20th call. Please send me an email if you'd like to participate on that call.

--Alex

[sbarnum]

I think we should be VERY careful about adding the concept of "Crime" to CASE as it is fraught with nuance and complexity. I would propose we avoid that for now.
I DO think that ChildExploitation makes good sense as a subClassOf Action.
If there are properties unique to a ChildExploitation action not already semantically covered by other properties we could add a ChildExploitationAction Facet to hold them.
That being said, I think we need to be careful not to add new properties where appropriate expressivity may already exist.
For example, digital evidence of a ChildExploitation action are likely best expressed with objects outside of the ChildExploitation action itself and related to the action with appropriate Relationships.
Similarly, the age of the victim is likely best expressed as an age property on a Person object having the Victim role and then that Person object being related to the ChildExploitation action with the 'object' property of the action (what the action is performed against/on).

[ajnelson-nist]

(I've edited the initial post to fix Markdown formatting.)

[ajnelson-nist]

@sbarnum , I'm facing a design question now. At your suggestion, and without anyone finding a good counter-example or counter-consideration, the UCO Ontology Committee had agreed to designate core:Event and action:Action disjoint classes (in Issue 563). I'd like to see if I understand that disjointedness as it applies here.

I'm going to switch tracks slightly and talk about modeling a murder, because we have had an example on CASE-Examples for a while where a murder occurs. Actually, several. Point being, there should be enough data-structural similarity to translate this conversation back to the original topic.

The example is the Oresteia, which I recently updated to add some reporting. (I noticed a while ago some of the personae mentioned weren't encoded.) The scenario is documented (with the generated-tables update) here.

I'll focus on "Crime C", linked here. I think this one happens to not have been fleshed out too much, so we should have some freedom to make graph nodes.

The investigation is based on a simple statement: At a location, a person killed another person. It's an investigation, so "allegedly" should probably be in that and the other descriptions. (@eoghanscasey , can you confirm?)

@sbarnum , here is the representation question re: Event and Action being disjoint:

• There is an event where someone died, and circumstances of the event are being investigated. I think the transition from living person to decedent would be encoded as a (subclass of) uco-core:Event. A reason for using Event is so no uco-action:performer value need be specified, in case the death happened to occur by some accident rather than some agent.
• Let's say from weapon wounds and/or bloody handprints and/or other visual indicators, it is apparent someone performed the act of killing the now-decedent. I think this would be encoded as a uco-action:Action, with the uco-action:performer (allegedly) being Aegisthus, but definitely being some uco-identity:Person.
• From UCO's current supported concepts, the act of killing would have a "context" of the murder event.
  • Should Issue 544 be adopted, we could also describe a perdurant proper-parthood where the action is part of the event.

@sbarnum , aside from the Issue 544 bits, do you concur?

I tried this phrasing so we don't necessarily need to classify the event as a crime. But, some ontology downstream of UCO and/or CASE could define a class CrimeEvent, subclass of Event, and likewise for CriminalAction. I do see how encoding these classes in CASE or UCO could lead to a "jump to conclusions" encoding issue.