Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to determine the specific type of a supporting publication #410

Open
mbrush opened this issue Mar 25, 2023 · 2 comments
Open

How to determine the specific type of a supporting publication #410

mbrush opened this issue Mar 25, 2023 · 2 comments

Comments

@mbrush
Copy link
Collaborator

mbrush commented Mar 25, 2023

KP can provide different types of documents back as “supporting publications” (e.g.journal articles, white papers, pre-prints, patents, package inserts, guidelines, web pages, etc). . The UI wants to know the doc/pub type to support users filtering/searching on this information - e.g, a user may want to filter down to edges/results supported by patents specifically.

If we allow for / require all supporting publications to be grouped together in one Attribute object as a list, per the supporting publications specification - how do we indicate the specific type of a given publication in the list?

@mbrush
Copy link
Collaborator Author

mbrush commented Mar 25, 2023

Per discussion on March 16 and March 23 Data Modeling Calls, we propose the following approach:

  1. Per the guidelines outlined in Representing Supporting Publications in TRAPI #409, KPs will reference supporting publications using CURIE identifiers whenever possible, and create new curies from urls by defining prefixes and mappings in theBiolink/Translator prefix map, where url patterns allow for this). e.g.
pmids/pmcids/dois →   already registered
wikipedia pages →     wikipedia:[id]
dailymed articles →   dailymed:[record id]
patents →             uspatent:[patent id]
. . . 
  1. SRI will define new Publication subclasses in the Biolink model representing the types of Publications we want to be able to distinguish between. e.g.
Publication
    JournalArticle
      	PrimaryLiterature
       	ReviewArticle
        CaseReport
    Patent
    PrePrint
    WhitePaper
    WebPage
    DrugLabel
  1. SRI will define a prefix → publication type mapping for each prefix KPs use to references supporting publications. This may be done in the id_prefixes property of the publication class definitions (as exemplified below), or in a separate file.
  Journal Article:
	is_a: Publication
	description: >-
  	   . . . 
	id_prefixes:
  	- pmid
        - pmcid
  1. Where it is not possible to define a CURIE for a given type of publication reference (e.g. the source/url pattern cannot easily be curified), KPs will use a URL to reference the publication. e.g. "http://info.gov.hk/gia/general/201011/02/P201011020204.htm" (we won’t be able to determine a pub type in such cases, but hopefully these will be very rare).

  2. The UI team or anyone wanting to determine the specific type of a publication would have to look at each curie, and either:
    a. use the CURIE to retrieve semantic type from the Pub Metadata API (may get more precise types here, e.g. if Pubmed captures whether a journal article is a review, case report, or primary literature)
    b. for CURIEs not registered in the API, use the prefix lookup a semantic type (wherever we end up recording these prefix-to-pub type mappings).
    c. for references that us full URLs default to ‘web page’ or ‘publication’ as the semantic type.
    d. for any other text found in the publications field (e.g. ids without prefixes), use the general type 'Publication'.

@mbrush
Copy link
Collaborator Author

mbrush commented Sep 12, 2023

To Do: circle back with UI Team and determine what categories of Publications they want to be able to distinguish for display/grouping in the interface - and use these requirements to guide modeling here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant