observable:userName seems it would be better as a string rather than a thing

[ajnelson-nist]

Background

observable:userName is currently defined as an owl:ObjectProperty with range of a generic observable:ObservableObject.

Requirements

Requirement 1: Change observable:userName from an owl:ObjectProperty to owl:DatatypeProperty, with range xsd:string.

Benefits

• Removes complexity of identifying an appropriate ObservableObject subclass to use for this property's range. One does not seem to exist. UserAccount seems closest, but represents a whole account, not just a name of the account.
• Follows pattern of string-identifier properties used in Account subclasses, such as observable:accountIdentifier.

Risks

• This property is not used in any CASE example, so there will be no impact to CASE-Examples or the CASE website.
• Any intended interaction of observable:userName is unknown with any AccountFacet, as observable:userName only appears on observable:URLFacet. No documentation exists to explain userName usage beyond URLFacet, or what annotations on the range ObservableObject would be.

Competencies demonstrated

Competency 1

Usernames used in a knowledge base can be retrieved.

With how the property is currently implemented, a SPARQL query for the literal-values of all usernames used in a knowledge base is currently unknown. It would look something like this, with every variable spelled verbosely:

SELECT ?lUserName
WHERE {
  ?nObservableObject
    a/rdfs:subClassOf* observable:ObservableObject ;
    core:hasFacet ?nSomeFacet ;
    .

  # Currently, the one implemented type is observable:URLFacet.
  # There will likely be a future proposal to add AccountFacet or a
  # related facet.
  ?nSomeFacet
    a/rdfs:subClassOf+ core:Facet ;
    observable:userName ?nSomeOtherObservableObject ;
    .

  # This object and the property-housing facet are currently not
  # described in the observable namespace.
  ?nSomeOtherObservableObject
    a/rdfs:subClassOf* observable:ObservableObject ;
    core:hasFacet ?nSomeOtherFacet ;
    .

  ?nSomeOtherFacet
    a/rdfs:subClassOf+ core:Facet ;
    ?nSomeProperty ?lUserName ;
    .

  # It is not clear which property ?nSomeProperty would be, but if we
  # had the concrete name, we wouldn't need this abstraction-describing
  # portion of the query.
  ?nSomeProperty
    a owl:DatatypeProperty ;
    .
}

A shorter version of that same query (also skipping all documenting comments) would look like:

SELECT ?lUserName
WHERE {
  ?nObservableObject
    core:hasFacet
    / observable:userName
    / core:hasFacet
    / ?nSomeProperty ?lUserName .
}

Adopting this proposal would reduce the longer-form query to:

SELECT ?lUserName
WHERE {
  ?nObservableObject
    a/rdfs:subClassOf* observable:ObservableObject ;
    core:hasFacet ?nSomeFacet ;
    .

  # Currently, the one implemented type is observable:URLFacet.
  # There will likely be a future proposal to add AccountFacet or a
  # related facet.
  ?nSomeFacet
    a/rdfs:subClassOf+ core:Facet ;
    observable:userName ?lUserName ;
    .
}

A shorter version of that same query (also skipping all documenting comments) would look like:

SELECT ?lUserName
WHERE {
  ?nObservableObject
    core:hasFacet / observable:userName ?lUserName ;
    .
}

Solution summary

Requirement 1 also fully describes the solution, implemented in PR 356.

Coordination

• Tracking in Jira ticket OC-229
• Requirements to be discussed in Ontology Committee (OC) meeting on 2022-03-22
• Requirements Review vote occurred, passing, on 2022-04-06
• Requirements development phase completed.
• Solution announced to OCs on 2022-05-10
• Solutions Approval to be discussed in OC meeting, 2022-05-17
• Solutions Approval vote occurred, passing, on 2022-05-27
• Solutions development phase completed.
• Implementation merged into develop
• Milestone linked
• Documentation logged in pending release page

[ajnelson-nist]

A git-blame dive showed there have been no substantive changes to this property's definition since its introduction in d5e6790. I did not review the class-property associations to see if it ever appeared on another ObservableObject subclass.

[ajnelson-nist]

When we get to the AccountFacet, we should keep observable:accountLogin in mind.

[sbarnum]

I agree that userName makes more sense as a string