patentsview

[crew102]

Summary

• What does this package do? (explain in 50 words or less):

This package provides a wrapper around the patentsview api, which serves USPTO patent data that has been disambiguated. There is one main function to search and download data from the API (search_pv) and several other helper functions.

• Paste the full DESCRIPTION file inside a code block below:

Package: patentsview
Type: Package
Title: An R Client to the PatentsView API
Version: 0.1.0.9000
Authors@R: person("Christopher", "Baker", email = "chriscrewbaker@gmail.com",
    role = c("aut", "cre"))
Encoding: UTF-8
Description: Provides functions to simplify the PatentsView API
    (http://www.patentsview.org/api/doc.html) query language,
    send GET and POST requests to the API's seven endpoints, and parse the data
    that comes back.
URL: https://github.com/crew102/patentsview
BugReports: https://github.com/crew102/patentsview/issues
License: GPL-2
LazyData: TRUE
Depends:
    R (>= 3.1)
Imports:
    httr,
    jsonlite,
    utils
Suggests:
    knitr,
    rmarkdown,
    testthat
VignetteBuilder: knitr
RoxygenNote: 6.0.1

• URL for the package (the development repository, not a stylized html page):
  master branch on github

• Who is the target audience?
  Researchers who want to interact with patent data. There are several specific use cases of patent data that have been listed in this thread of the rOpenSci discussion board.

• Are there other R packages that accomplish the same thing? If so, what is different about yours?
  I know of two R packages that one can use to download patent data: lensr and a development version of opsr. lensr is the most similar, as it can be used to download USPTO patent data. I do not know of any other packages that wrap patentsview, which is the only service that provides USPTO data that has been disambiguated.

Requirements

Confirm each of the following by checking the box. This package:

• does not violate the Terms of Service of any service it interacts with.
• has a CRAN and OSI accepted license.
• contains a README with instructions for installing the development version.
• includes documentation with examples for all functions.
• contains a vignette with examples of its essential functions and uses.
• has a test suite.
• has continuous integration with Travis CI and/or another service.

Publication options

• Do you intend for this package to go on CRAN?
• Do you wish to automatically submit to the Journal of Open Source Software? If so:
• The package contains a paper.md with a high-level description in the package root or in inst/.
• The package is deposited in a long-term repository with the DOI:
• (Do not submit your package separately to JOSS)

Detail

• Does R CMD check (or devtools::check()) succeed? Paste and describe any errors or warnings:

R CMD check passes with one warning regarding this being my first package submission.

• Does the package conform to rOpenSci packaging guidelines? Please describe any exceptions:

I believe the package follows the guidelines, but there are a few items I would like to highlight. These may or may not be issues:

1. The README does not follow the exact same format as described in the packaging guidelines.
2. I have added a cran-comment.md file which I plan on updating before submitting to CRAN.
3. I have not tagged the git repo yet, as I would like to wait for feedback before considering this version complete.

• If this is a resubmission following rejection, please explain the change in circumstances:

• If possible, please provide recommendations of reviewers - those with experience with similar packages and/or likely users of your package - and their GitHub user names:

[maelle]

Editor checks:

• [x ] Fit: The package meets criteria for fit and overlap
• [ x] Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
• [ x] License: The package has a CRAN or OSI accepted license
• [x ] Repository: The repository link resolves correctly
• Archive (JOSS only, may be post-review): The repository DOI resolves correctly
• Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

---

Editor comments

Thanks for your submission, @crew102! 😁 I'm currently looking for reviewers.

In the meantime here is the output of goodpractice::gp() that can help you and the reviewers. Note that reaching 100% code coverage isn't compulsory, the output just encourages you to write more of them.

It is good practice to

  ✖ write unit tests for all functions, and all package code in general. 55% of code
    lines are covered by test cases.

    R/check-query.R:8:NA
    R/check-query.R:9:NA
    R/check-query.R:61:NA
    R/flatten-pv-data.R:19:NA
    R/flatten-pv-data.R:20:NA
    ... and 139 more lines

  ✖ avoid long code lines, it is bad for readability. Also, many people prefer editor
    windows that are about 80 characters wide. Try make your lines shorter than 80
    characters

    R\check-query.R:12:1
    R\check-query.R:20:1
    R\check-query.R:38:1
    R\search-pv.R:57:1
    R\search-pv.R:71:1
    ... and 5 more lines

  ✖ avoid sapply(), it is not type safe. It might return a vector, or a list,
    depending on the input data. Consider using vapply() instead.

    R\flatten-pv-data.R:27:20
    R\flatten-pv-data.R:32:18
    R\print.R:14:8
    R\query-dsl.R:64:3
    R\query-dsl.R:67:3
    ... and 3 more lines

Using devtools::spell_check() I found these typos:

• equivlient search_pv.Rd:24,26

• paramater search_pv.Rd:13

• reccomened get_fields.Rd:18

• requirnments search_pv.Rd:26

---

Reviewers: @expectopatronum @poldham
Due date: 2017-05-24

[crew102]

Thanks for running those commands for me, @maelle. I have:

• Fixed spelling mistakes and added line breaks to code lines > 80 chars in length.
• Looked over all of my sapply calls and either changed to vapply or made sure that I had specified simplify = FALSE.
• Added additional unit tests.

The newest version of master is available here: crew102/patentsview@e6fdbc8

[maelle]

You're welcome @crew102! And nice work! 😺

[maelle]

Thanks @expectopatronum @poldham for accepting to review this package!

[poldham]

@crew102 @expectopatronum @maelle Just a quick note that I am working on the review at the moment, so @crew102 don't worry that we have forgotten!

[expectopatronum]

Me too! So far I have one remark: I think that in the method validate_endpoint in utils.R the error message

"endpoint must be a length 1 vector and be one of: "

might be confusing. I'm not sure if for an R novice it is clear that one element is equivalent to a vector of length one. Maybe the error message can changed to something like "endpoint must be a single element and be one of:"

I hope comments like this are ok here :)

[crew102]

Agreed that this is confusing. At several points I felt conflicted between precision and clarity (I actually dropped the phrase "vector of length one" in several places, thinking that it may be confusing...I guess I didn't do that here though). I will update this so it is less confusing.

[maelle]

@poldham @expectopatronum maybe useless since you've both been working on this but here is a friendly reminder that your reviews are due on Wednesday. 😸

[expectopatronum]

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

• A statement of need clearly stating problems the software is designed to solve and its target audience in README
• Installation instructions: for the development version of package and any non-standard dependencies in README
• Vignette(s) demonstrating major functionality that runs successfully locally
• Function Documentation: for all exported functions in R help
• Examples for all exported functions in R Help that run successfully locally
• Community guidelines including contribution guidelines in the README or CONTRIBUTING, and URL, Maintainer and BugReports fields in DESCRIPTION

Paper (for packages co-submitting to JOSS)

The package contains a paper.md with:

• A short summary describing the high-level functionality of the software
• Authors: A list of authors with their affiliations
• A statement of need clearly stating problems the software is designed to solve and its target audience.
• References: with DOIs for all those that have one (e.g. papers, datasets, software).

Functionality

• Installation: Installation succeeds as documented.
• Functionality: Any functional claims of the software been confirmed.
• Performance: Any performance claims of the software been confirmed.
• Automated tests: Unit tests cover essential functions of the package
  and a reasonable range of inputs and conditions. All tests pass on the local machine.
• Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

• The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 6

---

Review Comments

I'm very impressed by the code in the package, I think it is very well written and I enjoyed reviewing it! I only have a few remarks/comments.

• I installed and ran it successfully on Windows 10 (R-3.4.0) and Mac OS X (R-3.3.2)
• From my point of view the package follows most of the rOpenSci packing recommendations and follows all required things, in more detail:
  • It seems it does not generate the README.md from a README.rmd file and it does not include a code of conduct, however it is only a recommendation. I just wanted to point it out in case the author intends to change that.
  • It has the mandatory NEWS file.
  • Uses recommended packages (e.g. jsonlite)

Possibilities for improvement

• Testing is done for the main function search_pv and for error handling, which I think is very important. At first I thought there should be unit tests covering every exported function but after testing myself I think that it would be sufficient to add (a) test(s) for flatten_pv_data().
• Confusing error message in validate_endpoint already mentioned in my comment
• For convenience (since there is also get_fields()) a function get_endpoints() would be nice
• I tried to build my own queries and in one of them I tried to use location_longitude as a field for querying. I got an error location_longitude is not a valid field to query
  Error in if (f1$data_type == "date" && !is_date(value)) paste0_msg("Bad date: ", :
  missing value where TRUE/FALSE needed but I could not find out (using the help and the vignette) which fields are allowed for querying. Unless I missed something this should be added to the vignette/manual.