/examples/illustrations/src/illustration-nosrc.mk needs its case_validate call tweaked.

There is some nuance in figuring out how this would work with prerelease states.

I found the following problem when checking the validity of UUID definitions in the file 'network_connection.json'
The "@graph" collection definition is missing from the example

"@graph": [
]

the proposed change is to insert the missing lines of code in the network_connection.json example between lines 15-16 and 452-453, and indent the lines 16-452 accordingly.

i.e

1 {
2 "@context": {
:
15 },
"@graph": [
16 "@id": "kb:bundle-2a13e958a-d975-41aa-b1bb-029d2b6707ab",
:
452 ]
]
453 }

Oresteia.json, in today's state (e87a8e0eabe54762fec1347ff0e563173f3ccac0), has a design issue with the Clytemnestra iPhone.

The issue is in this excerpt, where the two Facets were modified to have an @id solely for discussion here:

{
    "@id": "kb:clytemnestra-device-uuid",
    "@type": "uco-observable:Device",
    "uco-core:hasFacet": [
        {
            "@id": "kb:facet-1",
            "@type": "uco-observable:WifiAddressFacet",
            "uco-observable:addressValue": "d0:33:11:13:e7:a1"
        },
        {
            "@id": "kb:facet-2",
            "@type": "uco-observable:BluetoothAddressFacet",
            "uco-observable:addressValue": "d0:33:11:13:e7:a2"
        }
    ]
}

This is an instance of Facets confusing is-a vs. has-a object relationships. It is also an instance of a potential conflict when RDFS subclassing is used.

UCO Issue 445 details the issue with subclassing and a yet-unencoded design point. The issue is: If RDFS expansion (/inferencing) were applied, several more subclasses would be added into this snippet. I'll add just a few - there are significantly more that would be added, but what comes in is sufficient for demonstration.

{
    "@id": "kb:clytemnestra-device-uuid",
    "@type": [
        "uco-core:UcoObject",
        "uco-observable:Device"
    ],
    "uco-core:hasFacet": [
        {
            "@id": "kb:facet-1",
            "@type": [
                "uco-observable:DigitalAddressFacet",
                "uco-observable:WifiAddressFacet"
            ],
            "uco-observable:addressValue": "d0:33:11:13:e7:a1"
        },
        {
            "@id": "kb:facet-2",
            "@type": [
                "uco-observable:BluetoothAddressFacet",
                "uco-observable:DigitalAddressFacet"
            ],
            "uco-observable:addressValue": "d0:33:11:13:e7:a2"
        }
    ]
}

Informal discussion in committee meetings has led me to understand that an object should only ever have one instance of any particular Facet class. If that were encoded in OWL, that would mean that kb:facet-1 and kb:-facet-2, having a class in common, would be kb:clytemnestra-device-uuid's one instance of a DigitalAddressFacet. The relevant OWL mechanics (likely something about qualified cardinalities) would trigger a owl:sameAs inference, collapse kb:facet-1 and kb:facet-2 into one object with two IDs (or just duplicate all properties from either to the other), and then trigger a SHACL validation error because this DigitalAddressFacet would have two addressValues.

If UCO starts encoding how Facets correspond with their similarly-named UcoObject subclasses, this example in Oresteia will be a significant forcing function towards creating and relating separate objects.

Background

The MSISDN is in both the MobileAccountFacet and the MobileDeviceFacet, which is duplicative and conceptually incorrect. A phone number is not hardcoded into a device, and can be switched to different device. Therefore, MSISDN belongs in MobileAccountFacet, not MobileDeviceFacet.

Requirements

Requirement 1: Remove MSISDN from MobileDeviceFacet

Benefits

Eliminate duplicative properties and conceptual incorrectness.

Risks

The submitter is unaware of risks associated with this change

Competencies demonstrated

Competency 1

Removing MSISDN from MobileDeviceFacet does not change competency because the MSISDN is already represented in MobileAccountFacet which is can be linked to MobileDevice using a Relationship object.

Solution summary

• Remove uco-observable:MSISDN property from uco-observable:MobileDeviceFacet
• Update the following CASE-Examples to Remove MSISDN property from MobileDeviceFacet
  ** https://github.com/casework/CASE-Examples/tree/master/examples/illustrations/Oresteia
  ** https://github.com/casework/CASE-Examples/tree/master/examples/illustrations/mobile_device_and_sim_card

An email database such as a Microsoft Outlook email container can be represented as a file system within a file.

filePath: \Users\username\AppData\Local\Microsoft\Outlook\Outlook.pst

• Contains folder items: \Users\username\AppData\Local\Microsoft\Outlook\Outlook.pst\Inbox
  ++ Contains message items which can be represented as EML files and can contain email, contact, and appointment items
  +++ Contains contents which can be represented as an EmailMessage observable object
  Note: In addition to email body text, Outlook email items contain compressed RTF message body (bodyRaw), which can contain addition information than the body text.

See libpff documentation for details on PST file format:
https://github.com/libyal/libpff/tree/main/documentation

There is a need to establish a usage convention for representing searches performed using various software applications and online services, along with their results. Searches can return strings, data structures, and observable objects (e.g., URL, long lat location). Properties include:

• Timestamp of search
• Instrument used to perform search (application or online service)
• What was searched (e.g., text, image)
• The result(s) of the search

The proposed usage convention is a uco-action:Action representing a search performed by a specific user (uco-action:performer) using a certain application (uco-action:instrument). The uco-action:object lists input(s) to the search, and uco-action:result lists results of the search. The online service that was searched can be referenced as the uco-action:environment.

The example could use the Crossover data, specifically SearchedItem in Cellebrite XML report:

https://raw.githubusercontent.com/casework/CASE-Implementation-UFED-XML/main/XMLreports/19_UFED_ANDROID_CROSSOVER.xml

The same usage convention is proposed for an InvestigativeAction representing keyword searches performed on digital evidence using forensic/investigative tools.

This came up in discussion with @cyberinvestigationexpress , and is something I'd seen in the CASE PROV-O mapping, but hadn't gotten to raising yet.

There is an error in mapping Oresteia to PROV-O. The short technical summary is:

• PROV-O defines prov:Activity owl:disjointWith prov:Entity.
• The CASE-to-PROV-O mapping maps all uco-action:Action inputs and outputs to being prov:Entitys.
• Oresteia includes a case-investigation:InvestigativeAction that includes in its outputs another investigative action (kb:investigative-action4-uuid generating kb:investigative-action5-uuid).

The correct way to handle this, at the time of UCO 0.7.0, is to use the vocabulary term "Initiated"^^vocabulary:ActionRelationshipTypeVocab on a new uco-core:Relationship object tying kb:investigative-action4-uuid to kb:investigative-action5-uuid. (At the time of UCO 0.8.0, the untyped string "Initiated" should be used.) Note that there is currently no uco-core:Relationship subclass for actions like there is one for uco-observable:ObservableObjects; this was another mental blocker for me before I raised the matter.

I hadn't gotten to this because UCO would need to address whether the range of core:source and core:target would need to be defined as the intersection of core:UcoObject and the complement of action:Action. A deeper justification than "PROV-O has a owl:disjointWith statement" should be provided for that conversation - particularly, what modeling errors arise without that restriction.

@cyberinvestigationexpress , I suggest for now that the new Relationship object be defined, and the core:target usage be removed, to remove this CASE-to-PROV-O mapping error from the Oresteia example. If you agree this change should happen, I'll make the change.

The Oresteia example has incorrect usage of observable:MSISDN. The usage as of UCO 0.7.0 is for this to be a Datatype property, referring to a Literal value with datatype xsd:string.

There was some question on where this incorrect usage originated (Oresteia, or the mobile device and SIM card example), but after a git blame dive, the incorrectly-typed line was found to have originated in this commit.

It's unclear why the example tries to use this property as an object-reference to a MobileAccount object.

This needs to be corrected, first in Oresteia, in a manner that preserves original intent, which unfortunately was only documented in the Git history as "Updated mobile account representation."

Once Oresteia's corrected, other places where this error propagated (several of which are on the website) can be revised.