Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "VT Science Gateway Primer/appdb"

From EGIWiki
Jump to navigation Jump to search
Line 129: Line 129:
The above recommendations were discussed on the 14th Jan. 2013 in a meeting between EGI.eu UCST and AppDB developement team. This section provides the final status for each of the SGP-VT recommendations towards AppDB and timeframe to implement accepted feautures into AppDB production instance.
The above recommendations were discussed on the 14th Jan. 2013 in a meeting between EGI.eu UCST and AppDB developement team. This section provides the final status for each of the SGP-VT recommendations towards AppDB and timeframe to implement accepted feautures into AppDB production instance.


{| cellspacing="0" cellpadding="10" border="1" class="wikitable sortable"  
{| cellspacing="0" cellpadding="10" border="1" class="wikitable sortable" width="85%"
|-
|-
! style="width: 50%; class="unsortable" | Topic  
! style="width: 20% class="unsortable" | Topic  
! Status  
! Status  
! class="unsortable" | Comment  
! class="unsortable" | Comment  

Revision as of 00:09, 16 January 2013

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:

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 discussed on the 14th Jan. 2013 in a meeting between EGI.eu UCST and AppDB developement team. This section provides the final status for each of the SGP-VT recommendations towards AppDB and timeframe to implement accepted feautures into AppDB production instance.

Topic Status Comment
1. Science Gateway sub-categories Accepted Preliminary feedback regarding this topic was provided by UCST. The sub-categorization of Science Gateways proposed is good. To support this request, a second level of categorization on AppDB software entries is needed, to reflect software capabilities. The feature will be developed during the first quarter of 2013.
2. Status of the gateway Rejected Preliminary feedback regarding this topic was provided by UCST. The status feature for each AppDB software entry is already implemented. Regarding specifically this recommendation from SGP-VT, there is no need to create an extra layer of complexity (sub-categorization) to show the science gateway status. We recognize though that current available status field options should be revised. A query refinement feature based on the status field, similar to what sourceforge project uses in their advanced search mode, is a feature that can be considered to be implemented in future AppDB releases. More complex ways to assess availability of science gateways in real time can also be considered in future releases.
3. Science sub-categories Rejected Preliminary feedback regarding this topic was provided by UCST. There is no need to create an extra layer of complexity (sub-categorization) to show the scientific field(s) of a science gateway. The categorization feature of all AppDB software entries by science field is already implemented: discipline field is mandatory; sub-discipline is optional. Furthermore, a VT on Scientific Discipline Classification is underway to revise this concept. It will impact all EGI.eu services that make use of a scientific classification from the second quarter of 2013, namely AppDB.
4. Free tags Rejected This feature is already implemented in AppDB.
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' through the EGI.eu AppDB. Because many of the software solutions that 'EGI Technology Providers' provide build on top of each other, similar to gateway instance being developed on top of a framework, their support in AppDB will also require the linkage of software related items. For completeness, there's an AppDB feature named 'Related software' already implemented. This feature has a built-in set of rules to make an initial match between a certain AppDB software entry and remaining registered AppDB entries.
6. Mandatory hyperlinks Accepted We accept this recommendation has important, nevertheless the definition of what is considered to be a production system is lacking from the SGP-VT work, namely the Primer.
  1. Usage policy is needed for open systems (software entries registered in AppDB with the goal of attracting users and also made available for use through AppDB), not (just) for production systems.
  2. A definition of 'open systems' should be given in the SG primer for science gateways (to be done by EGI.eu in the 1st quarter of 2013).
  3. Usage policy meta-data can be introduced and checked for open systems in AppDB.
  4. Each software registered in AppDB has a profile. The information requested to the software owner is currently the same, no matter what category of software is being registered. In the mid term we plan to refine the information available per software category, and the associated attributes, like if a field is mandatory or not.