Example-Step-1 Example Line#70~72 missing UCO namespace

[DrSnowbird]

Source of Issue:

• https://caseontology.org/examples/asgard/ (Step-1): Line# 70 ~ 72
  • These three lines are not 'legal' UCO/CASE properties.

The following three lines are not 'legal' UCO/CASE properties:
--- Current (Incorrect) Lines ---
{
"@type": "iPhoneDevice",
"uniqueID": "B3858A69A29375E6C706226B3633A3A11EB2A774",
"ownerName": "Loki iPhone"
},
--- Corrected (maybe) Lines should be like below: ---
{
"@type": "uco-observable:MobileDeviceFacet",
"uco-core:name": "iPhoneDevice",
"uco-observable:objectGUID": "B3858A69A29375E6C706226B3633A3A11EB2A774",
"uco-observable:owner": "Loki iPhone"
},

[ajnelson-nist]

Thank you, @DrSnowbird . We are aware of that facet being an issue, and are working through developing similar terminology for Android devices in the UCO Ontology Committee. Do you have a definition (English, with Apple documentation reference) of the terminology that should be used for those two fields?

Also, it would be better for this to be filed against casework.github.io, but I see now the Issues tab there is turned off, and I've asked after why that is. So you've done fine, thank you for reporting this here. I look forward to your assistance resolving the issue.

[DrSnowbird]

The suggestion that I wrote in my request is just one of the possible way to use UCO ontology. When applying ontology like UCO, I usually adopt the "minimalist" approach, i.e., Use the combination of any existing ontology terms to create domain specific use. If not possible, it maybe indicator that there is a need to either expand the upper ontology or extending the lower ontology (domain-specific, e.g., CASE) if the facets (multiple properties at least) with high common usage as one unit (or some called high cohesion among the sibling properties, e.g., the MobileDeviceFacet. That's why I was suggesting to just simple use the UCO's existing ones. The following suggests that we may need a "DeviceOwnerFacet" in UCO.

Note the following is just suggestion and I did not run against the UCO compliance checking (domain/range etc and SHACL):
{
"@id": "kb:suspect-device-uuid",
"@type": "uco-observable:ObservableObject",
"uco-core:hasFacet": [
{
"@type": "uco-observable:DeviceFacet",
"uco-observable:manufacturer": "Apple",
"uco-observable:deviceType": "iPhone",
"uco-observable:model": "13 Pro MAX",
"uco-observable:serialNumber": "F18Q4LGRG5MD"
},
{
"@type": "uco-observable:MobileDeviceFacet",
"uco-observable:keypadUnlockCode": "123789",
"uco-observable:IMEI": "359305065690067",
"uco-observable:MSISDN": "1239275339",
"uco-observable:clockSetting": "2019-03-30T22:36:24.35Z",
"localeLanguage": "no_AS",
"uco-observable:phoneActivationTime": {
"@type": "xsd:dateTime",
"@value": "2018-05-09T07:36:24.35Z"
},
"uco-observable:storageCapacityInBytes": 17179869184
},
{
"@type": "uco-observable:DeviceOwnerFacet",
"uco-observable:firstName": "Loki",
"uco-observable:lastName": "Hearts",
"uco-observable:password": "some-secret-password",
"uco-observable:color": "blue",
"uco-observable:case": "Ottobox",
"rdfs:label": "Loki's iPhone 13 Pro Max with Blue Ottobox",
"uco-observable:objectGUID": "B3858A69A29375E6C706226B3633A3A11EB2A774"
},

[ajnelson-nist]

DeviceOwnerFacet and the properties you suggested (some of which would need to change name to prevent some "basename" collisions) would take some discussion in the Ontology Committee. Would you be willing to champion a change proposal, similar to those listed on this page?

[DrSnowbird]

The DeviceOwnerFacet and the properties suggestion:

• It seems that there is a need for such a Facet to tie the Owner (from the perspective of the Owner to capture the properties needed) with the Device. Basically, Person/Owner--- 1:N --- Device (plural possible in a practical situation, drug dealers or cyber attackers mostly in the realistic situation would have multiple devices (phones (burned phones, etc.).
• The properties, yes, most likely need to be designed to provide non-conflicting, non-duplicating information - as you suggested.

I am not so deep-involved in UCO since I am more of an application-domain user. I am more focused on useability in general. For example, I like to use ontology IDE (my preference) Stanford's Protege (I have a few dockers in Protege in my GIT, you can look up them, "protege" including no-VNC-based Docker too) and, even have UCO-docker to bootstrap UCO ontologies for automatically loaded into Protege, and I soon will be releasing UCO-desktop-docker that will have all the curated RDF/OWL (UCO related) tools, editors, converters, etc. in X11-based Desktop Docker and noVNC-based Docker, etc. In short, my focus is more at practical usability and making how-to obstacles as none. For UCO, in short, I am not so much in the inner working of UCO (completeness, semantic aspect).

However, if I can be helpful and my time allowed (since I am spending a lot of my free time, as a freelance), in creating more productive A.I., ML, DL, GNN, NLP Dockers/tools for helping peer researchers) and my day job tasks, I would be glad to help. Hopefully, it is not a time-consuming to help your suggestion.