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.

>> the use of the word 'hierarchical' in that sentence was irrelevant.
   We've removed that word, but added a following paragraph to
   introduce these database concepts to the reader.

* 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.

>> Fixed this one and checked all URLs

* 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.

>> reconstruction of difference images within the IPP is regularly
   used, but an implementation of this process at MAST has not been
   developed.  The text has been modified to explain the concept and
   current status within the IPP.

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

>> correct -- URL to W3C specification added

* 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.

>> The linked microsoft technical report has not been published in a
refereed journal, but it has been placed on the arxiv, so we have adjusted the
reference to cite that article.

* 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.

>> Added words to describe the affected area.

* 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?

>> added a mention of the XML-to-LaTeX translation code.

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.

>> yes, these queries are meant for DR2.  Text updated to reflect this.

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.

>>> yes, we added a word of warning.

* 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.

>>> our retry confirms these numbers: numbers in text updated (for all three).

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

>> It is expected, added text to note and explain.

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

>> context for all examples is DR2

* 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.

>> the square brackets are always allowed, but are needed to protect
   table names with spaces or special words.  changed the examples to
   all used square brackets.  The _PS1 addition is meant to identify
   the table containing results for PS1 (vs Gaia) and would be
   appropriate for either DR1 or DR2 (both from PS1).

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?

>> should be all Hawai`i, except in the adjective Hawaiian

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

>> fixed

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

>> fixed

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

>> fixed (to R.A.)

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

>> "perform a set of..."

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

>> fixed (all double quotes)

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

>> fixed

* 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.

>> converted instances of XX arcsec to XX" where XX is numerical.
   Entries as units in tables and the rare case of a word (one
   arcsecond) are written out.

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

>> fixed

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

>> fixed

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

>> fixed
