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 38: Line 38:




How would this be implemented (exclusive)?
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 the two subcategories be at the top level (where Applications, Tools, Science gateways and where Workflow systems are now)?  

Revision as of 14:54, 7 December 2012


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)



Science sub-categories

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

Use cases:

a. 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 to the right set of gateways containg only a small number of gateways that all satisfies her requirements."

b. 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.



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.


Status

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