search

ucoProject / UCO

This repository is for development of the Unified Cyber Ontology.
Apache License 2.0
76 stars 34 forks source link

observable:ContactEmail is an orphan, and looks like its current implementation was supposed to be a Facet #444

Open ajnelson-nist opened 2 years ago

ajnelson-nist commented 2 years ago

Bug description

Reviewing the definition of observable:ContactEmail in today's develop branch state, it is unclear if there was an accident in implementation. It bears properties like Facets do on other UCO ObservableObjects. It has no accompanying rdfs:subClassOf statement.

What is the intended design of this object? A special-case ObservableObject, or just like other ObservableObjects?

Steps to reproduce

N/A

sbarnum commented 2 years ago

This is not a bug.

As described in section 3 of the UCO Design Document, there are three kinds of classes in UCO: UcoObject and subclasses, Facet and subclasses and other classes with no UCO superclass. In the UCO RDFS/OWL/SHACL ontology, classes are defined for any relevant domain concept as well as for any structured concept characterizing some aspect of a domain concept. These are structured concept classes that specify into UcoObject classes, Facet classes and other classes.

All classes other than UcoObject classes are not separate objects in the domain graph but rather parts of UcoObjects in the domain graph. Fundamentally, there are really just domain objects (in the domain graph) subclassed from UcoObjects and non-domain objects (separate objects in the RDF graph but parts of domain objects in the domain graph). Facets are just special cases of the latter. They are special cases as they only appear as values of the core:hasFacet property on domain objects and they act as consistent mechanism for expressing characteristics of a particular aspect of a UcoObject as a whole (rather than only of a single property) and serve as a standard extension mechanism point for custom additions to UCO.

If you recall, in CP-430 we make all of these classes subclasses of the new core:ClassBase to this lack of clarity.

If you look at ContactMessaging, ContactPhone, WindowsPESection, core:ExternalReference, tool:BuildUtilityType etc. you will see there are of the same nature as ContactEmail.

So, in short, not a bug. :-)

ajnelson-nist commented 2 years ago

I have a really difficult time understanding why observable:URL gets a URLFacet, but the classes you just listed don't.

I think this necessitates another class, just under what's being proposed as the new top-level UCO class (did you see my suggestion it be called core:UcoThing?), for what you referred to as "Structured concept classes".