User profile

This is where are the objects owned by the user are listed and can be managed. This includes the main SLED products, i.e. lenses, Imaging Data, Spectra, Redshifts, Generic Images, and Models, but also secondary objects that help with organisation, access, and overall convenience, i.e. saved queries, collections, and groups. Notifications and tasks are also listed here, the latter being very important for the funcionality of the website. This is also where the user can keep their personal information up-to-date, which is required to enable efficient completion of tasks and communication with other users.

Roles

There are 3 special user roles:

1. SuperAdmin: This is the user who decides who can assign the role of Admin and Inspector to other users.
2. Admin: This is a small group of users, usually 2, who have a higher degree of responsibility. They are the ones who can approve or reject new users, making public objects private, deleting public objects, etc, see the tasks for more details.
3. Inspector: This group of users has the responsibility to visually inspect any public images uploaded to the website and ensure that they are indeed related to science, e.g. lens mugshots, Imaging Data, Spectra, etc

The SuperAdmin can re-assign these roles at any time

Limits

Every user has a limited number of objects that they can create in the database per week and that they can own and manage in total. These numbers default to 100 and 1000 respectively, but they can be changed by the SuperAdmin upon request. These settings may be changed in the future to impose limits per object type, e.g. it makes sense to manage hundreds of lenses but not so much for groups or saved queries.

Access level

Any object that can exist in SLED (lenses, data, models, collections, etc) can be publicly visible and accessible by any registered SLED user, or kept private with its access directly controlled by its owner. Private objects will still appear in the queries of every user with access to them, but not to other users. A private object can be readily changed to public, but the opposite requires approval from the database administrators. It is good practice to inject objects as private and then, after ensuring that there are no mistakes, change them to public.

User groups

Creating groups of users is a convenient way to delegate access to private objects more easily. For example, one user adds 5 new lens candidates that they want to share with their close collaborators. The lenses are created as private, a group with the collaboration name is created (can also be private) and the collaborators are added to it, and the owner of the 5 private lenses gives access to the group instead of each user individually. This has the extra benefit that any new user who joins the group will automatically gain access to private objects accessible by the group. All groups are visible to all users, but the members of private groups are not shown. Any user has the option to request to join the group and a 'Join Group' task will be created for the group owner to resolve.

You can perform joined queries on Lenses, data (Redshifts, Imaging Data, Spectra, and Catalogue Data), and Models. For the position of the lens, you can limit the coordinates in a rectangular (box search) or in a circle around some point (Cone search). Placing the mouse above each field label provides some information about it (units, etc). Once you have filled in a few query fields, then you can save the query and access or modify it in your User profile page. You can also save all or part of the returned lenses in a new or existing Collection. The Collection will contain the returned results at the time of creation while the query will return any new lenses that may be added in the future. It is possible to select which lenses and associated to download in .json format.

Coming soon: querying lens Models and classification Scores.

Standard queries

These are some very common queries that are centrally available, for example, to return all the lensed quasars, lensed supernovae, lenses with HST data, etc. For comments or additions to these standard queries please contact the administrators.

Collections

A Collection is a fixed list of lenses, as opposed to a (dynamic) query, that users can create. It can be private or public, its management after creation can be passed on to another SLED user, and lenses can be removed or added to it. The latter can happen either by selecting lenses from a query result, or through the detail page of a given lens. Collections can be searched by any user. Currently, there are only collections of lenses allowed, but this may be extended to models, etc, in the future.

API queries

For large queries, it is advised to use the API functionality. The following fields are allowed to be passed explicitly to an API call:

Lenses

Redshifts

Imaging Data

Spectra

Catalogue Data

Models

Management

Download options

Lens

Everything in SLED (papers, collections, models, etc) is 'anchored' around lenses. The minimum requirements for a lens are its coordinates and a 'mugshot' image. This image doesn't need to be of scientific quality and can just be a pretty, colored, processed, etc, image of the lens. Images of public lenses will need to be visually inspected first through an Image Inspection task. The allowed choices of fields like 'image_conf', 'lens_type', etc, are pre-defined - additional choices are possible by contacting the admins. The 'score' field is temporary and will be replaced in the future.

Imaging data

These are images of the system taken with a specific instrument configuration. We do not store the actual data, for example, the raw pixel values in .fits format. We just store an image of the lens in a common format (e.g. .png) and its metadata - at least the 'instrument', 'band', and 'date_taken' fields. The allowed choices for the 'instrument' and 'band' fields are pre-defined - additional choices are possible by contacting the admins. Public data will need to be visually inspected first through an Image Inspection task.

Spectrum

Similarly to imaging data, we only keep metadata (at least the 'instrument' and 'date_taken' fields) and a plot of the spectrum. A script to help make the flux-wavelength plot can be found here. The allowed choices for the 'instrument' field are pre-defined - additional choices are possible by contacting the admins. Public spectra will need to be visually inspected first through an Image Inspection task.

Catalogue

Catalogue data are managed by the database administrators and cannot be currently added/edited by the users.

Redshift

We currently do not associate the redshift to a spectrum where it might have been calculated from. The required fields are: 'value', 'tag', and 'method'.

Generic Image

This can be in fact any image related to a lens that doesn't fit in the categories above. For example, it can be an image showing the environment of the lens, or even a plot of some sort (a model, kinematics, etc). The required fields are 'name' and 'info'. Public images will need to be visually inspected first through an Image Inspection task.

Model

Fetching data

Coming soon

Pending tasks

Coming soon

Future data

Coming soon

Backups

Coming soon