Voting on publications and supporting documents association slots

[mbrush]

This discussion was created for voting on one of the specific issues arising in #1107 - whether to maintain separate publications and supporting documents association slots, or collapse these into one.

---

Background:

The Biolink model currently has two association slots for linking a Statement or other information entity to a document/publication that 'supports it' (i.e. report the information or report evidence or provenance supporting it):

 supporting documents:
    is_a: association slot
    description: >-
      One or more referencable documents that report the statement expressed in an Association, or provide 
      information used as evidence supporting this statement.
    range: uriorcurie
    multivalued: true
    examples:
      - value: PMID:12345678
 
  publications:
    aliases: ["supporting publications"]
    singular_name: publication
    description: >-
      One or more publications that report the statement expressed in an Association, or provide information used as 
      evidence supporting this statement.
    is_a: supporting documents
    multivalued: true
    range: publication

The publications property predates the supporting_documents property, and is widely used across KPs to link Edges to pubs that support them.

The supporting_documents property was recently added to support the TMKP in linking Text Mining Study Result objects to documents from which the mined text/sentence was pulled (These study result objects help to organize EPC information about a particular analysis of a sentence, so that users can keep EPC for different sentences that support a single text-mined Edge separate in the TRAPI message structure).

TMKP wanted a property more general than 'publications' because not all documents their tools mine are publications in the traditional sense (e.g. some are things like patents, or product inserts, etc).

The issue largely comes down to the semantics of what a 'Publication' is. Biolink defines it as follows:

"any published piece of information. Can refer to a whole publication, its encompassing publication (i.e. journal or book) or to a part of a publication, if of significant knowledge scope (e.g. a figure, figure legend, or section highlighted by NLP). The scope is intended to be general and include information published on the web, as well as printed materials, either directly or in one of the Publication Biolink category subclasses."

The definition here seems broad enough that it might cover the types of edge cases TMKP brought to the table above (patents, product inserts).

On the 2-28-23 EPC Call we discussed the possibility of collapsing these into a single property to simplify the model and data. Three options were presented to choose from. This ticket provides a forum for discussion and casting votes.

---

Voting:

We will use the voting scheme described below:

+2 Highest (heart) - Love this option
+1 High (thumb up) - Like this option
0 Medium (eyes) - Meh, no strong feelings either way about this option)
-1 Low Priority (thumb down) - We should not do this option

Please cast a vote using one of these symbols for EACH of the options below by the next EPC call on March 14, 2023 (i.e. don't just vote for one - pick the symbol that best expresses your feelings about all three options).
And feel free to use this Discussion to argue your case for your preferred choice, pose questions, or proposed additional options for consideration.

[mbrush]

Option 1: Maintain the two properties in Biolink

• publications would be the default, and continue to be used in the majority of cases.
• supporting documents would be used in edge cases where a KP believes the document they want to reference is not a 'publication'.
• The hierarchical relationship between these two slots would ensure query completeness - e.g queries for supporting documents will include supporting publications.

[mbrush]

Option 2: Collapse to a single publications property (deprecate supporting documents in Biolink)

• This approach gives the simplest model, and simplest implementation =, and requires the least data migration effort on the part of KPs (only TMKP would have to change their data to replace supporting documents with publications).
• But it assumes the definition of 'publication' is broad enough to cover all types of documents that might support a Translator edge (or that this semantic imprecision is not problematic for the small number of edge cases we anticipate)

[mbrush]

Option 3: Collapse to a single supporting documents property (deprecate publications in Biolink)

• While this approach of defaulting to a more explicitly general property also gives a simple model, it requires more effort on the part of KPs to migrate data - as publications is in very broad use.

[mbrush]

In light of a new requirement from the UI team to encode the specific type of document/publication being captured (e.g. journal article, pre-print, patent, web page, etc) - we might want to reconsider our options/voting. See discussion in gdoc here.

[mbrush]

If we are concerned that the name publications will be confusing given the breadth of document types covered by this property, consider the property name published document instead?

[mbrush]

Closing, based on final decisions documented in the supporting publications specification here.