observable:ObservableRelationship should constrain the types on the objects it is relating

[ajnelson-nist]

Background

The observable:ObservableRelationship class is a subclass of core:Relationship. It currently encodes no specializations or restrictions on core:Relationship's properties.

Informal discussion has noted at times that the source and target on an ObservableRelationship should be observable objects. On review of the class hierarchy, and in deference to the freedom currently present in core:Relationship, it appears they should be observable:Observables, instead of observable:ObservableObjects. (For a diagram of where differences arise between observable:Observable and observable: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 (via core:source and core:target) are Observables.

Risk / Benefit analysis

Benefits

• Demonstrates value of creating specializations of core classes, such as core:Relationship being specialized by observable:ObservableRelationship.
• Encodes an expectation shared by some Ontology Committee members, but not yet formalized.

Risks

• Removes freedom currently present for users to use an ObservableRelationship to relate one thing that is an Observable and one thing that isn't. E.g., say an IT Asset Management system stores a core:Relationship between a server and a room, the former typed as an observable:Computer, the latter a location:Location, with core:kindOfRelationship value Deployed_In. Is it wrong if this core:Relationship is further typed as an observable:ObservableRelationship?
  • The resolution of this discussion could relax the proposal to require at least one of core:source or core:target be an observable: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:

observable:ObservableRelationship
	sh:property
		[
			sh:class observable:Observable ;
			sh:message "The source on an ObservableRelationship is expected to be typed as an Observable, and the noted value node is not.  This will be an error in UCO 2.0.0."@en ;
			sh:path core:source ;
			sh:severity sh:Warning ;
		] ,
		[
			sh:class observable:Observable ;
			sh:message "The target on an ObservableRelationship is expected to be typed as an Observable, and the noted value node is not.  This will be an error in UCO 2.0.0."@en ;
			sh:path core:target ;
			sh:severity sh:Warning ;
		]
		;
	.

For 2.0.0, reduce that addition to this:

observable:ObservableRelationship
	sh:property
		[
			sh:class observable:Observable ;
			sh:path core:source ;
		] ,
		[
			sh:class observable:Observable ;
			sh:path core:target ;
		]
		;
	.

Coordination

• Tracking in Jira ticket OC-302
• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2023-12-21
• Requirements to be discussed in OC meeting, 2024-01-18
• Requirements to be discussed in OC meeting, 2024-02-15
• Requirements Review vote occurred, passing, on 2024-02-15
• Requirements development phase completed.
• Solution announced to OCs on 2024-03-14
• Solutions Approval to be discussed in OC meeting, 2024-04-25
• Solutions Approval vote occurred, passing, on 2024-04-25
• Solutions development phase completed.
• Backwards-compatible implementation merged into develop for the next release
• develop state with backwards-compatible implementation merged into develop-2.0.0
• Backwards-incompatible implementation merged into develop-2.0.0
• Milestone linked
• Documentation logged in pending release pages
• Prerelease publication: CASE develop branch updated to track UCO's updated develop branch
• Prerelease publication: CASE develop-2.0.0 branch updated to track UCO's updated develop-2.0.0 branch

[ajnelson-nist]

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:

https://github.com/casework/CASE-Examples/blob/60ba58d/examples/illustrations/cell_site/cell_site.json#L153-L172

[ajnelson-nist]

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):

• https://github.com/casework/casework.github.io/blob/150554f/examples/owl_trafficking/owl_trafficking.json#L1155-L1166 - A location:Location Contained_Within a observable:File .
• https://github.com/casework/casework.github.io/blob/150554f/examples/owl_trafficking/owl_trafficking.json#L380-L391 - A identity:Person Has_Account a observable:EmailAccount .
• https://github.com/casework/casework.github.io/blob/150554f/examples/owl_trafficking/owl_trafficking.json#L392-L403 - A identity:Person Has_Account a observable:DigitalAccount .

[ajnelson-nist]

The meeting discussion date has been set to January 18th.

[sbarnum]

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.

[ajnelson-nist]

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:Observables. 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:

• Saying 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).
  • This could have downstream complexities in development of programming bindings.
• Saying 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.)
  • Those on the call agreed there was ambiguity in the end of the definition reading "observable objects": Does it mean observable:ObservableObjects, or core:UcoObjects that are observable:Observables? We did not decide whether the definition should be tweaked, now or for UCO 2.0.0.
• It is still possible to use core:Relationship to relate an Observable with a non-Observable.
• It is still possible to specialize 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.)
  • If we did define a subclass constraining a source to be Observables, and another subclass constraining a target to be Observables, we could then define ObservableRelationship, constraining source and target, as a subclass of both, forming a tidy lattice.

[ajnelson-nist]

CASE examples have updating PRs posted, which adapt data for the requirements voted on in last month's meeting:

• casework/casework.github.io@4154280
• casework/CASE-Examples@fcfa00b