New subclass of victim #616
Comments
|
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:
|
|
Hello @smite-dev , 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 |
|
Hi Alex,
Great to hear from you!
Yes, I would love to participate on the August 20 call. My change
request was submitted in a hurry right before the Rodeo ended, so it's
not as thorough as I would like it to be. When I get the chance, I am going
to go in and edit it to more properly shape it.
Thanks!
…On Mon, Jul 15, 2024 at 9:45 AM Alex Nelson ***@***.***> wrote:
Hello @smite-dev <https://github.com/smite-dev> ,
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
<https://cyberontology.atlassian.net/wiki/spaces/CDOC/pages/2248212489/2024-08-20+CDO+Ontology+Committees>.
Please send me an email if you'd like to participate on that call.
--Alex
—
Reply to this email directly, view it on GitHub
<#616 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AK7RIHYQGYCRUPKFFTAD57DZMPG7BAVCNFSM6AAAAABKYDERM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRYGU2DIMJTHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thank you for letting me know your plan. From unrelated matters, I'm unlikely to take action before late Thursday afternoon. |
|
Noted! I will have the edits done by Wednesday, in that case. Thanks for letting me know! |
|
I think this CP calls out a need for us to better explain how Victim works as a Role in relationship to a particular Identity (either a Person or an Organization). Reviewing the current UCO ontology when reviewing the CP did reveal a bug that I had not noticed and has likely been present for a long time. We need to fix this bug and change the subclassing of VictimTargeting from Victim to be Identity. |
|
Yes, this is true! My proposal was calling for the Victim ontology to have further detailed classifications of a victim: HOW a victim was targeted (e.g. homicide, accident) + the identity of a victim (e.g. race, sex, age). Knowing more insight into WHO the victim is can provide valuable help when analyzing a case. Knowing the identities of a victim can also help when tying it to a crime and trying to figure out why a crime on a victim could have been committed. |
|
I think there are two course-revisions in this proposal: @sbarnum noted the bugfix for The victim-categorizing notes I think more generically apply to people, rather than just victims, when describing physical characteristics. (Note for Sean coming in a moment.) There are some role-based classes that also apply, like targets within organizational positions (spear phishing IT administrators), but I think those are going to fold into the The crime-categorizing notes look like they veer a bit into general event descriptions, e.g., accidents aren't necessarily crimes. We have the @sbarnum - A while ago (a few years?), I recall there were notes in |
|
Here’s a starting point on the relatively recent efforts to advance NIEM: http://niem.github.io/json/
Patrick Maroney | Principal – Cybersecurity | AT&T Services, Inc.
Chief Security Office
Threat Analytics
e: ***@***.******@***.***> | p: 732.615.5287
…________________________________
From: Alex Nelson ***@***.***>
Sent: Thursday, July 18, 2024 5:39:58 PM
To: ucoProject/UCO ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [ucoProject/UCO] New subclass of victim (Issue #616)
I think there are two course-revisions in this proposal: @sbarnum noted the bugfix for VictimTargeting. At the moment, I think that should be handled in a separate proposal. It also is sounding a bit to me like a meta-class - I know how to
I think there are two course-revisions in this proposal:
@sbarnum<https://urldefense.com/v3/__https://github.com/sbarnum__;!!BhdT!mu4liFMT63RFEZpV7vG82AwBilJUxPRlN-fo_CV-MVr_6GVv6tpIoKQCWjVSnW0PwABHXHt5cTPWDrP6p5oio371P5Q$> noted the bugfix for VictimTargeting. At the moment, I think that should be handled in a separate proposal. It also is sounding a bit to me like a meta-class - I know how to spell what Sean described with owl:Restrictions, so I'm not seeing a lot for UCO to invent there, rather than just get well-demonstrated.
The victim-categorizing notes I think more generically apply to people, rather than just victims, when describing physical characteristics. (Note for Sean coming in a moment.) There are some role-based classes that also apply, like targets within organizational positions (spear phishing IT administrators), but I think those are going to fold into the VictimTargeting fix topic.
The crime-categorizing notes look like they veer a bit into general event descriptions, e.g., accidents aren't necessarily crimes. We have the core:eventType<https://urldefense.com/v3/__https://ontology.unifiedcyberontology.org/documentation/prop-coreeventtype.html__;!!BhdT!mu4liFMT63RFEZpV7vG82AwBilJUxPRlN-fo_CV-MVr_6GVv6tpIoKQCWjVSnW0PwABHXHt5cTPWDrP6p5oit7YxeU0$> informal-typing property for when data needs to be encoded faster than an OWL subclass of Event can be encoded, implemented, and released in an ontology version (whether UCO or an adopter).
@sbarnum<https://urldefense.com/v3/__https://github.com/sbarnum__;!!BhdT!mu4liFMT63RFEZpV7vG82AwBilJUxPRlN-fo_CV-MVr_6GVv6tpIoKQCWjVSnW0PwABHXHt5cTPWDrP6p5oio371P5Q$> - A while ago (a few years?), I recall there were notes in identity.ttl to look over NIEM. I think when last we looked NIEM was an XML Schema, but not RDF. They seem to have some JSON-LD or RDF support now, at least glancing at 5.0<https://urldefense.com/v3/__https://niem.github.io/NIEM-JSON-Spec/v5.0/niem-json-spec.html__;!!BhdT!mu4liFMT63RFEZpV7vG82AwBilJUxPRlN-fo_CV-MVr_6GVv6tpIoKQCWjVSnW0PwABHXHt5cTPWDrP6p5oiGsSYtD4$>. Should we look to that again for some of the person-characteristics in this proposal? (I'm having a little trouble finding their RDF encoding - the namespace returns an XML Schema document.)
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/ucoProject/UCO/issues/616*issuecomment-2237668613__;Iw!!BhdT!mu4liFMT63RFEZpV7vG82AwBilJUxPRlN-fo_CV-MVr_6GVv6tpIoKQCWjVSnW0PwABHXHt5cTPWDrP6p5oi7umIHXk$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AAYSFYO7CHKGEGMAQIOKSOLZNAY25AVCNFSM6AAAAABKYDERM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZXGY3DQNRRGM__;!!BhdT!mu4liFMT63RFEZpV7vG82AwBilJUxPRlN-fo_CV-MVr_6GVv6tpIoKQCWjVSnW0PwABHXHt5cTPWDrP6p5oil4dyIco$>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
Re:
@sbarnum , thanks for the description and example. Your last line seems to be suggesting this change: uco-victim:VictimTargeting
- rdfs:subClassOf uco-victim:Victim ;
+ rdfs:subClassOf uco-identity:Identity ;
.After trying this out on the example you provided modeling yourself, and @smite-dev 's competency illustration, I think I disagree. This comment has a decent amount of Turtle in it to discuss meta-classes and using OWL reasoning to realize that a subset of people fit some classes of victim-targets. The Turtle and working code is in this Gist, and the Turtle there has some further inlined comments. Here is the Sean-in-RDF example, adding some properties that UCO doesn't have yet. (I'm not sure how they would be implemented from NIEM. I don't understand the model well enough; @prefix ex: <http://example.org/ontology/> .
@prefix uco-core: <https://ontology.unifiedcyberontology.org/uco/core/> .
@prefix uco-identity: <https://ontology.unifiedcyberontology.org/uco/identity/> .
ex:age
a owl:DatatypeProperty ;
rdfs:comment "A person's age."@en ;
rdfs:seeAlso <https://niem.github.io/model/5.0/nc/PersonAgeMeasure> ;
rdfs:range xsd:integer ;
.
ex:hairColor
a owl:DatatypeProperty ;
rdfs:comment "A person's hair color."@en ;
rdfs:seeAlso <http://release.niem.gov/niem/domains/jxdm/6.0/#PersonHairColorCode> ;
rdfs:range xsd:string ;
.
kb:Person-64d47905-ac42-42ee-aaf2-cf52a4648c00
a uco-identity:Person ;
ex:age 55 ;
ex:hairColor "BRO" ;
uco-core:name "Sean Barnum" ;
uco-core:hasFacet kb:SimpleNameFacet-d7934591-b4b1-4934-aa93-828340aa82b6 ;
.
kb:SimpleNameFacet-d7934591-b4b1-4934-aa93-828340aa82b6
a uco-identity:SimpleNameFacet ;
uco-identity:familyName "Barnum" ;
uco-identity:givenName "Sean" ;
.I intentionally put Let's derive a "targeting" class that that characterization of Sean fits into: Some disgruntled individual chooses to target people who are over 40 with brown hair. In OWL, using those two # Necessary and sufficient conditions to be of this PersonType:
# * Be a Person.
# * Have brown hair.
# * Be over 40.
kb:PersonType-0ade6e45-1327-4826-8103-9cd331c655bd
a owl:Class ;
rdfs:comment "Class of people over 40 with brown hair. Derived from investigation details."@en ;
owl:equivalentClass [
a owl:Class ;
owl:intersectionOf (
uco-identity:Person
[
a owl:Restriction ;
owl:onProperty ex:hairColor ;
owl:hasValue "BRO" ;
]
[
a owl:Restriction ;
owl:onProperty ex:age ;
owl:allValuesFrom [
a rdfs:Datatype ;
owl:onDatatype xsd:integer ;
owl:withRestrictions (
[
xsd:minExclusive 40 ;
]
) ;
] ;
]
) ;
] ;
.An OWL reasoner would then look at the graph with the Sean node, and infer this: kb:Person-64d47905-ac42-42ee-aaf2-cf52a4648c00
a kb:PersonType-0ade6e45-1327-4826-8103-9cd331c655bd ;
.(The Gist covers the class of people with the last name Barnum, using the This shows a few complexities in ontological practice, but I think they would come up as investigations evolve. As an OWL class, this would typically go into the "TBox" side of the graph, where classes and properties are defined. However, the class may more naturally arise from the "ABox" side where (graph-)individuals are defined. For instance, this class could be defined after stumbling upon social media posts where the suspect (allegedly) posted a seething text about middle-aged men who aren't gray, with a specific envy for still having brown hue. This could comfortably go into a "TBox" ontology portion that is localized to just the current investigation. Or, like I did in my sketch, it could be part of the knowledge base in the "ABox" side. Sean suggested kb:Person-64d47905-ac42-42ee-aaf2-cf52a4648c00
a
kb:PersonType-0ade6e45-1327-4826-8103-9cd331c655bd ,
uco-victim:VictimTargeting
;
.Is the Sean node supposed to be an instance of the # A
kb:Person-64d47905-ac42-42ee-aaf2-cf52a4648c00
a uco-identity:Person ;
a uco-victim:VictimTargeting ;
.
# Or:
# B
kb:PersonType-0ade6e45-1327-4826-8103-9cd331c655bd
a owl:Class ;
a uco-victim:VictimTargeting ;
.(For what it's worth, the Gist was fairly unaffected by adding @sbarnum: A, or B? If A, how did you plan on setting up the encoding of why the victim was targeted? Did you have an alternative to the OWL mechanisms already available to us? Having gone through writing the Gist, I'm thinking this Issue (616) could morph into just aligning |
|
@plbt5 helped me realize another option between A or B at the end of my last comment: # C (which entails A)
uco-victim:VictimTargeting
rdfs:subClassOf uco-identity:Identity;
.
kb:PersonType-0ade6e45-1327-4826-8103-9cd331c655bd
a owl:Class ;
rdfs:subClassOf uco-victim:VictimTargeting ;
. |
|
If helpful, here are illustrations of what I meant by the choices B and C above. I think A would be subsumed by C, so I'll stop referencing it. Option B
flowchart BT
subgraph "TBox (Classes)"
uco_core_uco_object[uco-core:UcoObject]
uco_core_uco_thing[uco-core:Thing]
uco_identity_identity[uco-identity:Identity]
uco_identity_person[uco-identity:Person]
subgraph "Metaclasses"
uco_victim_victim_targeting[uco-victim:VictimTargeting]
end
subgraph "Case-specific classes"
kb_person_type_0ade6e45[Set of people,\nbrown-haired,\nover 40]
kb_person_type_a90a2c68[Set of people,\nlast name Barnum]
end
end
subgraph "ABox (Individuals)"
kb_sean[Sean Barnum;\nhair=BRO;\nage=55]
end
kb_sean --∈\n(asserted)--> uco_identity_person
kb_sean --∈\n(entailed)--> kb_person_type_0ade6e45
kb_sean --∈\n(entailed)--> kb_person_type_a90a2c68
kb_person_type_0ade6e45 --⊆--> uco_identity_person
kb_person_type_a90a2c68 --⊆--> uco_identity_person
kb_person_type_0ade6e45 --∈--> uco_victim_victim_targeting
kb_person_type_a90a2c68 --∈--> uco_victim_victim_targeting
uco_core_uco_object --⊆--> uco_core_uco_thing
uco_identity_person --⊆--> uco_identity_identity
uco_identity_identity --⊆--> uco_core_uco_object
Option C
flowchart BT
subgraph "TBox (Classes)"
uco_core_uco_object[uco-core:UcoObject]
uco_core_uco_thing[uco-core:Thing]
uco_identity_identity[uco-identity:Identity]
uco_identity_person[uco-identity:Person]
uco_victim_victim_targeting[uco-victim:VictimTargeting]
subgraph "Case-specific classes"
kb_person_type_0ade6e45[Set of people,\nbrown-haired,\nover 40]
kb_person_type_a90a2c68[Set of people,\nlast name Barnum]
end
end
subgraph "ABox (Individuals)"
kb_sean[Sean Barnum;\nhair=BRO;\nage=55]
end
kb_sean --∈\n(asserted)--> uco_identity_person
kb_sean --∈\n(entailed)--> kb_person_type_0ade6e45
kb_sean --∈\n(entailed)--> kb_person_type_a90a2c68
kb_person_type_0ade6e45 --⊆--> uco_identity_person
kb_person_type_a90a2c68 --⊆--> uco_identity_person
kb_person_type_0ade6e45 --⊆--> uco_victim_victim_targeting
kb_person_type_a90a2c68 --⊆--> uco_victim_victim_targeting
uco_core_uco_object --⊆--> uco_core_uco_thing
uco_identity_person --⊆--> uco_identity_identity
uco_identity_identity --⊆--> uco_core_uco_object
uco_victim_victim_targeting --⊆--> uco_identity_identity
|
|
I think today's English definition of
...except, on reviewing all of the classes entailed by just being a
And, the example targeting class I sketched has this definition string, which is similarly more descriptive of the set than of the individuals in the set: "A set of people allegedly being targeted by an investigation subject. Descriptions drawn from linked social media posts. To date, the qualifications are known to be brown-haired and over 40 years of age." In contrast, other ontologies and RDF models describe classes by their individuals.
If UCO were using the definition style of these other ontologies, today's wording of @sbarnum , your input on B vs C would still be appreciated. But, it seems current design suggests option C. |
|
@sbarnum : In the example graph, let's say you're actually victimized, and not just a member of the What is the |
The notes on fleshing out various Facets for Identity were referencing OASIS CIQ rather than NIEM. It is still the most comprehensive and fleshed out identity model out there to the best of my knowledge. |
It is neither A nor B though A is closer to reality. The class tree would look like this:
So, using your example scenario above, you could have a kb:PersonType-0ade6e45-1327-4826-8103-9cd331c655bd (characteristic details of some victim targeting) individual object that is a member of the VictimTargeting class but defines its characteristics like an Identity object would (with IdentityFacets containing properties) which is natural and straightforward for any user. If you wanted to convey that an Person object for Sean fit the victim targeting profile (at a given time) you would simply define a Relationship object where kindOfRelationship="fitsVictimTargeting", source=, target=kb:PersonType-0ade6e45-1327-4826-8103-9cd331c655bd, and startTime=<the time I fit the targeting pattern (remember, I could die my hair blond in 3 months ;-) ). If investigators/analysts at some point wanted to check the victims of unsolved crimes against a given victim targeting pattern they could either specify and appropriate SPARQL query or they could codify the VictimTargeting Individual as a separate OWL restrictions-based object as you did above and use either to potentially find matches. It should be noted that the intended concept and use of VictimTargeting has nothing to do with either of the Competencies in the CP. The first competency in the CP has to do with characterizing a specific person. The second competency in the CP has to do with what kind of victim he was. This does not have anything to do with VictimTargeting unless you wanted to characterize what sort of people the robber typically targeted . It is important not to conflate things like the identity of the victim, the fact he was a victim, the events and actions that occurred, where they occurred, what sort of victim targeting may have occurred. |
I will assert fairly strongly that it is not A, B, or C. |
I think my explanation regarding the Competencies in the CP should explain this but here is an attempt at a short summary. The Victim object is an predefined (in the ontology) Individual of the class NeutralRole. It IS a role, not a class of roles.
|
Background
In ontology/uco/victim, the victim.ttl file has only TWO classes: Victim and VictimTargeting. This should be increased, as there are many different ontological connections associated with victims.
Requirements
Requirement 1
Add subclass to describe different TYPES of victims. These will be subclasses to the parent class "Victim." Victims can be differentiated by their different properties. For example: age, race, sexuality, blood type, height, eye color, weight, tattoos, hair, sex, etc.
Requirement 2
Add subclass to describe HOW the victim was targeted. (Was this targeting a hate crime? A homicide? Etc.)
Risk / Benefit analysis
Benefits
Can help further classify victims and their properties and provide further insight into the details of a victim, which is very important during a crime analysis.
Risks
The submitter is unaware of risks associated with this change.
Competencies demonstrated
Competency 1
A victim has been killed. Law enforcement is analyzing this case. The first and most important thing is to learn more about who the victim is and how they were killed.
Competency Question 1.1
What identities does this victim have?
Result 1.1
The victim is named John Doe. He is a 44-year old Caucasian male with hazel eyes, brown hair, and stands 68 inches tall.
Competency Question 1.2
In what way was this victim targeted?
Result 1.2
John Doe was killed during a robbery at his job.
Solution suggestion
Define new subclasses of Victim
Crime Type
Victim Type
Define properties specific to the new subclasses
Within Crime Type, add properties such as: natural, accident, suicide, homicide, undetermined, and pending.
Within Victim Type, add properties such as: age, race, sexuality, blood type, height, eye color, weight, tattoos, hair, sex.
I am fine with my examples being transcribed and credited.
The text was updated successfully, but these errors were encountered: