mbrush
commented
1 year ago Proposal:
Given the state of affairs described above (i.e. the current preference of KPs to capture lists of pub ids in a single Attribute object, and the availability of TMKPs publication metadata endpoint to provision publication info on demand) the simplest path forward may be to:
- Establish the current practice of capturing multiple supporting publication ids as a list in the
valuefield of a single Attribute object, as the required standard/convention. e.g.
{
"attribute_type_id": "biolink:publications",
"value": ["PMID:31737390", "PMC:6815562"] ,
"value_type_id": "biolink:Publication",
"attribute_source": "infores:text-mining-provider-targeted"
}- Define a specific syntax for capturing these lists- as an array of Publication object references:
"value": ["PMID:31737390", "PMC:6815562"] # formal array of Publication object references
vs.
"value": "PMID:31737390|PMC6815562" # single string, pipe delimiters
"value": "PMID:31737390, PMC:6815562" # single string, comma delimiters- Any standard / general metadata about a pub (title, year, url, MeSH terms, journal, authors, ...) can be looked up using a publication id from the TMKP publication metadata service as needed - so no need to duplicate this in the publications Attribute object.
- make sure that all pub identifier types in the data can be used to lookup pub metadata in the TMKP service (e.g. may require a mapping/translation across pub identifier types, pmc - pmid - doi - . . . )
- Any additional / specific info about a pub that a KP wants to return that is not in TMKPs metadata service can be put into the
descriptionorvalue_urlfield of the Attribute object as desired by the KP (but note that there will be no structured way to link this info to a specific pub in the list). - For the specific use case of text-mined edges, we consider the standard for capturing and linking source sentence text and other NLP metadata to its source pub in #399.
(note that this KP is actually using the 
edeutsch
gglusman
Testing efforts have identified variability w.r.t. how publications and other documents are represented as support for Edges and Study Result objects in TRAPI messages. The Biolink Model provides two edge properties (
supporting_document, and its childpublications- which are the topic of the Biolink ticket here), as well as aPublicationclass.Here. I would like to finalize and document conventions for how these elements are applied in Attributes in TRAPI messages to structure this type of information.
Questions/Issues:
When to use these different properties? (ignore for now - as we are voting here on whether to have two properties at all))
How to represent the value of these properties? a. Current convention is to use established document identifiers such as pmids, pmc ids, dois, etc. Should there set an order of preference here, or a requirement to use one over another (e.g. if a pub has a PMC id and PMID, always use the PMID)? Do we have a resource that maps between different types of identifiers for documents/publications?
In cases where there are multiple documents/pubs supporting a given Statement or Study Result, should these be captured as a list/array of document identifiers in the
Attribute.valuefield, or one at a time in separate Attribute objects?a. It was decided earlier that separate attributes were best - as this would allow for additional metadata about each publication to be captured in other Attribute fields (e.g. url, description/title, etc). But it wasn't clear if this was a requirement or recommendation? b. In practice, most KPs are providing lists of pmids in a single Attribute - esp in cases where there are very many supporting pubs (can be tens to hundreds in some cases). But the format/syntax used to represent such lists is varibale (e.g. a single string vs formal array of object references? if a string, use of comma vs pipe delimiters?)
Where/how should we capture additional metadata about a publication (e.g. title, year, url, MeSH terms, journal, authors, etc)? a. Some of the use cases for applying such additional publication info are outlined in the ticket here - most relate to supporting O& O for ordering results, and which pubs to show first for a given result. b. Some of this info could be captured using Attribute fields such as
value_urlordescription(see json example below) - but this doesn't work if we allow multiple pubs as a list in a single Attribute object.c. But TMKP already provides a publication metadata API that provides the types of info listed here - so representing an yof this in the
publicationsAttribute seems duplicative. d. @bill-baumgartner I assume here that Publication/Documents are represented as instances of Biolink:Publication, which has a collection of node properties for describing things like title, authors, etc?