Creating AstroCat : Report on designing an interactive and dynamic online astronomical catalogue named AstroCat

(1)

Creating AstroCat

Report on designing an interactive and dynamic online

astronomical catalogue named AstroCat

Author: Charlotte Kortbeek

Supervisors: Rudy Wijnands & Bart Scheers

Physics & Astronomy Bachelor Project Report Conducted between 01-‐02-‐2014 and 01-‐07-‐2014 Submitted on: 10-‐07-‐2014 Second reviewer: Martin Heemskerk

(2)

(3)

Abstract

In the last months an effort has been made to start up AstroCat, an interactive dynamic online catalogue for X-‐ray binaries, using data from three existing catalogues of Liu, van Paradijs and van den Heuvel as starting point. The MonetDB relational database system is used to manage the database. The website is built using Shiny, a web application framework for R. AstroCat is now available online for a select group of people. In the first version of AstroCat users can search the data by name or by position. They can also see all data available in the database, edit this data when necessary and add new sources to the catalogue. This report provides those interested of detailed information on the project and the aim to make this catalogue a community project.

(4)

(5)

Populaire samenvatting

Vaak als sterrenkundigen bezig zijn met een onderzoek hebben ze informatie nodig over een bepaalde ster, bijvoorbeeld wat de positie van die ster is aan de hemel, welke andere namen ook wel gebruikt worden voor een ster, hoe helder de ster is of wat voor soort ster het is. Die

informatie kunnen ze dan vinden in een sterrencatalogus. Naast sterren zijn er nog veel

meer objecten en systemen te vinden in het heelal, zoals bijvoorbeeld röntgendubbelsterren. Een röntgendubbelster bestaat uit twee sterren: de zogeheten primaire ster en een begeleider. De primaire ster kan een

neutronenster of een zwart gat zijn. De begeleidende ster brengt materiaal over op de primaire ster. Hij wordt als het ware opgegeten door deze ster. Bij dat overbrengen van materiaal komt röntgenstraling vrij.

In dit project heb ik computerprogrammeren gecombineerd met sterrenkunde en AstroCat ontwikkeld. Dit is een online catalogus voor röntgendubbelsterren. Er zijn wel catalogussen voor röntgendubbelsterren, maar die zijn nadat ze zijn gepubliceerd nooit meer bijgewerkt. Dit is een probleem want de eigenschappen van deze bronnen veranderen nog wel eens. Ook worden elk jaar nieuwe

bronnen ontdekt en die zijn dan niet toegevoegd aan de catalogus.

Om uit te vinden wat voor informatie wetenschappers precies opzoeken in een catalogus en hoe zij vinden dat een online catalogus eruit zou moeten zien en zou moeten werken heb ik een aantal onderzoekers die werken met röntgensterren geïnterviewd. Zij bleken het belangrijk te vinden om makkelijk door alle

bronnen te kunnen zoeken, bijvoorbeeld op naam en positie. Ook wilden ze zelf de informatie kunnen veranderen, bijvoorbeeld de positie aanpassen of een nieuwe bron toevoegen. Het kunnen aanpassen is vooral belangrijk omdat de informatie over de sterren actueel moet zijn. Als onderzoekers zelf de informatie kunnen aanpassen als die niet meer klopt kunnen ze ervoor zorgen dat de

catalogus een betrouwbare plek blijft om gegevens voor onderzoeken te vinden.

Na twee maanden van programmeren is nu de eerste versie van AstroCat online voor een beperkte groep mensen. In deze eerste versie van de catalogus kunnen de gebruikers alle bronnen in de catalogus bekijken. Ze kunnen de gegevens van deze bronnen bewerken en als het nodig is nieuwe bronnen toevoegen aan de catalogus. Er moet nog wel wat werk gedaan worden aan AstroCat maar als de informatie is aangevuld kunnen onderzoekers een hoop tijd besparen door de catalogus te gebruiken. Ze hoeven dan niet meer door stapels artikelen te spitten

(6)

(7)

1 Introduction

1.1 X-‐ray binaries

A binary star system contains two stars orbiting around a common centre of mass. One is the primary star and is for X-‐ray binaries either a neutron star or a black hole. X-‐ray binaries are formed when the companion star transfers matter onto the (primary) object. These sources are the brightest class of X-‐ray sources in the sky (Lewin et al., 1995). Since the discovery of celestial X-‐rays in 1962, X-‐ ray binary research has been a steadily growing research field. By studying accreting objects such as X-‐ray binaries researchers have learnt a lot about the astrophysics of the end stages of stellar evolution. It is also important for our understanding of the physics of matter at extreme physical conditions for instance strong gravity and dense matter (Lewin & van der Klis, 2006). Other research areas are discovering what happens in the accretion disk, formation of binary stars and galaxies and population analysis. For more detailed information on the properties of X-‐ray binaries, see appendix B.

1.2 Motivation

Due to new and better instruments, the number of X-‐ray binaries and the information known about these sources has grown at a high rate in the last few decades. This growth of information is with no doubt a positive development, but due to this increase it is getting harder to find properties of individual sources and to perform population studies on X-‐ray binaries (See e.g. Jonker & Nelemans, 2004). The development of new tools to access this information is getting behind on the growth of the data pool. Scientists are losing a lot of time searching for information. Often they need multiple resources such as the Astrophysics Data System1_{,
or
even
use
Google
to
find
what
they
need.}

At the moment of writing there are only a few online catalogues for X-‐ray binaries and all of them are static, in the sense that they are not updated after

1_{http://adswww.harvard.edu}

(9)

they are published. These catalogues try to satisfy the need for a comprehensive data storage system that can be used to quickly find basic information about sources. However, the very nature of X-‐ray binaries makes that static catalogues are not ideal to accommodate the need of the community. Our knowledge about the properties of X-‐ray binaries keeps growing and new sources are discovered every year. These constant developments in the field make that static catalogues are already out-‐dated at the moment they are published, which is a problem for researchers that want to use the data in their work. An up-‐to-‐date, easy to use online catalogue would save a lot of time.

In the last months an effort has been made to start up an interactive dynamic online catalogue for X-‐ray binaries. It is still far from being the answer to all problems described above but it has the potential to be so in the future. This report provides those interested of detailed information on the project and the aim to make this a community project. The hope is that the joint efforts of scientists can make this catalogue a reliable source for information on X-‐ray binaries, and in the near future a lot of people can benefit from this project by using AstroCat in their everyday work activities.

1.3 Research question and aims for the project

The need for an alternative to static catalogues is without question. But it is not strange that there are so little online catalogues and that those that are online are all static ones. Creating and maintaining a comprehensive catalogue can get quite time consuming. Most people are interested in the catalogue for the time they will gain by using it and do not have time to build it from scratch. We decided to take on this project, and start a new catalogue for X-‐ray binaries from data out of three existing catalogues (see below). Therefore the question that stood at the foundation of this project was: How can we transfer data from a static catalogue into an interactive and dynamic online environment? The aim of this project was not only to initiate and create an online catalogue for X-‐ray binaries, but also to explore the best format for such a catalogue. How do you create a web-‐based catalogue that can be maintained by an online community? What would such a catalogue minimally have to offer for people to start using it? 1.4 Approach

It was clear from the start of this project that only a small part of the work that the catalogue need could be done in this short amount of time. But a firm foundation for AstroCat could be build from which the catalogue can grow over time. The first step in this project was to research the wishes and needs of the community and from that point form a project plan that made it possible to provide the community with a usable first version of the catalogue.

To define the aims and goals for this first version a small survey was conducted among four researchers in the field. See appendix A for more details on this survey. After doing this survey we realised that the most important tasks users will use our website for are searching the data (by name or position), editing the data and filtering the data (e.g only search on pulsars). Having reliable and up-‐ to-‐date data in the catalogue will be of vital importance for the success of AstroCat. With this in mind we started working on the database and the website.

(10)

More information on this stage of the project can be read in section 2.2. The survey will be discussed in the next section of this report.

AstroCat will not start as an empty catalogue but will use three existing catalogues of Liu, van Paradijs and van den Heuvel as starting point: High-‐mass X-‐ray binaries in the Magellanic Clouds (Liu et al., 2005), Catalogue of high-‐mass X-‐ray binaries in the Galaxy (4th edition) (Liu et al., 2006) and A catalogue of low-‐ mass X-‐ray binaries in the Galaxy, LMC,and SMC (Fourth edition) (Liu et al, 2007).

Further details on the functioning of the database, the user interface and the server will be given in section 3. This report will conclude with a perspective on the future of AstroCat in the section 4.

(11)

2 Project description

2.1 Survey

The survey was divided into four sections with questions about the potential users, the data, how to keep the catalogue up to date and possible visualisations to include in the website.

Potential users for the website are primarily researchers in the field, including PhD students, postdocs and maybe even master students. This means that the website is not intended for the broader audience. There is no need for a fancy layout and popular descriptions of the data. But the website does have to be easy to understand and easy to use.

Which data should and should not be included in a first version did not become very clear from the survey. Of course the respondents liked to have as much information about a source as possible but it depends on the research area of that particular person which data he or she prefers to be in the catalogue. What did become clear from the survey was that the reliability of the catalogue is going to be important. The catalogue will not provide an advantage over other catalogues if the data is not up-‐to date and correct. Also references to the papers from which the information comes will make the catalogue more useful. Since the data is at least seven year out of date when it enters the database, there will be a responsibility from the community to start updating and adding information, so that the catalogue can grow and gain the authority it needs to attract users. In the beginning there will be a small group of people that spends a considerable amount of time updating the catalogue. The hope is that soon a threshold will be reached and the work that people need to put in the catalogue is going to balance the time they gain from using it.

Since the aim is to make AstroCat a community project, there are choices to be made regarding the security/accessibility of the website. A Wikipedia-‐like structure was mentioned but it was also agreed that anonymous editing should not be possible. A structure where the administrators of the website have the possibility to add new users was also mentioned. Accounts are probably the best way to go. Some people can only view, others can also edit. There has not been a decision on the exact structure yet. This will remain to be determined at the moment the catalogue is released.

People are interested in having the possibility of making visualisations (e.g. graphs and maps) online. But it also seems that these visualisations need to be of high quality for the researchers to use them and prefer them to their own plotting programs. This means the visualisations have a low priority. If there is not enough data, or if the data is not up-‐to date conclusions drawn from the visualisations will be incomplete. Although no visualisations are included in this version of AstroCat, they will definitely add value to the platform in the future. One of the respondents indicated that he would like to be able to download the information from the website as well. We will add this functionality in the future so that the users have the possibility to take the data onto their own computers and making the visualisations themselves with other programs.

(12)

2.2 Designing the website and the database

AstroCat consists of two parts. A database and a website. At the beginning of the project decisions have been made about which frameworks, systems and languages were going to be used to build the catalogue. It was decided to make the database in the MonetDB2_{relational
database
system.
This
is
an
open-‐source}

database system developed at the Centrum Wiskunde & Informatica (CWI). The tasks of a relational database system are to store, read, write and update the data and to modify the data structure. MonetDB is a relational database system; this means links between different tables and data items can be made. MonetDB is one of the database systems used for the Low-‐Frequency Array (LOFAR) radio telescope (Swinbank, 2011). We have chosen not to use a framework for the database but to build the database for AstroCat from scratch, using Structured Query Language (SQL). This is a commonly used programming (querying) language used for database systems. The way we use it (without the use of any database specific syntax) makes it relatively easy to change to any other database management system that works with SQL. It also ensures that there will not be any limitations on the structure of the database. There are no constraints on the way tables are defined which often happens when a framework is used for the database.

The user interface is built using Shiny3_{,
a
web
application
framework
for
R}4_{.
R
is}

a statistical programming language and works well together with MonetDB (Mühleisen & Lumley, 2013). It is designed for statistical computing and graphics. R is effective in data handling and has integrated tools for data analysis (“What is R?”, July 2014). This make R a logical programming language of choice, especially with future expansions for the website in mind, such as tools for statistical analysis of the data and interactive graphs. The downside of using a framework like Shiny is that there are constraints on the design of the user interface. There are for instance only a limited amount of layout options available for Shiny application. For this project these limitations were not significant and did not limit the functionality of the website, but this might not always be the case. When the moment comes that the limitations of Shiny form a problem for the project it can be decided to rewrite the user interface in other languages like HTML and JavaScript, but this is unlikely to happen in the near future.

AstroCat 1.0 is now available on http://wikistats.ins.cwi.nl/astrocat/home for a select group of people (a username and password are required to access the webpage). At this moment the website is hosted by a personal computer at the CWI. This is a temporary solution until a permanent solution for hosting the website is found. Within the scope of this project we managed to implement a website that can function as a good foundation for future improvements. In the first version of AstroCat users can search the data by name or by position, they can see all data available in the database, edit this data when necessary and add new sources to the catalogue.

2_{http://www.monetdb.org} 3_{http://shiny.rstudio.com} 4_{http://www.r-‐project.org}

(13)

3 Technical details

3.1 Database

3.1.1 Data structure

Not all data from the original catalogues is included into this version of AstroCat. We choose to only use the data that is useful for this first version of the website and unambiguous. We also added some properties because they were missing in the original catalogues, such as the distance and an extensive list of different names used for a particular source. For a short description of every column of the tables in the database see appendix C.

A schematic representation of the database is given in Figure 2. Most information in stored in the main table catalogedsource. The primary key of this table is the column id. This means that every source is uniquely defined by its id. The key can be used to make references between tables. The tables cattypes and catnames are linked to the main table by a foreign key. The field catid functions as the foreign key in both tables. It uniquely identifies a row of the catalogedsource table (e.i. one source). In the cattypes table types are connected to sources. The first rows in this table could look like Table 1. From this table you can learn that the source with id 1 has two types associated with it. These types have type-‐id 2 and 3. The source with id 2 has one type with type-‐id 4 associated with it. The field typ in this table is a foreign key (a reference) to the field id of the types table. Table 2 shows the first four rows of this table. Now you can see that source 1 is an X-‐ray burst and dipping source. Catnames associates names to sources in the same way cattypes does with types. The ref columns of cattypes and catnames are momentarily empty since the functionality to add references is not available yet. But in the future a reference id stands in this column and it is linked to the reference table in the same way as the cattypes table is linked to the types table. For the same reason the table reference is empty at this moment. It is meant to be a table were metadata for the references is stored. For instance a link to the referenced papers on the ADS website and its full title.

catid typ ext ref

1 2 -‐ -‐

1 3 -‐ -‐

2 4 -‐ -‐

Table 1: cattypes

id code description

1 A Atoll 2 B X-‐ray Burst 3 D Dipping 4 E Eclipsing Table 2: types

(14)

Figure 2: Schematic representation of the database structure

reference id bibcode title catnames catid name ref types id code description cattypes catid typ ref catrefs catid ref catalogedsource id ra decl pos_err zone x y z Name types Pos Opt starlike disklike Porb Porb_err u_Porb Ppulse u_Ppulse Ppulse_err distance dist_err coldens coldens_err sptype unabs_minflux unabs_minflux_err unabs_maxflux unabs_maxflux_err abs_minflux abs_minflux_err abs_maxflux abs_maxflux_err notations

(15)

3.1.2 Loading the database

Figure 3 shows the file structure of the AstroCat web application. The folder AstroCat/db contains all files needed to load the data into the database. The data from the three catalogues of Liu, van Paradijs and van den Heuvel was downloaded in csv format from the website of the VizieR Catalogue access tool5

from the Strasbourg astronomical Data centre. The folder cats contains these files. When running load.sh (also in the db directory) the database is loaded and filled. The program load.sh makes sure everything is executed in the right order. The data from the catalogues is first loaded into tables that have the same setup as the original catalogue. Then the tables for the database are created and a subset of the data is loaded from the temporary tables into the tables of the database. We used ADS to find alternative names for the sources. These names are loaded into the names table from a separate text file.

3.1.3 MonetDB

The database management system MonetDB consists of multiple tools and a server. The server that runs the database is called mserver5. The interactive tool mclient can be used to read the data and write (change) the data in the database. The program monetdb is a tool to check the status of the database. The monetdbd tool (the MonetDB database server deamon) can be used to create, delete, start and stop database instances (different databases). These database instances are stored in a directory, which is often referred to as the dbfarm. (“monetdb.org”, July 2014)

3.2 Web Application

The user interface is build as a Shiny web application. Such an application has two components: a user-‐interface definition (code where you define how, when and where components such as text, input-‐ and output fields and tables are placed) and a server script which handles any interactive components of the website. Not to be confused with the server that hosts the website. The shiny server generates output components (mostly dynamically generated text) and reads input components (e.g. text fields, radio buttons, checkboxes, etc.). It handles all the reactive components (i.e. components that change when the user provides the application with input) of the website and the communication with the database (reading and writing data). Normally a simple shiny app has only one page that is generated with code from two files. The first is the ui.R file in which the user-‐interface is defined. In the other file server.R the server side of the application is defined (“shiny.rstudio.com”, July 2014). Our application works a bit differently. Since we wanted to make a website that consisted of multiple pages we changed the structure a bit.

The file structure of the AstroCat web application is shown in Figure 3. The directory shiny contains all files needed for the definition of the web application. As you can see the ui.R file and the server.R file are present but their function is slightly different than usual. The server.R file gets session information (mainly about the user) from the server on which the application

(16)

runs and makes a connection with the database. It also redirects the user to the different pages of the website. ui.R contains paths to the different pages of the website. The files with the code that defines the user interface of the pages are in the apps directory. Every page file has a server component and a user interface component. These two components have the same function as the ui.R and the server.R files in a basic shiny application described above with the difference that they are both defined within the same file. The www directory contains images for the website.

Figure 3: File structure of the shiny web application 3.2.1 Source files for the pages of the application

home.R

This is the file that defines the home page of the website. On this page the user can search the catalogue on name and position. The results are displayed in a table. The names of the sources are links to the details pages of the individual sources.

details.R

Defines the details page on which the details of an individual source are displayed.

edit.R

Defines the edit pages. This is where a user can edit al properties of the source. edit_names.R

In edit_names.R the page is defined where users can edit the names of a source. They can also add or delete a name and change the primary name of the source.

(17)

new_source.R

On the new source page, which is defined by new_source.R users can add a new source to the catalogue. First the user has to give a position for the new source. Then the database is checked to see if no other sources are within a radius of 0.5 degrees around this point. If this is not the case the user has to give a name for the source and then the source is inserted into the database.

delete_source.R

Defines the page where users can delete a source. They have to give the reason for deleting the source and have the possibility to add further explanation to the notes page. When a user deletes a source the source is not deleted from the database but flagged as deleted. This is so that users can still find the source in the database and see why it has been deleted, to prevent them from adding the source to the database again.

3.3 Server

At the moment of writing this thesis, the first authorization is done on the wikistats server of the CWI (the user has to provide a username and a password). After that the user is redirected to the shiny application, which runs on an nginx6_{server
on
a
regular
desktop
computer
at
the
CWI.
This
is
a}

temporary situation until a better solution is found for hosting the website. During the development of the website I hosted the website locally on my laptop. 3.4 Installation

The latest version of the MonetDB database management system can be downloaded from monetdb.org. In this project Shiny was used to build the user interface. R needs to be installed to make use of this framework. Shiny is a package for R. Packages for R can be installed in the R console. For the communication between the application and MonetDB MonetDB.R has to be installed, this is a package (extension) for R that makes it possible to communicate with the database using R. To have more possibilities for the layout of the webpage an extra package called ShinyBS was used. This package adds much of the functionality of Bootstrap, a HTML, CSS and JavaScript framework to Shiny. Sometimes functions from other R packages were used when building AstroCat, but I will not discuss all of them here. It is easy to find out which ones because they are always included on the top of the .R file.

(18)

4 Discussion an conclusion

This version of AstroCat is a fully functional website and users can already perform a lot of the tasks we intended to make possible. Nevertheless there are a couple of improvements the catalogue could really benefit from. Of which the most important is the possibility of adding references to papers for each source property. We made a start with developing the infrastructure for this feature, but it is not implemented yet. These references would give the catalogue more authority and at the same time would be useful for researchers looking for papers on a particular source. It should also be made possible to log any changes made to the catalogue. Additionally there should be a system that makes regular back-‐ups of the database. If anything would go wrong the backup of the catalogue could be restored. Next to these frequent backups and logs it would be very helpful for researchers to be able to make a reference to AstroCat when they use the data for an article. For this to be possible the catalogue could have a history of source information so that researchers can refer to a particular source in the AstroCat database at a certain point in time. Another possibility is to publish official releases of AstroCat so that scientists can refer to data they obtained from a certain version release of AstroCat.

Something else that could be improved is the accessibility of the website. Right now only a select group of people have a username and password for the website. It would be great if the security could be arranged differently so that you do not need to log in to access the website and see the information and only if the user wants to edit the data he or she needs to log in. This could be done as soon as a permanent solution for hosting the website is found.

One of the problems a community project like this is susceptible to is that there is a chicken-‐egg problem. For the catalogue to be up to date it has to be actively used. But for the website to be used it has to be up-‐to date. In the initial start-‐up period there will have to be a group of committed individuals that are willing to put a significant amount of their time in developing the catalogue. Adding missing data, adding sources, updating out-‐dated information, adding references, etc. The future will have to tell if the catalogue will be able to reach a certain threshold on which the community will be big enough to develop the catalogue on its own and individuals will actually win time by using the catalogue. It will also take a certain amount of time for the catalogue to gain the authority it needs to be a reliable source for research. This does not mean that when this threshold cannot be reached the catalogue will be a failure. It just means the community option did not work out and another way has to be found to keep the catalogue up to date.

In the motivation of this thesis I stated an alternative for static catalogues should be found. I absolutely believe AstroCat could be the solution. AstroCat still needs some work but after the improvements described above are implemented researchers can save a lot of time using this catalogue. If the community project works this can also be an incentive for other researchers to start similar community projects.

(19)

5 References

Caroll, B.W., & Ostlie, D.A. (2007). An introduction to modern astrophysics. San Fransico: Pearson Addison-‐Wesly.

Jonker, P.G., & Nelemans G. (2004). The distances to Galactic low-‐mass X-‐ray binaries: consequences for black hole luminosities and kicks. Monthly Notices of the Royal Astronomical Society, 354, 355-‐366.

Lewin, W.H.G., & van der Klis, M. (Eds.).(2006). Compact stellar X-‐ray sources. New York: Cambridge University Press.

Lewin, W.H.G., van Paradijs, J., & van den Heuvel, E.P.J (Eds.).(1995). X-‐ray binaries. Cambrige (UK): Cambridge University Press.

Liu, Q. Z., van Paradijs, J., & van den Heuvel, E. P. J. (2005). High-‐mass X-‐ray binaries in the Magellanic Clouds), Astronomy & Astrophysics, 442, 1135–1138. Liu, Q. Z., van Paradijs, J., & van den Heuvel, E. P. J. (2006). Catalogue of high-‐ mass X-‐ray binaries in the Galaxy (4th edition), Astronomy & Astrophysics, 455, 1165–1168.

Liu, Q. Z., van Paradijs, J., & van den Heuvel, E. P. J. (2007). A catalogue of low-‐ mass X-‐ray binaries in the Galaxy, LMC, and SMC (Fourth edition), Astronomy & Astrophysics, 469, 807–810.

Mühleisen, H., & Lumley, T. (2013). Best of Both Worlds – Relational Databases and Statistics. Proceedings of the 25th International Conference on Scientific and Statistical Database Management.

Swinbank, J. (2011). The LOFAR Transients Pipeline. Astronomical Data Analysis Software and Systems XX. ASP Conference Series, 442, 313-‐316.

Documentation. Retrieved from http://www.monetdb.org (2014, July 8).

What is R? Retrieved from http://www.r-‐project.org (2014, July 8).

The basic parts of a Shiny app. Retrieved from http://shiny.rstudio.com (2014, July 8).

(20)

Appendix A: Survey (Q&A)

Web-‐based interactive Dynamic X-‐ray Binaries Catalogue

The catalogue will start with information listed in the following 3 catalogues: • A catalogue of low-‐mass X-‐ray binaries in the Galaxy, LMC, and SMC:

http://adsabs.harvard.edu/abs/2007A%26A...469..807L (Liu et al. 2007) • Catalogue of high-‐mass X-‐ray binaries in the Galaxy:

http://adsabs.harvard.edu/abs/2006A%26A...455.1165L (Liu et al. 2006) • High-‐mass X-‐ray binaries in the Magellanic Cloud:

http://adsabs.harvard.edu/abs/2005A%26A...442.1135L (Liu et al. 2005) The catalogue should be web-‐based. That means it should be a website.

The catalogue should be interactive. That means researchers should be able to filter/sort/search.

The catalogue should be dynamic. That means that it will be possible for users to add new sources and edit sources that already are in the database.

The catalogue will start as a catalogue for X-‐ray binaries, but in the future it might be interesting to expand the catalogue to other sources.

In response to the introduction respondent 1 noted: I agree on all of these points. Particularly I would put emphasis on the last one. It would be great if you could have a “template” of a catalogue that can be easily adapted to any other type of sources or things that we want. That would save a lot of time! And would make this project have a higher impact.

Questions About the Data

1. The catalogues contain some basic information about sources. What would you normally use this data for? (For which tasks?)

Respondent 1: Very good question, and one which is difficult to answer, as we usually think about this when we face the problem. Every time there is a source which does something new, I tend to look in google and ADS and whatever I can use to get more information about it, and to see whether it is worth to do something with it (such as requesting new observations, etc). The catalogue will really help, because when finished, it will have the most important information about each source, saving me (and others) a lot of time. Also it should be a place where

different measurements are given, with the proper references. For example, it is not uncommon to find different distances to a given source. The differences come from different papers, so it would be good to quickly know which papers these are, and may be even have a 1-‐2 lines summary of the main difference.

Respondent 2: There are already many different answers possible here. I use it for many different things, for example searching for data about a source and searching for correlations between sources.

(21)

Respondent 3: Search for coordinates to check whether a transient is already a known source. Search for papers directly related to the source. Find parameters of the source (e.g., NH, distance, etc.)

Respondent 4: I rarely use the catalogue because the information is not up to date. If I want to know something about a source I Google it or I search trough a

database of scientific papers. I use the date when I write proposals and articles. 2. When you go trough the catalogue, as it is right know. What information

do you miss?

Respondent 1: I'm looking at lmxb.xlsx, if that was what I was suppose to do. The distance is missing, and actually many other things that you are not necessarily aware of. For example, we could add:

a. Presence or not of (and references to) b. quasi-‐periodic oscillations

c. observations in quiescence/ quiescence luminosity d. peak luminosity during outburst

e. date of discovery + satellite

f. number of outbursts detected so far ... g. average Mdot meassured ....

h. etc etc etc

So as you see, we could put in many more things, even more than I can think about right now. This is the reason why the format of the catalogue should be such that is easy to add new columns, or/and new characteristics. Of course the catalogue should be able to grow in any parameter you have.

Respondent 2: The most important thing is that the information that is in the catalogue is correct and after that up-‐to date.

Respondent 3: I do not normally use the catalogues of Liu. I would like to have an easy way to access the literature related to the source. CDS Simbad allows you to find all papers related to a source, but you get both those about the source and about similar sources. It would be useful to have the possibility to search **only** the papers **directly** related to the source.

Respondent 4: Minimum flux, the type and spectral type of the companion star.

About the users

3. Who do you think could benefit from a web catalogue?

Respondent 1: Everyone working on transient sources will benefit. Actually, in the next 5 years many new instruments will start working, which will be looking for the “transient sky”. So having such a catalogue will definitely help more and more people as it grows in content.

(22)

Respondent 2: Master en PhD students, researchers in the field (post-‐docs)

Respondent 3: People working on transient sources, since they have to check

whether a transient is new source or whether it was known before. It would be also useful when you search the literature related to a source of interest.

4. How big do you think the user group will be?

Respondent 1: I would say that at the beginning we will be only a few, maybe around 10... but that number will probably grow in time. My guess is that in a few years it could be more than 50 people using it on “daily” basis ..s. plus many more using it less often.

Respondent 2: Hundreds.

Respondent 3: It all depends how easy it is to use, but it can be a big community. E.g., for every new satellite or ground-‐based telescope that is able to detect transient sources in a large region of the sky will bring that community to use the catalogue.

5. Will there be a big enough group interested to keep the catalogue up to date?

Respondent 1: This will be like Wikipedia, and if people find it useful, then it will definitely happen. I think people will like to add the information from their own papers, and that will trigger other people to do the same thing. I foresee that it can be a slow chain reaction, but it should work out. We know a lot of people that would be interested in this.

Responent 2: Yes, that is now certainly the case.

Respondent 3: I don’t know the answer to this one. But as I said in my previous answer, with new telescopes/satellites (e.g. LOFAR, ASTROSAT, etc.), it can be large.

About the website

6. What should the web catalogue minimally offer, so that you would start using it?

Respondent 1: Good question again! Coordinates, discovery date, quiescence flux, NS or BH or what, pulsar or not, QPOs or not, dipper? Eclipses? Inclination? Optical counterpart? Radio emission? Jets? Sorry, I don't know which are the best ones or the most needed. It depends on what you are doing at the moment.

Respondent 2: Reliability.

(23)

Respondent 3: As I said above, I would like to be able to check coordinates and source parameters, but also links to the relevant literature.

Respondent 4: You should be able to search, sort and filter the data and the data has to be up to date. It should be easy to edit the information but there should also be supervision.

7. What else would you like to be able to do on a website like this?

Respondent 1: Definitely searching, downloading selected information (for example, downloading coordinates and distances to all sources in catalog), being able to order the table based on any parameter. It would be great if we could also have plotting possibilities.... that would be awesome, but I understand it will be more work.

Respondent 3: Besides use the data, be able to update the information myself. 8. Do you use websites like the one we are about to create? What do you

like/dislike about this website?

Respondent 1: Not many, as basically something like that does not exist. Of course I use simbad or catalogues like that, but there is nothing like that in X-‐rays, and it would be super great!

Respondent 2: not for X-‐ray binaries because such a website doesn’t exsist.

Respondent 3: I believe arxiv is this kind of site. You can upload your papers but you need to have an endorsement to be able to do that. I like that idea. It allows you to add information (in this case papers), but it ensures that things are not done by anyone with a web browser and access to the Internet.

About the visualisations

9. We would also like to include/add some visualisations (maps/graphs) to the website. What kind of visualisations would you be interested in? What kind of visualisations would help you analyse/interpret the data?

Respondent 1: Yes! I was mentioning something like that in the previous point. It would be great if we could plot one column versus another one, i.e. 2D plots.

Additionally, it would be extremely useful if we could also display images of the sky in different bands (selected by the user) to see where our source is. That would be extremely helpful! Direct links to papers would also help

Respondent 2: Maps en graphs are useful, but my experience is, that researches will want to make their own different plots, so for me this wouldn’t have the highest priority.

Respondent 3: I suppose sky maps would be helpful. It would be nice on the long run to be able to see spectra or images from different missions reduced in some

standard way, even if these would not be useful to do science. Something similar to what you get in the XMM Science Archive, or in the XMM tool Bird.

Creating AstroCat : Report on designing an interactive and dynamic online astronomical catalogue named AstroCat