New subclass of victim

[smite-dev]

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.

[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 @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

[smite-dev]

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 https://github.com/ucoProject/UCO/issues/616#issuecomment-2228544139, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK7RIHYQGYCRUPKFFTAD57DZMPG7BAVCNFSM6AAAAABKYDERM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRYGU2DIMJTHE . You are receiving this because you were mentioned.Message ID: @.***>

[ajnelson-nist]

Thank you for letting me know your plan. From unrelated matters, I'm unlikely to take action before late Thursday afternoon.

[smite-dev]

Noted! I will have the edits done by Wednesday, in that case. Thanks for letting me know!

[sbarnum]

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. VictimTargeting is not supposed to be a subClassOf Victim. VictimTargeting is not a Role. Victimtargeting is intended to be an abstraction for an Identity that could specify particular Identity characteristics of people and/or organizations that were targeted in some malicious action. Rather than having a Person object with name="SeanBarnum", gender="male", age="55", and hairColor="Brown", you could specify that a particular malicious action was targeting people who have gender="male" and hairColor="Brown". Obviously, Sean Barnum would fit the targeted profile but so would many others. This VictimTargeting could also be related to objects other than a specific action. They could be related to a Person having a Subject Role to specify their particular victim targeting profile (e.g., girls, age=12-15, blond hair, etc). Many other such relationships are also possible and relevant.

We need to fix this bug and change the subclassing of VictimTargeting from Victim to be Identity.

[smite-dev]

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.

[ajnelson-nist]

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 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 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 - 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. 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.)

[packet-rat]

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:

@sbarnumhttps://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:eventTypehttps://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).

@sbarnumhttps://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.0https://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 GitHubhttps://urldefense.com/v3/__https://github.com/ucoProject/UCO/issues/616*issuecomment-2237668613__;Iw!!BhdT!mu4liFMT63RFEZpV7vG82AwBilJUxPRlN-fo_CV-MVr_6GVv6tpIoKQCWjVSnW0PwABHXHt5cTPWDrP6p5oi7umIHXk$, or unsubscribehttps://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: @.***>

[ajnelson-nist]

Re:

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. VictimTargeting is not supposed to be a subClassOf Victim. VictimTargeting is not a Role. Victimtargeting is intended to be an abstraction for an Identity that could specify particular Identity characteristics of people and/or organizations that were targeted in some malicious action. Rather than having a Person object with name="SeanBarnum", gender="male", age="55", and hairColor="Brown", you could specify that a particular malicious action was targeting people who have gender="male" and hairColor="Brown". Obviously, Sean Barnum would fit the targeted profile but so would many others. This VictimTargeting could also be related to objects other than a specific action. They could be related to a Person having a Subject Role to specify their particular victim targeting profile (e.g., girls, age=12-15, blond hair, etc). Many other such relationships are also possible and relevant.

We need to fix this bug and change the subclassing of VictimTargeting from Victim to be Identity.

@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; nc:PersonAgeMeasure and j:PersonHairColorCode seem applicable from this page, but I don't yet grok the linking.)

@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 ex:age and ex:hairColor onto the uco-identity:Person node rather than a Facet for the sake of demonstrating some OWL, though this isn't UCO's typical design guidance. I think they would go onto a uco-identity:PhysicalInfoFacet, but which Facet they would go onto feels a bit out of scope of this discussion. A Facet-based demonstration is also in the Gist.

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 ex: properties on the Person node, that targeted class of people looks like this:

# 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 SimpleNameFacet.)

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 VictimTargeting be a specialization of Identity. I think that that class, kb:PersonType-0ade6e45-..., relates to VictimTargeting, but I'm not entirely convinced this would be the correct thing to also infer:

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 VictimTargeting class? Or, is the class kb:PersonType-0ade6e45-... supposed to be an instance of the VictimTargeting class? (That is, should VictimTargeting be a class whose members are classes, a.k.a., a metaclass.)

# 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 VictimTargeting as a metaclass.)

@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 VictimTargeting. I do agree, that class shouldn't be tied by subclassing to Role. I'm not sure what else would go into specifically the Victim ontology, and @smite-dev 's competency seems illustrable with core:eventType (should the homicide-during-robbery event be data-illustrated) and owl:Restrictions in search-oriented classes.

[ajnelson-nist]

@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 ;
    .

[ajnelson-nist]

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

VictimTargeting is a metaclass, and targeting classes are instances of VictimTargeting.

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

VictimTargeting is a specialization of Identity, and targeting classes are specializations of VictimTargeting and most often also a specialization of Person or Organization.

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

[ajnelson-nist]

I think today's English definition of VictimTargeting today would lean more towards option B (metaclass)...

A victim targeting is a grouping of characteristics unique to people or organizations that are the target of some malicious activity.

...except, on reviewing all of the classes entailed by just being a identity:Person, the Sean graph-node is all of these:

• identity:Person: "A person is a grouping of identifying characteristics unique to a human being regarded as an individual."
• identity:Identity: "An identity is a grouping of identifying characteristics unique to an individual or organization."
• core:IdentityAbstraction: "An identity abstraction is a grouping of identifying characteristics unique to an individual or organization. This class is an ontological structural abstraction for this concept. Implementations of this concept should utilize the identity:Identity class."
• core:UcoObject: "A UCO object is a representation of a fundamental concept either directly inherent to the cyber domain or indirectly related to the cyber domain and necessary for contextually characterizing cyber domain concepts and relationships. Within the Unified Cyber Ontology (UCO) structure this is the base class acting as a consistent, unifying and interoperable foundation for all explicit and inter-relatable content objects."
• core:UcoThing: "UcoThing is the top-level class within UCO."

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.

• foaf:Person: "A person."
• prov:Person: "Person agents are people."
  • prov:Agent: "An agent is something that bears some form of responsibility for an activity taking place, for the existence of an entity, or for another agent's activity."
• schema:Person: "A person (alive, dead, undead, or fictional)."

If UCO were using the definition style of these other ontologies, today's wording of VictimTargeting would firmly suggest it is a metaclass. But, given the wording style of current classes where most everything in UCO is "a grouping of characteristics about a thing X," rather than "an X," victim:VictimTargeting seems to verbally fit under identity:Identity as a subclass.

@sbarnum , your input on B vs C would still be appreciated. But, it seems current design suggests option C.

[ajnelson-nist]

@sbarnum : In the example graph, let's say you're actually victimized, and not just a member of the VictimTargeting subclass kb:PersonType-0ade6e45-....

What is the victim:Victim object?

[sbarnum]

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 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 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 - 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. 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.)

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.

[sbarnum]

this Gist

It is neither A nor B though A is closer to reality. The first big issue is that while the OWL approach you present above could be valid to predefine a filter for any Person individuals in the future it kind of misses the point. Only an ontologist (an tiny tiny portion of the user community) could ever hope to write that correctly. The intent of VictimTargeting is to enable laymen practitioners to be able to describe characteristics of the victims targeted in some malicious activity. Individual victim targeting descriptions need to be able to be defined as individual UcoObject (Identities to be more specific) using the properties defined in CDO ontologies that apply to Identity objects and their subclasses (Person, Organization, etc.).

The class tree would look like this:

• UcoObject
  • IdentityAbstraction
    • Identity
      • Person
      • Organization
      • VictimTargeting

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. It could look something more like the following: (A brief note here that there is already a defined identity:BirthInfoFacet with an identity:birthdate property. This example has highlighted that we probably should add two more properties (identity:birthdateRangeStart and identity:birthdateRangeEnd to identity:BirthInfoFacet where both are disjoint from identity:birthdate.) kb:PersonType-0ade6e45-1327-4826-8103-9cd331c655bd a identity:VictimTargeting ; rdfs:comment "People over 40 with brown hair. Derived from investigation details."@en ; hasFacet: [ { @id: kb:birth-info-facet-fa1faab5-f212-4ab5-ae09-6937ca06e847, @type: identity:BirthInfoFacet, identity:birthdateRangeEnd "1984-08-20T00:00:0.0Z", }, { @id: kb:physical-info-facet-4449a465-f561-4e32-9716-4853757985ea, @type: identity:PhysicalInfoFacet, identity:hairColor "Brown" ].

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. This should absolutely be done using an Individual object of the Person class. I just realized there is an even bigger problem/error with Victim that I can't believe I did not catch earlier. Victim should not be a subclass of NeutralRole. Victim should be an Individual of the NeutralRole class. It IS a specific role not just a type of role. I could see how this oversight could be the cause of a lot of the confusion around this. I apologize for not noticing sooner. To characterize that this person John Doe was the victim of some malicious activity you would simply specify a Relationship object where kindOfRelationship="hasRole", source=, target=Victim (the predefined role Individual), and startTime=.

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 . I agree with Alex that the "how" he was a victim is best characterized in an Event (something like "Death during robbery at Company X, Office Y on date Z") object using eventType (something like "Death"). That Event could reference a specific Action (something like "Kill" (I would recommend against presuming "Murder" as the killing could be murder, manslaughter, or an accident)) for the killing in the eventContext property which would specifically link to the Identity object of the victim using the 'object' property; and a specific Action (something like "Rob") for the robbery. Both the Kill and Rob Actions could reference the location.

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.

[sbarnum]

I think today's English definition of VictimTargeting today would lean more towards option B (metaclass)...

A victim targeting is a grouping of characteristics unique to people or organizations that are the target of some malicious activity.

...except, on reviewing all of the classes entailed by just being a identity:Person, the Sean graph-node is all of these:

• identity:Person: "A person is a grouping of identifying characteristics unique to a human being regarded as an individual."
• identity:Identity: "An identity is a grouping of identifying characteristics unique to an individual or organization."
• core:IdentityAbstraction: "An identity abstraction is a grouping of identifying characteristics unique to an individual or organization. This class is an ontological structural abstraction for this concept. Implementations of this concept should utilize the identity:Identity class."
• core:UcoObject: "A UCO object is a representation of a fundamental concept either directly inherent to the cyber domain or indirectly related to the cyber domain and necessary for contextually characterizing cyber domain concepts and relationships. Within the Unified Cyber Ontology (UCO) structure this is the base class acting as a consistent, unifying and interoperable foundation for all explicit and inter-relatable content objects."
• core:UcoThing: "UcoThing is the top-level class within UCO."

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.

• foaf:Person: "A person."

• prov:Person: "Person agents are people."

  • prov:Agent: "An agent is something that bears some form of responsibility for an activity taking place, for the existence of an entity, or for another agent's activity."
• schema:Person: "A person (alive, dead, undead, or fictional)."

If UCO were using the definition style of these other ontologies, today's wording of VictimTargeting would firmly suggest it is a metaclass. But, given the wording style of current classes where most everything in UCO is "a grouping of characteristics about a thing X," rather than "an X," victim:VictimTargeting seems to verbally fit under identity:Identity as a subclass.

@sbarnum , your input on B vs C would still be appreciated. But, it seems current design suggests option C.

I will assert fairly strongly that it is not A, B, or C. A specific victim targeting characterization must be an Individual and not a class (subclass) as the pattern fit between a given Identity and the victim targeting pattern is not permanent across the lifespan of the Identity or of the victim targeting pattern. Characteristics of the Identity may change over time leading to a fit at some times and not at others. The same could be said of the victim targeting pattern as it may be adjusted by investigators as they learn more over time or the subject changes their MO. The even bigger issue as I explained above is that non-ontologist users need to be able to specify VictimTargeting patterns and defining them as classes is not practical. Hopefully, the characterization in my above comment is clear. It should fully support all of the capabilities and aspects I have seen here.

[sbarnum]

@sbarnum : In the example graph, let's say you're actually victimized, and not just a member of the VictimTargeting subclass kb:PersonType-0ade6e45-....

What is the victim:Victim object?

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.

1. If an person was a victim but did not fit any victim targeting characterization then you could define the Person object for them and then assert a "hasRole" Relationship from the Person object to the Victim object.
2. If a person fits a victim targeting pattern but is not actually victimized then you could define the Person object for them, define an Individual (user-defined) VictimTargeting object for the targeting pattern, and then assert a "fitsVictimTargeting" Relationship from the Person object to the Individual (user-defined) VictimTargeting object.
3. If the person fits a victim targeting pattern AND was a victim then you could combine number 1 and number 2.