Should SmartDevice be under Computer?

[ajnelson-nist]

Bug description

While discussing a phone concept with someone recently, I was showing a subclass hierarchy visualization, for uco-observable:SmartPhone:

(Non-raw file link)

I noticed that SmartDevice is not a subclass of Computer.

I'm having a hard time recalling if we intentionally set that to be the subclassing. I'm also having a hard time thinking of a smart device that is not, in at least some degree, a computer.

Should we shift SmartDevice to be a subclass of Computer, following the pattern used for a few similar shifts - warning if an instance of SmartDevice is not also additionally typed in user data to be a Computer?

Steps to reproduce

See the above figure.

[chrishargreaves]

Is AndroidDevice also intentionally not under computer?
Note the form factors within Android Studio device emulator (just a convenient list):

The definition you have for computer is "A computer is an electronic device for storing and processing data, typically in binary, according to instructions given to it in a variable program." If that definition remains it would seem there's rather a lot more that would fall under this definition (e.g. Gaming Console) which aren't currently, probably to the point where the classification of computers may be so broad it is most devices and doesn't have a lot of utility?

Personally I think the definition of computer could be a bit broad and 'computer' would better contain intuitive: Laptop, Server, (+Desktop) and separate out mobile devices and wearables, games consoles etc.

It requires a custom definition e.g.
"A computer is a general‑purpose laptop, desktop, or server used for productivity or general computing tasks (excluding smartphones, tablets, game consoles, and other dedicated devices).”
but I think this could provide more utility for differentiation?

[ajnelson-nist]

Likely a lot more can go under Computer---maybe all the Devices we have now. Before everything falls in, though, we might benefit from one class that is a Device, but *is notaComputer`.

Car would probably work. Nowadays there are many Computers that are part of a Car, but parthood doesn't make the entire Car a Computer, just like despite having organ parts I am not an organ myself.

[ajnelson-nist]

[...]
Personally I think the definition of computer could be a bit broad and 'computer' would better contain intuitive: Laptop, Server, (+Desktop) and separate out mobile devices and wearables, games consoles etc.

It requires a custom definition e.g. "A computer is a general‑purpose laptop, desktop, or server used for productivity or general computing tasks (excluding smartphones, tablets, game consoles, and other dedicated devices).” but I think this could provide more utility for differentiation?

@chrishargreaves : I agree we could also use a class to cover the case of desktops, those devices that are generally tethered to A/C. Thinking about size-scale¹ - under what class would an Arduino or Raspberry Pi go, in your mind?

From a forensic perspective, I would have game consoles under the (soon-growing?) hierarchy of Computer. Their storage devices can have file system forensics done on them; DFRWS had a challenge a (surprisingly!) long time ago pertaining to malware on the GPU of a PlayStation...3? 4? I've forgotten. IIRC, in that same challenge, Yellow Dog Linux was put onto the PlayStation.
The "Can it run Doom" family of projects (/challenges) suggests a great breadth of the class Computer, even beyond physical devices. I do suggest Computer remain physical in UCO.

Footnotes

1. Disclaimer: Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose. ↩

[packet-rat]

Reusing Existing Ontologies for Electronic Device Modeling in UCO

Context

Within the Unified Cyber Ontology (UCO) community, there is a need to expand device definitions to include modern electronic devices such as Android smartphones, tablets, and other mobile computing platforms.

However, defining a full device taxonomy inside UCO may not be optimal. Best practices in ontology engineering emphasize reuse, alignment, and layering, rather than re-creating concepts that already exist in well-established ontologies.

In particular, domains such as digital forensics and investigations require devices to be modeled in a precise and well-structured way, because devices may represent evidence objects.

This document surveys existing ontologies and linked data sources that could serve as reference points for modeling electronic devices.

---

1. Foundational / Upper Ontologies

These ontologies provide the conceptual grounding for physical artifacts and devices.

They are commonly used as the top layer of ontology stacks.

---

BFO — Basic Formal Ontology

BFO is widely used in scientific and engineering ontologies, particularly within the OBO Foundry ecosystem.

It provides core distinctions such as:

• material entity
• object
• artifact
• role
• function

Relevant Hierarchy

Material Entity

└─ Object

└─ Artifact

└─ Device

A smartphone could therefore be modeled as:
Smartphone

subclassOf Device

subclassOf Artifact

Advantages

• extremely stable ontology
• widely reused
• strong formal semantics

Possible UCO alignment

uco:ElectronicDevice

rdfs:subClassOf bfo:Device

---

DOLCE / DOLCE-Ultralite (DUL)

DUL is another foundational ontology frequently used in engineering and IoT modeling.

Relevant Hierarchy

dul:PhysicalObject

└─ dul:DesignedArtifact

└─ dul:Device

The SSN/SOSA ontologies align with DUL.

---

2. Engineering / Hardware Ontologies

These ontologies are closer to the hardware taxonomy problem.

---

EMMO — European Materials & Modelling Ontology

EMMO is one of the most modern engineering ontologies.

It is used in European digital engineering programs and materials science initiatives.

Relevant Hierarchy

Physical

└─ ManufacturedProduct

└─ Device

└─ ElectronicDevice

Smartphone Mapping Example

Smartphone

subclassOf ElectronicDevice

subclassOf ComputingDevice

Strengths

• good representation of engineered artifacts
• aligns with physics and materials science
• extensible hardware modeling

---

SAREF — Smart Appliances REFerence Ontology

Developed by ETSI for IoT devices.

Core Concepts

saref:Device

saref:Function

saref:Service

Example Modeling

Device

└─ MultiFunctionDevice

└─ Smartphone

SAREF is particularly useful for describing device capabilities such as:

• camera
• sensors
• network radios
• storage

---

3. IoT Device Ontologies

These ontologies are useful if UCO needs to represent connected devices and embedded sensors.

---

W3C SSN / SOSA Ontology

Developed by W3C and the Open Geospatial Consortium.

Focus areas:

• sensors
• actuators
• observations
• platforms hosting sensors

Example Hierarchy

sosa:Platform

└─ hosts

sosa:Sensor

Smartphone Example

AndroidPhone

sosa:hosts

AccelerometerSensor

CameraSensor

GPSReceiver

This model allows representation of smartphone internal sensors.

---

W3C Web of Things — Thing Description

The Web of Things standard provides a JSON-LD model describing device capabilities and interfaces.

Conceptual model:
Thing

└─ Device

└─ Smartphone

It can describe:

• device capabilities
• communication interfaces
• security schemes
• network endpoints

---

4. Linked Data / Knowledge Graph Vocabularies

These vocabularies have extremely large ecosystems and high coverage.

---

Schema.org

Schema.org defines a taxonomy for products and devices.

Example Hierarchy

schema:Product

└─ schema:MobilePhone

Potential extension:
MobilePhone

└─ Smartphone

Advantages

• large web ecosystem
• widely used by search engines
• integrates easily with RDF

---

Wikidata Ontology

Wikidata provides a large device classification hierarchy.

Example

electronic device (Q1183543)

└─ mobile phone

└─ smartphone

└─ Android smartphone

These are represented using Wikidata QIDs.

Advantages

• enormous device catalog
• continuously updated
• useful for entity linking

---

5. Digital Forensics Ontologies

These ontologies are closest to UCO's domain.

---

CASE / UCO Ecosystem

Relevant classes include:
uco-observable:Device

uco-observable:MobileDevice

uco-observable:Computer

However, these constructs are not deeply aligned with engineering ontologies, which creates an opportunity for improvement.

---

DFXML / Digital Forensics Ontologies

Common modeling patterns:
DigitalDevice

└─ MobileDevice

└─ StorageDevice

These ontologies are often custom-built and domain-specific, and rarely aligned with broader ontology ecosystems.

---

6. Device Description Repositories

Another useful concept is device capability description systems.

---

W3C Device Description Repository (DDR)

The DDR vocabulary describes device capabilities such as:
screenSize

inputMethod

colorDepth

deviceCapabilities

This approach is useful when describing web-connected devices.

---

7. Recommended Ontology Architecture for UCO

A layered architecture is typically the most robust approach.
Upper ontology

BFO / DUL

Engineering device ontology

EMMO / SAREF

IoT capability ontology

SSN / SOSA

Linked data references

Wikidata / Schema.org

Application ontology

UCO

This architecture allows UCO to reuse existing taxonomies rather than creating new ones.

---

8. Example Modeling Pattern

uco:AndroidSmartphone

rdfs:subClassOf uco:MobileDevice

rdfs:subClassOf saref:Device

rdfs:subClassOf emmo:ElectronicDevice

skos:exactMatch wikidata:Q94

This approach preserves interoperability across ontology ecosystems.

---

9. Additional Ontologies Worth Reviewing

Ontology	Domain	Why Useful
EMMO	Engineering	Formal device classification
SAREF	IoT appliances	Device capabilities
SSN / SOSA	Sensors	Smartphone sensors
Schema.org	Web knowledge graph	Product/device taxonomy
Wikidata	Linked data	Large device hierarchy
DUL	foundational ontology	artifact/device modeling
BFO	upper ontology	widely reused foundation

---

10. Recommended Strategy for the UCO Committee

Instead of defining device classes such as:
uco:AndroidPhone

uco:iPhone

uco:Tablet

uco:Laptop

UCO should define only abstract device categories:
uco:ElectronicDevice

uco:MobileDevice

uco:ComputingDevice

Specific device types can then be aligned with external ontologies using:
owl:equivalentClass

rdfs:subClassOf

skos:exactMatch

This prevents taxonomy drift, which is a common failure mode in security ontologies.

---

11. Potential Benefits

Adopting this approach provides:

• stronger semantic interoperability
• easier integration with external knowledge graphs
• improved long-term maintainability
• reduced ontology maintenance burden
• improved forensic device modeling

---

12. Possible Next Steps

Potential future work for UCO could include:

1. An OWL alignment proposal between UCO and engineering ontologies
2. A canonical device ontology stack for cyber investigations
3. A device taxonomy optimized for digital forensic evidence modeling

These artifacts could significantly strengthen device modeling within the UCO ecosystem.