Flags for phenopacket types (manual, automatic, others?)

[jmcmurry]

Related to https://github.com/phenopackets/phenopacket-format/pull/27#event-584313124

Algorithms that aggregate phenopackets with the aim of determining causal relationships need the ability to distinguish phenopackets that are the result of automatic entity recognition (eg. from journal articles) from those that are the result of manual curation. I'm not sure if we want to get more granular than that (eg. computationally inferred and manually verified). Thoughts? @cmungall @DoctorBud @tudorgroza

[kshefchek]

It was my understanding that could be done with ECO evidence classes (or GO codes): Inferred from electronic annotation: https://github.com/phenopackets/phenopacket-format/blob/master/examples/level-1/omim-example-l1.json#L52 Observed: https://github.com/phenopackets/phenopacket-format/blob/master/examples/level-1/patient-example-l1.json#L58 but curious where we would put the IRIs or curies for these evidence types.

[jmcmurry]

@cmungall @DoctorBud does the model need to be modified to accommodate such distinctions? Kludgy temp fix could be to stuff the mining algorithm in as "author"? But last I checked we only had the designation "contributor".

[cmungall]

@kshefchek - the mapping from code to class IRI is done via JSON-LD, see @mbrush's comments here: #40

I think the evidence model should be extensible to allow complete precisionas to algorithm used etc. The best place to experiment with extensions here i a branch on the reference implementation

[mellybelly]

Evidence Any of the above elements may be linked to one or more evidence assertions.
Evidence could include items of the following:

• EHR record numbers
• published papers
• functional assays
• computational models
• population studies
• clinical trials

We should have a section of the doc explaining this with examples.