Open ajnelson-nist opened 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. :-)
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".
Bug description
Reviewing the definition of
observable:ContactEmail
in today'sdevelop
branch state, it is unclear if there was an accident in implementation. It bears properties likeFacet
s do on other UCOObservableObject
s. It has no accompanyingrdfs:subClassOf
statement.What is the intended design of this object? A special-case
ObservableObject
, or just like otherObservableObject
s?Steps to reproduce
N/A