VT Science Gateway Primer/appdb

AppDB recommendations

Recommendations on how to improve the data structure of the EGI Application Database, to better support science gateway developers, are recorded in this wiki page. Preliminary UCST feedback on these topics are also provided.

Science Gateway sub-categories

1. Within the Science Gateways category we need two subcategories concerning the type of the gateway:

a. SG framework (Generic DCI gateway framework)

b. SG instance (Application-specific science gateway)

UCST comment

Science gateways (SG) and Workflow systems have been added as separate new categories on the AppDB portal interface. The science gateways listed in AppDB SG category are not sub-categorized as mentioned in the above recommendation. However, there are two subcategories already 'conceptually' available within the database through the usage of tags. These two subcategories are shown on the EGI SG dedicated website:

• Science gateways
• Science gateway enabling technology

The terminology should match between the Primer and the EGI SG dedicated webpages.

Given this background, the requirement can be translated as:

1. Within the Science Gateways category we need two subcategories concerning the type of the gateway:

a. Science gateway

b. Science gateway enabling technology

How would this recommendation be implemented?

• Should the two subcategories be at the top level (where Applications, Tools, Science gateways and where Workflow systems are now)?
• Should these two subcategories be presented under the main Science gateway category? In this case should we use a different name for the main category to avoid name duplication between the top level category and a subcategory under this?

Status of the gateway

2. In both subcategories we need two subcategories concerning the status of the gateway:

a. Production level (available for external users)

b. Prototype level (tested by a selected set of users)

UCST comment

Every software that is registered in AppDB have a 'Status' field in their profile. This Status field can have one of the following values:

• In production
• Ready for deployment
• Ready for validation
• Ready for portal interface
• Ready for middleware
• Ready for standalone use / running on a local cluster

These values are legacy values that have not changed for ~4 years. They are very much tuned for the workflow of porting a scientific application to a cluster, then to a grid, then integrate it with a portal interface to end up in a production system at the end. This workflow is not valid for many of the software that we have now in AppDB, so the statuses should be changed. Just some of the scenarios that the current values cannot cover:

• What if somebody targets a prototype system, not a production system? (the b scenario from your suggestion)
• What it somebody ports an application to infrastructure with a graphical environment and not scripts?
• What if somebody targets a cloud system, not a grid middleware?

We welcome suggestions from the VT on how to revise these values. Particularly, we expect the VT to define:

• what statuses are realistic for a science gateway
• what statuses are realistic for a science gateway enabling technology

Science sub-categories

3. In both subcategories we need science subcategories like chemistry, biotechnology, earth, astrophysics, etc.

UCST comment

Scientific discipline (compulsory) and subdiscipline (optional) are defined for every software in AppDB. Filtering and searching AppDB entries using discipline or subdiscipline is a feature in production.

What the VT should provide feedback:

• the current values that one can select for discipline and subdiscipline
  • are these the right one?
  • are these complete?

(to register science gateways and science gateway enabling technologies!) (E.g. which discipline should a gateway technology belong to?)

• the way entries can be searched, filtered and presented by discipline and subdisciline
  • are the searches, gadgets provide enough flexibility?
  • can discipline and subdiscipline searches joined with searches for Status and for Type? (Peter's use case below)

Free tags

4. Free tags should be available. These could be used by the Science Gateways software for example to:

a. Define each application a specific SG is offering (Science Gateways can offer access to one or more software packs)

b. Provide a better categorization of a SG software register. For example, which enabling technology is the SG based on? Later on, this information will be valuable to assess how different technologies are being uptake by SG developers. We are aware of the AppDB gadget and that is easy to build customized AppDB queries.

Cross-references

5. An AppDB software (e.g. SG related entries) should be able to cross-reference with other software already in AppDB. For example, if a SG is based on the WS-PGRADE/gUSE enabling technology, then somewhere in the description of the SG this could be referenced.

a. We are aware that AppDB uses permalinks

b. Are there other ways this could be accomplished?

Mandatory hyperlinks

6. If a SG claims to be in production, an URL and usage policy should be available. A user expects to have at least this information available in order to assess if a certain SG is suitable for him or not.

Use cases

These use cases were provided to co-substantiate above recommendations.

1. A typical scientist would like to search the data base in the following way ...

I am interested in an application-specific science gateway that is in production in the area of astrophysics. Using the subcategories she can quickly get the right set of gateways containing only a small number of gateways that all satisfies her requirements.

2. A biotechnology gateway developer would like to see if there is any generic gateway framework that is in production and from which she can build a SG instance.

Status

The above recommendations were recorded as requirements in the EGI RT system (#4520). UCST and AppDB developers are discussing these topics. This page will be update accordingly.

Topic	Status	Comment
1 - Science Gateway sub-categories	Accepted	The categorization is good, but requires support for second level categories of software in AppDB based on software capabilities. This support will be developed during the first quarter of 2013, and then it can be applied for science gateways in the database.
2 - Status of the gateway	Rejected
3 - Science sub-categories	Accepted	There is a VT XXX that will decide about the scientific categorisation of items in EGI services and tools. The output of this VT will be fed into AppDB in the second half of 2013.
4 - Free tags	Rejected	Already implemented.
5 - Cross-references	Accepted	Support for linking software profiles will be considered for implementation during 2013, as part of the development phase that aims to support 'EGI Technology Providers' to provide software for EGI through the EGI AppDB. Because many of the software solutions that EGI Technology Providers provide build on each other, as well as on other software in the EGI community, their support in AppDB will also require the linkage of software items.
6 - Mandatory hyperlinks	Accepted	1. Usage policy is needed for open systems, not (just) for production systems (I call a system open here if it is registered in AppDB to attract users and it is available for use through AppDB); 2. A definition of 'open systems' should be given in the SG primer for science gateways (to be done by EGI.eu); 3. Usage policy meta-data can be introduced and checked for open systems in AppDB.