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.

Coming soon: option to download the query result directly 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.

API queries

Coming soon.

Adding lenses

There is an automatic check for duplicate lenses in the database based on the RA, DEC: if the given coordinates are within 10 arcsec of an existing lens then the new lens is flagged as potential duplicate. This check includes all the lenses accessible to the user at the time, both private and public (see Access Level). If a submitted lens is a duplicate then there are the following options in order to proceed:

1. Do nothing: The lens is ignored and not injected in the database.
2. Distinct lens: The lens is treated as a distinct entry in the database, despite its proximity to an existing one, and injected.
3. Merge: All the information of the new lens will be suggested to be merged into the existing one. A 'Merge' task will be created for the owner of the existing lens to resolve.

The mugshot of every public lens needs to be visually confirmed by an Inspector before the lens is actually made public. Such lenses are termorarily injected in the database as private and automatically changed to public if approved by the Inspector.

Adding papers

Coming soon

Adding data

Data that are associated with a lens, Redshifts, Imaging Data, Spectra, Generic Images, and Models, can be added directly in the detail page of each lens. Catalogue data are managed by the database administrators and cannot be added/edited by the users. Mass injection of data is allowed only via the API. Public data that include an image, i.e. Imaging Data, Spectra, Generic Images, etc, need to be visually confirmed by an Inspector and are termorarily injected in the database as private.

Using the API interface

Coming soon: if duplicates are detected during injection via the API then a Resolve Duplicates task is created in the same way as adding lenses via the web interface described above.