This paper, on the whole is well-written, useful, and worthy of
Publication in ApJS. However, some minor revisions should be performed
before final acceptance.  Based on the publication dates of the other
Pan-STARRS1 papers listed in the introduction, and on other clues in
the paper itself, it appears this paper was originally written
c. 2016, and subsequently revised, but additional revisions are needed
to bring this paper fully up-to-date.

Issues with the substance of the paper
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* Not required, just curious: Is there any special reason why this paper is being
submitted so much later than other papers in this set?

>> All paper were delayed by the effort to produce DR2 and were
   submitted only about 9 months before this article.  The change of
   project by the first author further delayed this paper.

* Page 2, 1st paragraph: I understand the definition of a hierarchical database,
but that might be apparent to the average reader. A one-sentence definition
would be appropriate here. Also, even though the database is hierarchical,
it is also still a *relational* SQL database, so that should be mentioned as well.

>> TBD

* Page 2, Section 3: The release dates for DR1 and DR2 are mentioned here.
Were the databases available to the public on exactly those dates, or was there
any delay? For example, were DR1 *files* released in December 2016, but
the database was not ready until later?

>> These were dates when the PSPS DB was opened to the public (added note in text)

* Page 3, 1st line: Not all readers may be familiar with the glob-like notation
for sets of tables, e.g. Forced*. It might be useful to explain this notation
along with the other typographical conventions listed at the end of Section 1.

>> added a footnote to explain this nomenclature

* Page 3, Section 4: It would be more appropriate to use https instead of http.
In general, given that this paper was likely originally written several years
ago, all URLs in the paper should be re-checked for accuracy, and replace
http with https wherever that changeover has been made.

>> TBD

* Page 6, Section 5.1.6, last paragraph: Has the reconstruction of
difference images been demonstrated and tested? Please provide a
reference or give an example in the sample queries appendix.

>> TBD

* Page 10, Section 6.5: Isn't it Simple Object Access? Please provide a
reference and/or URL for SOAP.

>> TBD

* Page 19, Section 7.7: I understand the reason for using a number such as
-999 instead of the SQL NULL value. However the reference given is to the
EDR version of SDSS SkyServer, which was about 20 years ago. There must be
a published paper that describes this reasoning by now. Also the SkyServer
URL itself may well be invalid at this point, or the quoted text may have
changed. Please provide a reference to a published paper. The SkyServer
developers can probably assist with that.

>> TBD

* Page 21, Section 8.1.1: What total area of the sky is affected by the polar
astrometry problem (a fraction of 3pi is acceptable)? This may well be
described in Paper IV, but it's worth including a single sentence here.

* Appendix, Table Schema: The authors should detail how they ensure that all
the table and column descriptions are accurate. For example, what automation,
if any, is used to convert SQL table definitions into these LaTeX tables?

SQL Examples
~~~~~~~~~~~~

These examples are useful. I created a MAST account and ran all of the
SQL examples in this section. All of them worked, but I have some
suggested revisions.

* It is not clear from this section which specific context to use. I used DR2.

A particular database context should be explicitly mentioned and some names
should be checked for consistency with that context. You could also state
that the queries work in both DR1 and DR2, but in that case, expected results
should be included for both DR1 and DR2.

* Example 1: You should state that using COUNT instead of COUNT_BIG in this
example will not simply return an invalid value, but actually throw
an arithmetic overflow exception.

* Example 2: This query returned 3868 rows in DR2, not 3867.

* Example 4: This query returned 748 objects in DR2, not 747.

* Example 5: This query returned 1806 objects in DR2, not 1805.

* Example 9: Most of the objects selected have -999 for gMeanPSFMag.
Is this expected?

* Example 10: The name of the MyDB table implies DR2. Again, choose a specific
context or rename to be data-release agnostic.

* Example 12: Is there a reason the MyDB table name is enclosed in brackets in
one example and not the other? Also the '_PS1' name doesn't seem to be
consistent with the apparent DR2 context.

Spelling, Typos, etc.
~~~~~~~~~~~~~~~~~~~~~

These may be taken care of by the editors, but I have noted these to assist
revision process.

* In general: Hawaii or Hawai'i?

* In general: Check terms like 'Section', 'Table', 'Figure' (vs. 'Fig') for
consistency.

* In general: Spell SÃ©rsic consistently throughout the paper.

* In general: Choose a single notation for RA (RA vs. R.A.).

* Page 1, 1st paragraph: "perform as set of astronomical" -> "as a set".

* Page 2, Table 1: There seem to be several different quotation conventions in
the paper, e.g. `Release'. Elsewhere double quotes are used.

* Page 2, Table 1: "Tessellation Type" -> "TessellationType"

* Page 5, Section 5.1.4: in the description of SDSS apertures, double prime
(') notation may be more compact than 'arcsec' repeated many times.
In general it might be best to settle on a single notation for arcsec, since
both notations are used in the paper.

* Page 10: "csv, FITS or xml"; CSV and XML are acronyms just like FITS, so the
same typography should be used.

* Page 21, Section 8.1.1: "This issues" -> "This issue".

* Page 22, Section 9: Use official IAU designation for Oumuamua.
