This is the project coordination repository of the Translator Evidence Provenance Confidence (& possibly Context) Modelling Working Group. The EPC Working Group Charter defines the group's mission and an EPC Issue Staging and Discussion defines and elaborates the technical scope of concerns.
For convenience of access, this project has a dedicated EPPC fork of the Biolink Model injected into this project as a Git submodule in the biolink folder of the project. The basic idea here is that we will make judicious EPCC revisions to this forked copy of the Biolink model,f or pull request merging into the main Biolink Model, once those changes are ready to be used by the Translator community.
Discussions about EPC integration with the Translator Reasoner Application Programming Interface (TRAPI) are ongoing. Progress (as of December 15th, 2020) is documented in a set of EPC modelling design notes and data encoding examples.
There are several somewhat independent TRAPI design issues relating to EPC data representations, only the first of which is near resolution (as of December 15th):
Proposed revisions of the Attribute data model schema of TRAPI is currently taken as an initial design iteration to enhance support for EPC annotations on edges (and nodes?) published from Knowledge Providers (KP). A core design consideration is a clear separation of concerns between the ‘value’ of an attribute versus its context of usage (or specific ‘relationship’ to the edge (or node) it documents. The proposed Attribute model revision also distinguishes between the original source's semantic labelling of the Attribute values and relationship, versus the Translator-specific semantic mapping of the value type and relationship. This is the main design issue discussed in the aforementioned December 15, 2020 meeting notes here and here.
The final nomenclature for the TRAPI Attribute schema properties related to design issue#1 above remains to finalized.
The concern about whether or not TRAPI Attributes require human readable names is to be decided (such Attribute names could be defined but optional). This relates mainly to the question about whether or not TRAPI JSON is mainly for programmatic versus human consumption, or how performant ontology lookup operations may be.
Encoding EPC metadata inside TRAPI Edge Attributes is the current TRAPI standard, but there may be some scientific or technical use cases that may support the idea of locating certain specific EPC metadata as direct Edge properties.
Could instances of TRAPI Attribute schema be permitted to contain “embedded" attributes and how might these be implemented?
A user conducts an initial Translator ARS query which returns a non-empty knowledge graph result. They wish to view all of the available EPC information associated with a specific edge assertion in the graph, so triggers a second the ARS to retrieve all said EPC information in a second query to the graph, using some suitable edge identifier.
a) Variant of 1: user provides specific EPCC information filters to constrain the information returned to specific types. b) Variant of 1 and 1a): the EPCC information returned default to 'shallow', 'breadth first', scope, so the user may ask for additional details about one or more specific components of the information returned (e.g. access details about underlying "evidence information objects" cited within the EPC).