The attributes marked with a * are confidential and should not be disclosed outside the service provider.

Service overview
Service nameData / metadata generation from semantic annotations
Service areaA named group of services that offer access to the same type of resource (e.g. compute, storage, data, operations, training, coordination)
Service phase

Phase of the service design selected among: - discovery: researching users needs, exploring technological or policy constraints; - alpha: prototype available for closed set of users; - beta: service being developed while available for testing publicly; - production: service available in the live environment meeting security/performance requirements; - retired: the service is not anymore offered *Note: services in beta and production phase are live and can be part of the service catalogue (see the page Service Phases for more information)

Service descriptionHigh-level description of what the service does in terms of functionalities it provides and the resources it enables access to

Customer group

  • RI metadata and data managers and publishers
  • e-Infrastructure semantic operators
User groupType of Individuals that primarily benefits from and uses a service
ValueThe benefit to a customer and their users delivered by a service; benefits are usually related to alleviating pains (e.g., eliminate undesired outcomes, obstacles or risks) or producing gains (e.g. increased performance, social gains, positive emotions or cost saving).
Tagline1-line value proposition (max XX words to be derived from value) 
Features
  • A-Generation of ISO19139 metadata records from rdf triples. 
    • Step 1) convertion of OBOE-based triples to DCAT-AP
    • Step 2) from DCAT-AP to ISO. This second step can be re-used alone.
  • B- Generation/identification of datasets from raw data OBOE-based RDF triples.
    • Step 1) data perimeter delimitation (from metadata),
    • Step 2) identification of dataset dimensionalities
    • Step 3) Data file (NETCDF) generation and
    • Step 4) DOI generation
Service options
OptionNameDescriptionAttributes
1Add a name for this option Add a description for this option; this description is targeted to potential customers who need to understand what each option is about and being able to choose the best for their needs Add attributes as numbered bullet lists in the form of 1. attribute name: [possible values] 2. attribute name: [possible values]  ... 
2



3



Access policiesPolicies stating how the service can be accessed, examples are: Policy-based: users are granted access to the service based on policies defined by the EGI service provider(s) or by EGI.eu; Wide access: users can freely access the service provided; Market-driven: users can negotiate a fee to access the service either directly with the EGI service provider or indirectly with EGI.eu
Service management information
Service owner *Name of the service owner (see this page for the specific responsibilities Roles, Responsibilities, Communication)
Contact (internal) *Internal contact (e.g., e-mail, phone) to ask information about the service
Contact (public)External contact (e.g., e-mail, phone) to ask information about the service
Request workflow *

Service request list
  • Development stage
  • Open Source
Terms of useURL to a document containing the rules which one must agree to abide by in order to use the service
SLA(s)Link to URL to a document containing information about the levels of performance that a service provider is expected to achieve (service level agreement)
Other agreementsList of agreement documents that are associated to this services (e.g. OLA, UA)
Support unitName of the support unit in the EGI Helpdesk
User manualURL to the user manual for this service
Service architecture
Service components

List of service components that are the minimum required to make the service available and their TRL

#TypeNameDescriptionTRL [1]
1

Choose: Enabling or Enhancing

Definitions:

- Enabling service components are the minimum set of service components that make the service available

- Enhancing service components are any additional service components that improves the service, however, the service would still run without them, even if at lesser quality.  

 Name of the component

2



Finances & resources
Payment model(s)Supported payment models and restrictions that apply to each of them; example of types of payment models are: free, pay-as-you-go, subscription, membership to corporate customers , higher education, etc.
PricingDescribe the price scheme for this service in case the customer is charged for access/usage
Cost *The costs required to develop (CAPEX) and maintain/operate (OPEX) the service in the best case, e.g. human effort; financial investment
Revenue stream(s) *e.g. public funding, membership fees, in-kind, paid (specify price)
Action requiredList the actions that are required to complete the service portfolio entry according to the specific service phase; if no actions are required, write 'no'


[1] Technology Readiness Levels (TRL) are a method of estimating technology maturity of components during the acquisition process. For non-technical components, you can specify “n/a”. For technical components, you can select them based on the following definition from the EC:

  • TRL 1 – basic principles observed
  • TRL 2 – technology concept formulated
  • TRL 3 – experimental proof of concept
  • TRL 4 – technology validated in lab
  • TRL 5 – technology validated in relevant environment (industrially relevant environment in the case of key enabling technologies)
  • TRL 6 – technology demonstrated in relevant environment (industrially relevant environment in the case of key enabling technologies)
  • TRL 7 – system prototype demonstration in operational environment
  • TRL 8 – system complete and qualified
  • TRL 9 – actual system proven in operational environment (competitive manufacturing in the case of key enabling technologies)