Closed ajnelson-nist closed 2 months ago
The ITAM example I noted under Risks turns out to already have had an analogy hanging around among CASE-Examples. The Cell Site example uses that pattern - a cell tower Located_At
a location, and the relationship is an ObservableRelationship
. This object got flagged when I merged the PRs for this Issue into the unstable
test branches:
The CASE website had some other examples where just one side of an ObservableRelationship
is a subclass of Observable
(links are to today's data):
location:Location
Contained_Within
a observable:File
.identity:Person
Has_Account
a observable:EmailAccount
.identity:Person
Has_Account
a observable:DigitalAccount
.The meeting discussion date has been set to January 18th.
I agree with the proposal that the constraint should be to observable:Observable rather than observable:ObservableObject.
I believe that the constraint should be that at least one of either source or target should be observable:Observable rather than requiring both be observable:Observable.
In the meeting, we hit a stumbling point on the "either or both" matter. The summary of the discussion was that the spelling of Requirement 1 in this proposal remains as is: We are voting to require ObservableRelationship
constrain both core:source
and core:target
to be observable:Observable
s. Due to a participating committee member getting interrupted from the meeting, we are holding the Requirements Review vote in February's call.
The concerns boiled down to:
ObservableRelationship
requires EITHER would introduce a potentially significant logical complexity: we would need to implement a logical disjunction (sh:or
in SHACL, and if we get to it, owl:unionOf
in OWL).
ObservableRelationship
requires BOTH is consistent with the current English definition on ObservableRelationship
: "An observable relationship is a grouping of characteristics unique to an assertion of an association between two observable objects." (Emphasis added.)
observable:ObservableObject
s, or core:UcoObject
s that are observable:Observable
s? We did not decide whether the definition should be tweaked, now or for UCO 2.0.0.core:Relationship
to relate an Observable
with a non-Observable
.core:Relationship
with a subclass that always relates a source Observable
with another object that isn't constrained to be or not be a Observable
. But, what would we call that? (We had one suggestion, I think "SourceObservableRelationship", or another arrangement of those words.)
Observable
s, and another subclass constraining a target to be Observable
s, we could then define ObservableRelationship
, constraining source
and target
, as a subclass of both, forming a tidy lattice.CASE examples have updating PRs posted, which adapt data for the requirements voted on in last month's meeting:
Background
The
observable:ObservableRelationship
class is a subclass ofcore:Relationship
. It currently encodes no specializations or restrictions oncore:Relationship
's properties.Informal discussion has noted at times that the
source
andtarget
on anObservableRelationship
should be observable objects. On review of the class hierarchy, and in deference to the freedom currently present incore:Relationship
, it appears they should beobservable:Observable
s, instead ofobservable:ObservableObject
s. (For a diagram of where differences arise betweenobservable:Observable
andobservable:ObservableObject
, see the "Solution Suggestion" section of Issue 544.)Requirements
Requirement 1
An object asserted to be an
ObservableRelationship
should require that the objects it is relating (viacore:source
andcore:target
) areObservable
s.Risk / Benefit analysis
Benefits
core:Relationship
being specialized byobservable:ObservableRelationship
.Risks
ObservableRelationship
to relate one thing that is anObservable
and one thing that isn't. E.g., say an IT Asset Management system stores acore:Relationship
between a server and a room, the former typed as anobservable:Computer
, the latter alocation:Location
, withcore:kindOfRelationship
valueDeployed_In
. Is it wrong if thiscore:Relationship
is further typed as anobservable:ObservableRelationship
?core:source
orcore:target
be anobservable:Observable
.Competencies demonstrated
Competencies are omitted from this proposal, as the effects are new restrictions on data, and hence do not enable new expressive abilities.
Solution suggestion
Add the following to UCO for its next pre-2.0.0 release:
For 2.0.0, reduce that addition to this:
Coordination
develop
for the next releasedevelop
state with backwards-compatible implementation merged intodevelop-2.0.0
develop-2.0.0
develop
branch updated to track UCO's updateddevelop
branchdevelop-2.0.0
branch updated to track UCO's updateddevelop-2.0.0
branch