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

Paper not downloaded and no error is thrown #310

Open
raffaem opened this issue Jan 24, 2025 · 5 comments
Open

Paper not downloaded and no error is thrown #310

raffaem opened this issue Jan 24, 2025 · 5 comments
Labels

Comments

@raffaem
Copy link

raffaem commented Jan 24, 2025

Consider the following code:

works_from_dois <- oa_fetch(
  entity = "works",
  doi = c("10.3233/978-1-61499-432-9-116", "10.1016/S0168-1605(01)00734-6"),
  verbose = TRUE
)

It will return just 1 work (the second one) without giving you any error/warning why the first work was not returned

@yjunechoe
Copy link
Collaborator

Thanks! I can replicate this. It seems to be a problem on the API end, where a mix of valid and invalid DOIs silently drop the invalid ones from the search without throwing an informative message/warning

oa_fetch(
  entity = "works",
  doi = "foobar"
)
#> Warning in oa_request(oa_query(filter = filter_i, multiple_id = multiple_id,
#> : No records found!
#> NULL

oa_fetch(
  entity = "works",
  doi = c("foobar", "10.1016/S0168-1605(01)00734-6")
)
#> # A tibble: 1 × 39
#>   id                    title display_name authorships doi   publication_date
#>   <chr>                 <chr> <chr>        <list>      <chr> <date>          
#> 1 https://openalex.org… Anti… Antimicrobi… <tibble>    http… 2002-03-25      
#> # ℹ 33 more variables: publication_year <int>, fwci <dbl>,
#> #   cited_by_count <int>, counts_by_year <list>, cited_by_api_url <chr>,
#> #   ids <list>, type <chr>, is_oa <lgl>, is_oa_anywhere <lgl>,
#> #   oa_status <chr>, oa_url <lgl>, any_repository_has_fulltext <lgl>,
#> #   source_display_name <chr>, source_id <chr>, issn_l <chr>,
#> #   host_organization <chr>, host_organization_name <chr>,
#> #   landing_page_url <chr>, referenced_works <list>, …

You can see the query we constructed [here] - this returns a valid response, so {openalexR} happily parses it.

oa_query(
  entity = "works",
  doi = c("10.3233/978-1-61499-432-9-116", "10.1016/S0168-1605(01)00734-6")
)
#> [1] "https://api.openalex.org/works?filter=doi%3A10.3233%2F978-1-61499-432-9-116%7C10.1016%2FS0168-1605%2801%2900734-6"

I agree this is an issue but I'm hesitant to rush to implement a check on our end in case this can be fixed back over at OpenAlex.

@raffaem
Copy link
Author

raffaem commented Jan 29, 2025

Thank you.

Where do we go from here? We report it to OpenAlex?

@yjunechoe
Copy link
Collaborator

@trangdata do you know what's the appropriate channel for submitting issues w.r.t. the OpenAlex API? Do you think this issue falls under their scope of interest (or should we just handle it here)?

@trangdata
Copy link
Collaborator

Apologies for the delayed response: I'm on vacation until Feb 10.

Thanks for submitting the issue @raffaem. You can submit a ticket to the OpenAlex team at https://openalex.org/feedback

I agree with June that we should wait to hear from the OA team before fixing this issue in openalexR. This generic OR operator works for other filters as well, so I'm not sure a warning for anything that is missing would be helpful.

@rkrug
Copy link

rkrug commented Feb 3, 2025

Please note that doi has two meanings:

  1. DOI to get an individual work. (https://docs.openalex.org/api-entities/works/get-a-single-work_. Here an error is raised if the DOI does not exist.
  2. Doi is a filter (https://docs.openalex.org/api-entities/works/work-object#doi) here, the works corresponding top the filter are returned. If a filter does not match anything, nothing is returned and no error is returned

openalexR::oa_query() translates the doi argument into a filter, which is correct:
``https://api.openalex.org/works?filter=doi%3Afoobar`. This results in a warning if OpenAlex returns nothing (empty results) issued by openalexR which makes sense, while the second filter for doi does not result in an empty results, therefore no warning. This behavior makes perfect sense, as doi is translated into a filter.

Hope this clarifies.

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

No branches or pull requests

4 participants