observable:inReplyTo should behave the same as observable:messageID

[ajnelson-nist]

Background

(Ontology concepts noted in this Issue assume the observable: prefix unless noted otherwise.)

The properties messageId and inReplyTo pertain to RFC 822(/2822) headers for email. Take for example these lines drawn from an email in the m57 Jean scenario:

...
Message-ID: <KAEEIACFIHBPDJMPKNIPKEAGCAAA.alison@m57.biz>
...
In-Reply-To: <NNEEKAKACNPOIIMAAIIKEECACAAA.jean@m57.biz>

messageId uses a datatype property, range xsd:string, to store the value of the Message-Id header. However, inReplyTo is currently implemented as a core:Facet-housed object property, range ObservableObject.

Requiring an object is problematic in a few ways:

1. The reply relationship between two email objects fits more characteristics of a ObservableRelationship object than of a core:Facet-housed object property. Particularly, the association would likely have a chain of reasoning that led to its declaration.
   • The UCO Design Document should cover patterns for relating objects to objects in Section 6. The propose has not reviewed this section in depth yet.
   • The email object corresponding to the Message-ID header can be discovered from multiple evidence sources. To which object would an inReplyTo object-property link, in the rather?
2. At the time of parsing an email and coming across the In-Reply-To header, an email with that message identifier might not have been encountered yet. This can cause confusion in discovery order, and induce an object identity-resolution problem well worth avoiding.
3. If the In-Reply-To header is not included in signed headers, its content integrity may need reviewing.

There may be other issues, but the proposer hopes that is sufficient.

Requirements

Requirement 1

inReplyTo should be implemented in the same style as messageID.

Requirement 2

inReplyTo should be a owl:DatatypeProperty, range xsd:string.

Risk / Benefit analysis

Benefits

• Problems with object instantiation noted above are avoided.

Risks

• The submitter believes flattening to a string, while generally a risk in relaxing data-structural enforcement, is an improvement in this situation.

Competencies demonstrated

Competency 1

Under the current UCO implementation, this is an example parse result for inReplyTo and messageID that could be generated for the above M57 header values.

kb:email-message-d194bbe4-b430-4fd8-b59f-dea5649458b9
        a uco-observable:EmailMessage ;
        uco-core:hasFacet [
                        a uco-observable:EmailMessageFacet ;
                        # ...
                        uco-observable:inReplyTo kb:email-message-e73fabfd-1d58-4dad-b7a1-184419269ce0 ;
                        # ...
                        uco-observable:messageID "<KAEEIACFIHBPDJMPKNIPKEAGCAAA.alison@m57.biz>" ;
                        # ...
        ] ;
        .

kb:email-message-e73fabfd-1d58-4dad-b7a1-184419269ce0
        a uco-observable:EmailMessage ;
        prov:wasDerivedFrom kb:email-message-d194bbe4-b430-4fd8-b59f-dea5649458b9 ;
        uco-core:hasFacet [
                        a uco-observable:EmailMessageFacet ;
                        uco-observable:messageID "<NNEEKAKACNPOIIMAAIIKEECACAAA.jean@m57.biz>" ;
                        # ...and nothing else.
        ] ;
        .


kb:email-message-07d3f90e-01dc-40e2-9da6-153584fa0f2c
        a uco-observable:EmailMessage ;
        uco-core:hasFacet [
                        a uco-observable:EmailMessageFacet ;
                        # ...
                        uco-observable:inReplyTo kb:email-message-6b463cab-977e-4a09-acdd-a60d470784f8 ;
                        # ...
                        uco-observable:messageID "<QWERTY1234.alison@m57.biz>" ;
                        # ...
        ] ;
        .

kb:email-message-6b463cab-977e-4a09-acdd-a60d470784f8
        a uco-observable:EmailMessage ;
        prov:wasDerivedFrom kb:email-message-07d3f90e-01dc-40e2-9da6-153584fa0f2c ;
        uco-core:hasFacet [
                        a uco-observable:EmailMessageFacet ;
                        uco-observable:messageID "<NNEEKAKACNPOIIMAAIIKEECACAAA.jean@m57.biz>" ;
                        # ...and nothing else.
        ] ;
        .

Note the usage of wasDerivedFrom from PROV-O. This usage is due to some slight circularity in the chain of derivations, as the core:Facet-housed property links to something derived from itself.

If there are multiple independent replies to some message, and additional information is found about the replied-to message (say, some ported attachment), this representation might induce significant chain of custody and logistical trouble from trying to flesh out the knowledge of the replied-to message.

Competency Question 1.1

At least two emails are encountered with the same In-Reply-To header value.

To which emails did this user reply multiple times (forking, not continuing, the thread)?

SELECT ?nRepliedToMessage
WHERE {
  ?nReplyingMessage1
    uco-core:hasFacet /
      uco-observable:inReplyTo ?nRepliedToMessage .

  ?nReplyingMessage2
    uco-core:hasFacet /
      uco-observable:inReplyTo ?nRepliedToMessage .

  FILTER ( ?nReplyingMessage1 != nReplyingMessage2 )
}

Result 1.1

With inReplyTo as an object property, and a tool creating corresponding a "stub" EmailMessage object each time an In-Reply-To header is encountered, the above query will provide no results. This will likely be unsatisfactory to a user.

Competency Question 1.2

Suppose instead we use a datatype property.

kb:email-message-d194bbe4-b430-4fd8-b59f-dea5649458b9
        a uco-observable:EmailMessage ;
        uco-core:hasFacet [
                        a uco-observable:EmailMessageFacet ;
                        # ...
                        uco-observable:inReplyTo "<NNEEKAKACNPOIIMAAIIKEECACAAA.jean@m57.biz>" ;
                        # ...
                        uco-observable:messageID "<KAEEIACFIHBPDJMPKNIPKEAGCAAA.alison@m57.biz>" ;
                        # ...
        ] ;
        .

kb:email-message-e73fabfd-1d58-4dad-b7a1-184419269ce0
        a uco-observable:EmailMessage ;
        uco-core:hasFacet [
                        a uco-observable:EmailMessageFacet ;
                        uco-observable:messageID "<NNEEKAKACNPOIIMAAIIKEECACAAA.jean@m57.biz>" ;
                        # ...and maybe other things...
        ] ;
        .


kb:email-message-07d3f90e-01dc-40e2-9da6-153584fa0f2c
        a uco-observable:EmailMessage ;
        uco-core:hasFacet [
                        a uco-observable:EmailMessageFacet ;
                        # ...
                        uco-observable:inReplyTo "<NNEEKAKACNPOIIMAAIIKEECACAAA.jean@m57.biz>" ;
                        # ...
                        uco-observable:messageID "<QWERTY1234.alison@m57.biz>" ;
                        # ...
        ] ;
        .

Then the same question encoded in CQ1.1 can become:

SELECT ?nRepliedToMessage
WHERE {
  ?nReplyingMessage1
    uco-core:hasFacet /
      uco-observable:inReplyTo ?lMessageID .

  ?nReplyingMessage2
    uco-core:hasFacet /
      uco-observable:inReplyTo ?lMessageID .

  ?nRepliedToMessage
    uco-core:hasFacet /
      uco-observable:messageID ?lMessageID .


  FILTER ( ?nReplyingMessage1 != nReplyingMessage2 )
}

Result 1.2

The query would now return:

• kb:email-message-e73fabfd-1d58-4dad-b7a1-184419269ce0

It would then behoove the user to further review these discovered links, and declare any ObservableRelationships to codify results.

Solution suggestion

• Change observable:inReplyTo to an owl:DatatypeProperty, range xsd:string.

Coordination

• Tracking in Jira ticket OC-239
• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2022-05-12.
• Requirements to be discussed in OC meeting, 2022-05-17
• Requirements Review vote occurred, passing, on 2022-06-02
• Requirements development phase completed.
• Solution announced to OCs on 2022-06-02
• Solutions Approval to be discussed in OC meeting, 2022-06-14
• Solutions Approval vote occurred, passing, on 2022-06-14
• Solutions development phase completed.
• Implementation merged into develop
• Milestone linked
• Documentation logged in pending release page

[sbarnum]

I would support modifying observable:inReplyTo to be a DatatypeProperty with range of xsd:string.

I believe it was originally modeled in UCO as an ObjectProperty with the goal of making the reply chaining of the email message easier to understand as a UCO graph.

I agree that ObjectProperty approach is not closely aligned with the specific approach specified in RFC 2822 and therefore more problematic for a forensic capture of an email message as well as some of the other potential concerns outlined above.

I would make not that while the cardinality of observable:messageID is 0..1, the cardinality of observable:inReplyTo should be 0..*

I would also not that this same pattern change should be applied to the observable:references property as well.

[ajnelson-nist]

(Apologies for linking the mimeType PR, I had a misclick.)

[ajnelson-nist]

The review checklist has been completed on PR 397. This proposal takes care of some SHACL validation errors on the website.