https://wiki.gcube-system.org/api.php?action=feedcontributions&user=Rena.tsantouli&feedformat=atomGcube Wiki - User contributions [en]2024-03-29T09:37:46ZUser contributionsMediaWiki 1.25.1https://wiki.gcube-system.org/index.php?title=Integration_and_Interoperability_Facilities_Framework:_HTTP_API_Framework_Specification&diff=16656Integration and Interoperability Facilities Framework: HTTP API Framework Specification2012-11-21T13:29:51Z<p>Rena.tsantouli: /* Authentication Modes */</p>
<hr />
<div>=Objective=<br />
The Application Services Layer offers HTTP APIs to expose a subset of its JAVA API facilities for supporting high level standards. It consists of a set of servlets that support HTTP methods and operates on top of the JAVA libraries. The retrospection of the current architecture and principles of those interfaces will guide the steps towards a formalization into a framework for this layer of the system. <br />
<br />
==HTTP Front End==<br />
Work within HTTP Front End framework focuses on system software that handles HTTP requests and replies with HTTP responses. The objective of this task involves access points that cover series of services, can pass through ASL for session handling and/or expose HTTP standards compliant interfaces.<br />
<br />
==Clients==<br />
The framework targets clients submitting HTTP requests and handling HTTP responses. Such clients will be components external or internal to the system that have come in an agreement with the HTTP services implementers about the data/format they are expecting and the response they will be giving out, or will be implementing standard HTTP specifications offered by the HTTP front end of the system. <br />
<br />
==Goals==<br />
The task aims at reviewing the existing architecture and extending the principles of the HTTP Front End to promote consistency across its implementing components and extensibility of the framework. At a later stage it focuses on monitoring its adoption across HTTP Front End components.<br />
<br />
==Roadmap==<br />
The roadmap defines the steps through which the review of the existing implementation will lead to the definition of the options and needs for extensions and formalization of the procedures. The final objective is the aggregation of the findings into a framework that will guide the evolution, usage, deployment and evaluation of the components that underlie this layer of the infrastructure. The methodology includes the following steps:<br />
<br />
* Architecture review<br />
** Clean the current architecture into more distinct components that will promote framework extensibility <br />
** Identify common functionalities and needs for development of common utility libraries<br />
* Principles extension<br />
** Extend principles with rules clarifying areas with needs for functionalities compliant with standards<br />
** Usage of standard data interchange formats <br />
* Definition of rules defining scope of application<br />
* Definition of management rules covering topics for changes, deployment, distribution, etc.<br />
* Definition of rules for controlling use and development<br />
* Definition of methods for checking compliance with fundamental rules <br />
<br />
==Models==<br />
The framework distinguishes concerns that relate to the HTTP applications fromt hose that relate to their management and evolves two separate models for their structuring: the Design Model and the Management Model.<br />
* Design Model: The Design Model for CL defines the architecture, the framework principles and the common functionality needs. It addresses cross-cutting design concerns within the HTTP components that include at least the following issues: authenticated calls, error handling, data interchange formats, Web Standards and their interplay with Infrastructure requirements, configurations. Consistency is more readily and conveniently achieved through shared implementations of common solutions. In this sense, the work within the framework evolution will also be concerned with the delivery of new system components that support the development of HTTP components. <br />
* Management Model: The model for HTTP Front End components will address at least the following (inter-related) issues:<br />
** Build outputs: what secondary artifacts are associated with HTTP Front End modules<br />
** Release cycle: how are HTTP components released with respect to target services<br />
** Change management: how changes in ASL or other target service API should be handled<br />
** Profiling and deployment: how should HTTP artifacts be profiled for dynamic deployment<br />
** Distribution: how should HTTP artifacts be packaged for distribution<br />
<br />
=Design Model HTTP Front End=<br />
==Architecture==<br />
The architecture of this layer is driven by the needs for provision of access to resources that fall under specific functional categories. More specifically, it consists of a set of servlets for which each access point covers a series of services. In the existing implementation, those components cover mostly the fundamental functionality needed by the end-users. Extensions in the existing framework can either provide access to resources of other functional categories or offer a standard HTTP based API adhering to a widely used specification, to support interoperability needs. All the components within the existing framework use common functionalities implemented for caller authentication.<br />
<br />
===External Architecture===<br />
HTTP Front End aims at providing access to higher level functionality, frequently compliant to web standards. Most probably each access point covers a series of services and requires interaction with lower level components in the system architecture to achieve resources aggregation. The system layer that offers this kind of access to multiple services as well as a session mechanism that can be exploited within different applications’ interactions is the ASL (Application Services Layer). Therefore, the HTTP layer is logically placed above it and offers a subset of its functionality. In the image below, the framework of ‘layers’ of gCube system is depicted, clarifying the place of this set of interfaces in the system architecture. <br />
<br />
[[File:WP11_FrameworkLayers.jpg]]<br />
<br />
===Internal Architecture===<br />
HTTP Front End is composed by web applications based on Java Servlet technology. By revisiting the architecture of the existing implementation of ASL HTTP Front End, the need for extensibility drives the decision for division of the only application into a set of smaller applications that can proliferate within the framework. An HTTP application in the new version of this layer can logically group related functionalities. The grouped functionalities address demanding tasks that need access to multiple services and a sequence of logical steps to complete. In the context of this decision, the architecture of the existing implementation consists of the following new system components:<br />
* [[ASL_HTTP_InformationRetrieval]]: Aggregates mandated functionality to perform a gCube search <br />
** listing of searchable collections<br />
** retrieval of information about searchable collections<br />
** listing of search types<br />
** listing of languages <br />
** listing of searchable fields<br />
** submission of search query<br />
** support for OpenSearch Specification<br />
** retrieval of search results<br />
* [[ASL_HTTP_ContentAccess]]: Aggregates functionality for accessing gCube content<br />
** retrieval of information about content<br />
** retrieval of content<br />
** retrieval of metadata<br />
** retrieval of thumbnails<br />
* [[ASL_HTTP_InfrastructureLogin]]: Aggregates functionality for logging in an infrastructure scope by using the ASL interna session mechanism<br />
** user authentication – logging in Infrastructure<br />
** listing of infrastructure scopes <br />
** logging in an Infrastructure scope<br />
* Specifications Implementations: Implementations of HTTP Standards placed in separate application components<br />
** [[ASL:_OAI-PMH_Implementation | ASL_HTTP_OAIPMH]]<br />
** [[HTTP_Front_End:_OAI-ORE_Implementation | ASL_HTTP_OAIORE]]<br />
* Implementations offering common functionality to all HTTP applications<br />
Based on the functionality, each servlet overrides the doGet and doPost methods of HttpServlet<br />
<br />
==Principles==<br />
The general principles conducting the implementation within the framework are listed as follows:<br />
* Session management with the use of the built in session tracking mechanisms of the servlets and the internal ASL Session for intercommunication within applications deployed in the same container.<br />
* Use of higher level functionalities hosted in ASL.<br />
* Provision of sufficient error handling based on appropriate error codes and prescriptive fault messages<br />
* Ability to run in any servlet container (not binding to portal installation) and with minor container configurations<br />
* Authentication application for all invocations<br />
** Provision of support for anonymous access also for every invocation<br />
<br />
More specifically, within the HTTP layer, servlets are implemented as Java programming language classes that extend HttpServlet. Depending on the functionality offered, a servlet overrides the doHead, doGet and doPost methods and handles the requests based on the following guidelines:<br />
===API===<br />
====Data Interchange Formats====<br />
For the benefits of interoperability and openness, HTTP responses must be in an interchangeable data serialization format. Extensible Markup Language (XML) or JavaScript Object Notation (JSON), which is a text notation that is better suited for data-interchange are recommended to be used in the applications HTTP responses. Therefore, the content type in the doHead method of every servlet should be either “application/json” or “text/xml”. If both mime types are supported, then the servlet will require the parameter “type” and render the results based on the user selection.<br />
====Error Handling====<br />
HTTP Front End components must return status codes compliant with Hypertext Transfer Protocol and appropriate HTTP error codes, with prescriptive messages of what went wrong in the system, or in the user input.<br />
====Coding Guidelines==== <br />
- Naming Conventions<br />
<br />
===Context Management===<br />
As stated above, HTTP Front End uses ASL constructs to access lower level functionality. The remote operations are called by ASL in a context which encompasses more information than the target service endpoint and the input parameters of the calls. In particular, calls occur always in a given scope and to the provision of credentials about the caller. An attempt to call an operation in no particular scope or an operation called anonymously within a scope for which anonymous access is not configured, will be rejected.<br />
Below, we describe how this contextual information is made available within the calls to an application:<br />
====Authenticated Calls====<br />
All calls to HTTP Front End components must be authenticated, in terms of being performed within a context that contains information about the caller identity and the infrastructure scope. In the case of [http://wiki.i-marine.eu/index.php/Integration_and_Interoperability_Facilities_Framework_:_HTTP_API_Framework_Specification#Authentication_Modes anonymous access], the caller does not need to identify herself but has to provide information about the scope within which the anonymous call will be performed (see authentication modes). Therefore, the first step for an interaction with any HTTP application is logging in to the system, through Login servlet by providing the right credentials. <br />
The Login servlet makes use of status codes and HTTP headers to manage the security policy. It implements both BASIC and Form – based authentication methods, receiving the user’s credential (username-password) and then communicating with ASLCore component to perform authentication. ASLCore provides a user authentication mechanism independent from specific applications and authentication providers. Using a pluggable mechanism to specify authentication modules it restricts users’ access to applications interacting with it. In case of denied credentials, the servlet returns an SC_UNAUTHORIZED status code to the client. Once the user is logged in to the system, an internal session within ASL is created for him and can be accessed with the use of the http session id and the username of the caller. This means that in subsequent calls the user will have to add a “username” parameter and keep the same jsessionid. <br />
In the cases of ‘anonymous access’, the user does not need to identify herself by visiting the Login portlet.<br />
<br />
====Scope Management====<br />
All calls to the underlying infrastructure are scoped. Consequently, a user interacting with HTTP Front End has to login to a scope before trying to access resources. This is done by visiting the LoginInfrastructureScope servlet and passing as parameter the scope to enter. LoginInfrastructureScope servlet interacts with ASLCore to log the user and keep this information in the internal ASLSession to prevent the need for passing this information in all subsequent calls of the application.<br />
When anonymous access is used, there is no need for logging in to an infrastructure scope, but all the requests need to be scoped by adding one more ‘scope’ parameter to the request.<br />
====Session Management====<br />
HTTP Front End makes use of the built in session tracking mechanisms of the servlets in combination with the internal ASLSession, to allow intercommunication between different applications living in the same container. Consequently, the user’s http session can be tracked either with the use of persistent cookies, where the session ID is saved on the client in a cookie called JSESSIONID, or with URL rewriting. URL rewriting can be used by clients that don’t support cookies by sending the sessionID as part of a rewritten URL, encoded using a jsessionid parameter. The http session is returned once the user logs in the system, inside an XML response, and all following URL – encoded requests within one application must contain it. The http session ID, along with the ‘username’ parameter are being used to track the internal ASL session that allows intercommunication between different ASL HTTP applications living in the same container. <br />
By offering a session tracking mechanism, the framework allows the user to make subsequent requests without having to log in every time she asks for a resource. <br />
In cases of HTTP standards implementations, where the requests can be strictly defined and the parameters non negotiable, the contextual information required from the underlying infrastructure is provided within application specific configurations, which are described [http://wiki.i-marine.eu/index.php/Integration_and_Interoperability_Facilities_Framework_:_HTTP_API_Framework_Specification#Configurations here].<br />
<br />
==Authentication Modes==<br />
Since many Web Standards require open access, HTTP Front End supports two modes for accessing the system resources: Authenticated and Open Access<br />
* Authenticated<br />
In authenticated mode, the user needs to login to the system and to an Infrastructure scope and continue interacting with the application over HTTP without having to pass the contextual information in every request submitted. Moreover, she can use personalized benefits in the cases of functionalities interacting with gCube personalization services. <br />
* Open Access<br />
A servlet can also support Open Access to the underlying resources . For the user interacting with the application, this means that she has to pass the ‘scope’ parameter in every call it submits to the application. <br />
<br />
The servlets implementers do not have to write code for any of the user authentication mode. This common functionality can be directly accessed through the aslHttpAccessManagement component, on which all servlets of the HTTP Front End should depend. Before processing the user’s call, the servlet implementer needs to authenticate the user by passing the HTTPServletRequest to the asl authentication component for HTTP and the identifier of the operation the user asked to perform, i.e:<br />
<code><br />
<br />
HttpSession session = request.getSession();<br />
<br />
//-- Check if the user is authenticated<br />
<br />
AuthenticationResponse authenticationResp = CallAuthenticationManager.authenticateCall(request, operationID);<br />
<br />
</code><br />
<br />
The operationID is a string that identifies the operation and is used in a generic configuration for the management of Open Access. This configuration controls the open access permission per scope and per operation through HTTP. Therefore, if the user has not previously logged in the System, the Open Access configuration for the requested scope and for the particular operation is checked. The operationId should be a static final variable declared for every operation (or group of operations) in every servlet. <br />
As a response, the servlet implementer gets back an AuthenticationResponse object, from which he can retrieve whether the user was authenticated. If the user was authenticated, the userId can be retrieved from the returned object and if not, one can retrieve the message indicating what went wrong. For example:<br />
<code><br />
<br />
HttpSession session = request.getSession();<br />
<br />
//-- Check if the user is authenticated<br />
<br />
AuthenticationResponse authenticationResp = CallAuthenticationManager.authenticateCall(request, operationID);<br />
<br />
if (!authenticationResp.isAuthenticated()) {<br />
<br />
response.sendError(401, authenticationResp.getUnauthorizedErrorMessage());<br />
<br />
return;<br />
<br />
}<br />
<br />
String username = authenticationResp.getUserId();<br />
<br />
…<br />
</code><br />
<br />
=== Node configured with Scope ===<br />
There is an option to configure the node hosting the web applications with a specific scope. In that case, all the web applications deployed in that node are running in the configured scope and there is no need for clients to select a running scope. This means that for anonymous access, the request can be performed using the fundamental parameters for making the calls, without having to deal with the scope parameter. This is mainly used for web applications with interfaces that adhere to specifications and that have strictly defined APIs, not allowing for extensions with supplementary ones.<br />
<br />
==Web Standards and Infrastructure Requirements==<br />
Many HTTP standards strictly define the request types and their parameters that can’t be extended and are non-negotiable. In the cases of implementation of such standards for providing interoperable HTTP interfaces, the client cannot specify the details of the environment within which her actions will take place (for instance information about the gCube scope). Moreover there are other cases where an administrator of an application could wish to expose part of the infrastructure resources through an Open Access protocol or cases where a protocol requires the exposal of resources in a particular form (not directly matching to the system’s resources structure). <br />
===Configurations=== <br />
In all cases, where there is a gap between the requirements of the protocol and those of the infrastructure, the servlets offering the rendering functionality should base on bridging configurations. Those configurations can bind requests to scopes and virtually organize the infrastructure resources, based on the protocol’s requirements. The configurations of the servlets must be stored as generic resources in the system, in order for the Administrators to be able to easily configure them. If smaller configurations are needed, (represented by name – value pairs) that are rarely changed, those can be placed in the ‘init’ params of the web.xml of the servlet. <br />
<br />
<!-- * High level standards<br />
* REST / SOAP over HTTP : shall we employ SOAP apis ? --></div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=Integration_and_Interoperability_Facilities_Framework:_HTTP_API_Framework_Specification&diff=16655Integration and Interoperability Facilities Framework: HTTP API Framework Specification2012-11-21T13:29:17Z<p>Rena.tsantouli: /* Authentication Modes */</p>
<hr />
<div>=Objective=<br />
The Application Services Layer offers HTTP APIs to expose a subset of its JAVA API facilities for supporting high level standards. It consists of a set of servlets that support HTTP methods and operates on top of the JAVA libraries. The retrospection of the current architecture and principles of those interfaces will guide the steps towards a formalization into a framework for this layer of the system. <br />
<br />
==HTTP Front End==<br />
Work within HTTP Front End framework focuses on system software that handles HTTP requests and replies with HTTP responses. The objective of this task involves access points that cover series of services, can pass through ASL for session handling and/or expose HTTP standards compliant interfaces.<br />
<br />
==Clients==<br />
The framework targets clients submitting HTTP requests and handling HTTP responses. Such clients will be components external or internal to the system that have come in an agreement with the HTTP services implementers about the data/format they are expecting and the response they will be giving out, or will be implementing standard HTTP specifications offered by the HTTP front end of the system. <br />
<br />
==Goals==<br />
The task aims at reviewing the existing architecture and extending the principles of the HTTP Front End to promote consistency across its implementing components and extensibility of the framework. At a later stage it focuses on monitoring its adoption across HTTP Front End components.<br />
<br />
==Roadmap==<br />
The roadmap defines the steps through which the review of the existing implementation will lead to the definition of the options and needs for extensions and formalization of the procedures. The final objective is the aggregation of the findings into a framework that will guide the evolution, usage, deployment and evaluation of the components that underlie this layer of the infrastructure. The methodology includes the following steps:<br />
<br />
* Architecture review<br />
** Clean the current architecture into more distinct components that will promote framework extensibility <br />
** Identify common functionalities and needs for development of common utility libraries<br />
* Principles extension<br />
** Extend principles with rules clarifying areas with needs for functionalities compliant with standards<br />
** Usage of standard data interchange formats <br />
* Definition of rules defining scope of application<br />
* Definition of management rules covering topics for changes, deployment, distribution, etc.<br />
* Definition of rules for controlling use and development<br />
* Definition of methods for checking compliance with fundamental rules <br />
<br />
==Models==<br />
The framework distinguishes concerns that relate to the HTTP applications fromt hose that relate to their management and evolves two separate models for their structuring: the Design Model and the Management Model.<br />
* Design Model: The Design Model for CL defines the architecture, the framework principles and the common functionality needs. It addresses cross-cutting design concerns within the HTTP components that include at least the following issues: authenticated calls, error handling, data interchange formats, Web Standards and their interplay with Infrastructure requirements, configurations. Consistency is more readily and conveniently achieved through shared implementations of common solutions. In this sense, the work within the framework evolution will also be concerned with the delivery of new system components that support the development of HTTP components. <br />
* Management Model: The model for HTTP Front End components will address at least the following (inter-related) issues:<br />
** Build outputs: what secondary artifacts are associated with HTTP Front End modules<br />
** Release cycle: how are HTTP components released with respect to target services<br />
** Change management: how changes in ASL or other target service API should be handled<br />
** Profiling and deployment: how should HTTP artifacts be profiled for dynamic deployment<br />
** Distribution: how should HTTP artifacts be packaged for distribution<br />
<br />
=Design Model HTTP Front End=<br />
==Architecture==<br />
The architecture of this layer is driven by the needs for provision of access to resources that fall under specific functional categories. More specifically, it consists of a set of servlets for which each access point covers a series of services. In the existing implementation, those components cover mostly the fundamental functionality needed by the end-users. Extensions in the existing framework can either provide access to resources of other functional categories or offer a standard HTTP based API adhering to a widely used specification, to support interoperability needs. All the components within the existing framework use common functionalities implemented for caller authentication.<br />
<br />
===External Architecture===<br />
HTTP Front End aims at providing access to higher level functionality, frequently compliant to web standards. Most probably each access point covers a series of services and requires interaction with lower level components in the system architecture to achieve resources aggregation. The system layer that offers this kind of access to multiple services as well as a session mechanism that can be exploited within different applications’ interactions is the ASL (Application Services Layer). Therefore, the HTTP layer is logically placed above it and offers a subset of its functionality. In the image below, the framework of ‘layers’ of gCube system is depicted, clarifying the place of this set of interfaces in the system architecture. <br />
<br />
[[File:WP11_FrameworkLayers.jpg]]<br />
<br />
===Internal Architecture===<br />
HTTP Front End is composed by web applications based on Java Servlet technology. By revisiting the architecture of the existing implementation of ASL HTTP Front End, the need for extensibility drives the decision for division of the only application into a set of smaller applications that can proliferate within the framework. An HTTP application in the new version of this layer can logically group related functionalities. The grouped functionalities address demanding tasks that need access to multiple services and a sequence of logical steps to complete. In the context of this decision, the architecture of the existing implementation consists of the following new system components:<br />
* [[ASL_HTTP_InformationRetrieval]]: Aggregates mandated functionality to perform a gCube search <br />
** listing of searchable collections<br />
** retrieval of information about searchable collections<br />
** listing of search types<br />
** listing of languages <br />
** listing of searchable fields<br />
** submission of search query<br />
** support for OpenSearch Specification<br />
** retrieval of search results<br />
* [[ASL_HTTP_ContentAccess]]: Aggregates functionality for accessing gCube content<br />
** retrieval of information about content<br />
** retrieval of content<br />
** retrieval of metadata<br />
** retrieval of thumbnails<br />
* [[ASL_HTTP_InfrastructureLogin]]: Aggregates functionality for logging in an infrastructure scope by using the ASL interna session mechanism<br />
** user authentication – logging in Infrastructure<br />
** listing of infrastructure scopes <br />
** logging in an Infrastructure scope<br />
* Specifications Implementations: Implementations of HTTP Standards placed in separate application components<br />
** [[ASL:_OAI-PMH_Implementation | ASL_HTTP_OAIPMH]]<br />
** [[HTTP_Front_End:_OAI-ORE_Implementation | ASL_HTTP_OAIORE]]<br />
* Implementations offering common functionality to all HTTP applications<br />
Based on the functionality, each servlet overrides the doGet and doPost methods of HttpServlet<br />
<br />
==Principles==<br />
The general principles conducting the implementation within the framework are listed as follows:<br />
* Session management with the use of the built in session tracking mechanisms of the servlets and the internal ASL Session for intercommunication within applications deployed in the same container.<br />
* Use of higher level functionalities hosted in ASL.<br />
* Provision of sufficient error handling based on appropriate error codes and prescriptive fault messages<br />
* Ability to run in any servlet container (not binding to portal installation) and with minor container configurations<br />
* Authentication application for all invocations<br />
** Provision of support for anonymous access also for every invocation<br />
<br />
More specifically, within the HTTP layer, servlets are implemented as Java programming language classes that extend HttpServlet. Depending on the functionality offered, a servlet overrides the doHead, doGet and doPost methods and handles the requests based on the following guidelines:<br />
===API===<br />
====Data Interchange Formats====<br />
For the benefits of interoperability and openness, HTTP responses must be in an interchangeable data serialization format. Extensible Markup Language (XML) or JavaScript Object Notation (JSON), which is a text notation that is better suited for data-interchange are recommended to be used in the applications HTTP responses. Therefore, the content type in the doHead method of every servlet should be either “application/json” or “text/xml”. If both mime types are supported, then the servlet will require the parameter “type” and render the results based on the user selection.<br />
====Error Handling====<br />
HTTP Front End components must return status codes compliant with Hypertext Transfer Protocol and appropriate HTTP error codes, with prescriptive messages of what went wrong in the system, or in the user input.<br />
====Coding Guidelines==== <br />
- Naming Conventions<br />
<br />
===Context Management===<br />
As stated above, HTTP Front End uses ASL constructs to access lower level functionality. The remote operations are called by ASL in a context which encompasses more information than the target service endpoint and the input parameters of the calls. In particular, calls occur always in a given scope and to the provision of credentials about the caller. An attempt to call an operation in no particular scope or an operation called anonymously within a scope for which anonymous access is not configured, will be rejected.<br />
Below, we describe how this contextual information is made available within the calls to an application:<br />
====Authenticated Calls====<br />
All calls to HTTP Front End components must be authenticated, in terms of being performed within a context that contains information about the caller identity and the infrastructure scope. In the case of [http://wiki.i-marine.eu/index.php/Integration_and_Interoperability_Facilities_Framework_:_HTTP_API_Framework_Specification#Authentication_Modes anonymous access], the caller does not need to identify herself but has to provide information about the scope within which the anonymous call will be performed (see authentication modes). Therefore, the first step for an interaction with any HTTP application is logging in to the system, through Login servlet by providing the right credentials. <br />
The Login servlet makes use of status codes and HTTP headers to manage the security policy. It implements both BASIC and Form – based authentication methods, receiving the user’s credential (username-password) and then communicating with ASLCore component to perform authentication. ASLCore provides a user authentication mechanism independent from specific applications and authentication providers. Using a pluggable mechanism to specify authentication modules it restricts users’ access to applications interacting with it. In case of denied credentials, the servlet returns an SC_UNAUTHORIZED status code to the client. Once the user is logged in to the system, an internal session within ASL is created for him and can be accessed with the use of the http session id and the username of the caller. This means that in subsequent calls the user will have to add a “username” parameter and keep the same jsessionid. <br />
In the cases of ‘anonymous access’, the user does not need to identify herself by visiting the Login portlet.<br />
<br />
====Scope Management====<br />
All calls to the underlying infrastructure are scoped. Consequently, a user interacting with HTTP Front End has to login to a scope before trying to access resources. This is done by visiting the LoginInfrastructureScope servlet and passing as parameter the scope to enter. LoginInfrastructureScope servlet interacts with ASLCore to log the user and keep this information in the internal ASLSession to prevent the need for passing this information in all subsequent calls of the application.<br />
When anonymous access is used, there is no need for logging in to an infrastructure scope, but all the requests need to be scoped by adding one more ‘scope’ parameter to the request.<br />
====Session Management====<br />
HTTP Front End makes use of the built in session tracking mechanisms of the servlets in combination with the internal ASLSession, to allow intercommunication between different applications living in the same container. Consequently, the user’s http session can be tracked either with the use of persistent cookies, where the session ID is saved on the client in a cookie called JSESSIONID, or with URL rewriting. URL rewriting can be used by clients that don’t support cookies by sending the sessionID as part of a rewritten URL, encoded using a jsessionid parameter. The http session is returned once the user logs in the system, inside an XML response, and all following URL – encoded requests within one application must contain it. The http session ID, along with the ‘username’ parameter are being used to track the internal ASL session that allows intercommunication between different ASL HTTP applications living in the same container. <br />
By offering a session tracking mechanism, the framework allows the user to make subsequent requests without having to log in every time she asks for a resource. <br />
In cases of HTTP standards implementations, where the requests can be strictly defined and the parameters non negotiable, the contextual information required from the underlying infrastructure is provided within application specific configurations, which are described [http://wiki.i-marine.eu/index.php/Integration_and_Interoperability_Facilities_Framework_:_HTTP_API_Framework_Specification#Configurations here].<br />
<br />
==Authentication Modes==<br />
Since many Web Standards require open access, HTTP Front End supports two modes for accessing the system resources: Authenticated and Open Access<br />
* Authenticated<br />
In authenticated mode, the user needs to login to the system and to an Infrastructure scope and continue interacting with the application over HTTP without having to pass the contextual information in every request submitted. Moreover, she can use personalized benefits in the cases of functionalities interacting with gCube personalization services. <br />
* Open Access<br />
A servlet can also support Open Access to the underlying resources . For the user interacting with the application, this means that she has to pass the ‘scope’ parameter in every call it submits to the application. <br />
<br />
The servlets implementers do not have to write code for any of the user authentication mode. This common functionality can be directly accessed through the aslHttpAccessManagement component, on which all servlets of the HTTP Front End should depend. Before processing the user’s call, the servlet implementer needs to authenticate the user by passing the HTTPServletRequest to the asl authentication component for HTTP and the identifier of the operation the user asked to perform, i.e:<br />
<code><br />
<br />
HttpSession session = request.getSession();<br />
<br />
//-- Check if the user is authenticated<br />
AuthenticationResponse authenticationResp = CallAuthenticationManager.authenticateCall(request, operationID);<br />
<br />
</code><br />
<br />
The operationID is a string that identifies the operation and is used in a generic configuration for the management of Open Access. This configuration controls the open access permission per scope and per operation through HTTP. Therefore, if the user has not previously logged in the System, the Open Access configuration for the requested scope and for the particular operation is checked. The operationId should be a static final variable declared for every operation (or group of operations) in every servlet. <br />
As a response, the servlet implementer gets back an AuthenticationResponse object, from which he can retrieve whether the user was authenticated. If the user was authenticated, the userId can be retrieved from the returned object and if not, one can retrieve the message indicating what went wrong. For example:<br />
<code><br />
<br />
HttpSession session = request.getSession();<br />
//-- Check if the user is authenticated<br />
AuthenticationResponse authenticationResp = CallAuthenticationManager.authenticateCall(request, operationID);<br />
if (!authenticationResp.isAuthenticated()) {<br />
response.sendError(401, authenticationResp.getUnauthorizedErrorMessage());<br />
return;<br />
}<br />
<br />
String username = authenticationResp.getUserId();<br />
…<br />
</code><br />
<br />
=== Node configured with Scope ===<br />
There is an option to configure the node hosting the web applications with a specific scope. In that case, all the web applications deployed in that node are running in the configured scope and there is no need for clients to select a running scope. This means that for anonymous access, the request can be performed using the fundamental parameters for making the calls, without having to deal with the scope parameter. This is mainly used for web applications with interfaces that adhere to specifications and that have strictly defined APIs, not allowing for extensions with supplementary ones.<br />
<br />
==Web Standards and Infrastructure Requirements==<br />
Many HTTP standards strictly define the request types and their parameters that can’t be extended and are non-negotiable. In the cases of implementation of such standards for providing interoperable HTTP interfaces, the client cannot specify the details of the environment within which her actions will take place (for instance information about the gCube scope). Moreover there are other cases where an administrator of an application could wish to expose part of the infrastructure resources through an Open Access protocol or cases where a protocol requires the exposal of resources in a particular form (not directly matching to the system’s resources structure). <br />
===Configurations=== <br />
In all cases, where there is a gap between the requirements of the protocol and those of the infrastructure, the servlets offering the rendering functionality should base on bridging configurations. Those configurations can bind requests to scopes and virtually organize the infrastructure resources, based on the protocol’s requirements. The configurations of the servlets must be stored as generic resources in the system, in order for the Administrators to be able to easily configure them. If smaller configurations are needed, (represented by name – value pairs) that are rarely changed, those can be placed in the ‘init’ params of the web.xml of the servlet. <br />
<br />
<!-- * High level standards<br />
* REST / SOAP over HTTP : shall we employ SOAP apis ? --></div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16370GCube Web Specifications and Standards Compliance2012-09-27T15:23:20Z<p>Rena.tsantouli: </p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols, data transfer protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management / Data Transfer<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
==OpenSearch==<br />
<br />
===Specification Description===<br />
OpenSearch is a collection of technologies that allow publishing of search results in a format suitable for syndication and aggregation. It is a way for websites and search engines to publish search results in a standard and accessible format. OpenSearch helps search engines and search clients communicate by introducing a common set of formats to perform search requests and syndicate search results. The five basic pieces of information that a search client needs in order to communicate effectively with a search engine supporting the protocol are:<br />
* local search engine location<br />
* the query-grammar expected<br />
* the request encoding<br />
* the response encoding<br />
* the record encoding <br />
The OpenSearch protocols define what a description document looks like, but not how it is retrieved. The location of the description document is discovered by some means outside the protocol (a priori knowledge). The description document specifies the location of the local search engine, how to formulate the search URL, and the local search engine's language to which the queries submitted must comply. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
As a producer, gCube can publish search results in a standard and accessible format, thus allowing metasesarch engines to know how to send a search to the gCube search engine and how to interpret the results.<br />
As a consumer, gCube can access external providers which publish their results through search engines conforming to the OpenSearch Specification. Therefore, it can act as a metasearch engine that combines results coming from a gCube search with the results from searching many other sites simultaneously, providing a high level of integration.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - OpenSearch: the http front end for the protocol that allows the gCube search engine to act as an OpenSearch Provider<br />
* OpenSearch Library: framework that includes a core library providing general-purpose OpenSearch functionality, and the OpenSearch Operator which utilizes functionality provided by the former<br />
* OpenSearch Service: the web service responsible for the invocation of the OpenSearch Operator in the context of the provider to be queried<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==SRU==<br />
<br />
===Specification Description===<br />
SRU is a standard XML-focused search protocol for Internet search queries, utilizing CQL (Contextual Query Language), a standard syntax for representing queries. As in OpenSearch, the five basic pieces of information provided by the mechanisms of the protocol to a client trying to communicate with the search engine, are: (1) local search engine location, (2) the query grammar expected, (3) the request encoding, (4) the response encoding, and (5) the record endoding. SRU expects that the content provider will have a description record that describes the search service. The protocols define what a description record looks like and specifies that it can be obtaines from the local search engine. The location of the local search engine is provided by means outside the protocol (a priori knowledge). SRU defines also how to formulate the search URL by defining it, and specifies a standard query grammarL CQ: (Common Query Language). This means that clients of the engine only have to write one translator for all the SRU local search engines but also that all SRU local search engines have to support the CQL query grammar. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
The gCube Search engine supports CQL as its native query grammar, thus complying fully to the SRU requirements for query formulation. Providing and interface and the description mechanisms defined by the protocol would allow all SRU metasearch engines to access gCube results in a standard way and with a high integration level. <br />
<br />
In the consuming side of the protocol, gCube would act as a metasearch engine for external search engines. An SRU provider integrated in the gCube system , would allow the dissemination of its results coming along with gCube results, within a single search in gCube system. The mechanism for the registration of the information that describes the SRU search engines in the gCube system, can be integrated with the one already implemented for OpenSearch providers, since the requirements for effective communication with external search engines are common in both protocols.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol is planned to be integrated within the system, covering both consumer and producer sides and exploiting the already implemented mechanisms for OpenSearch providers subscription to the system.<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - SRU: the http front end for the protocol that allows the gCube search engine to act as an SRU provider<br />
* SRU - OpenSearch Convertor: the mechanism that will be converting the response of an 'explain' request in SRU protocol to the equivalent OpenSearch Description document, to register the provider information within the gCube System<br />
* To be defined.<br />
<br />
===References===<br />
* [http://www.loc.gov/standards/sru/index.html| Search Retrieval via URL]<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16363GCube Web Specifications and Standards Compliance2012-09-27T10:43:30Z<p>Rena.tsantouli: /* gCube Adoption Status */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
==OpenSearch==<br />
<br />
===Specification Description===<br />
OpenSearch is a collection of technologies that allow publishing of search results in a format suitable for syndication and aggregation. It is a way for websites and search engines to publish search results in a standard and accessible format. OpenSearch helps search engines and search clients communicate by introducing a common set of formats to perform search requests and syndicate search results. The five basic pieces of information that a search client needs in order to communicate effectively with a search engine supporting the protocol are:<br />
* local search engine location<br />
* the query-grammar expected<br />
* the request encoding<br />
* the response encoding<br />
* the record encoding <br />
The OpenSearch protocols define what a description document looks like, but not how it is retrieved. The location of the description document is discovered by some means outside the protocol (a priori knowledge). The description document specifies the location of the local search engine, how to formulate the search URL, and the local search engine's language to which the queries submitted must comply. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
As a producer, gCube can publish search results in a standard and accessible format, thus allowing metasesarch engines to know how to send a search to the gCube search engine and how to interpret the results.<br />
As a consumer, gCube can access external providers which publish their results through search engines conforming to the OpenSearch Specification. Therefore, it can act as a metasearch engine that combines results coming from a gCube search with the results from searching many other sites simultaneously, providing a high level of integration.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - OpenSearch: the http front end for the protocol that allows the gCube search engine to act as an OpenSearch Provider<br />
* OpenSearch Library: framework that includes a core library providing general-purpose OpenSearch functionality, and the OpenSearch Operator which utilizes functionality provided by the former<br />
* OpenSearch Service: the web service responsible for the invocation of the OpenSearch Operator in the context of the provider to be queried<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==SRU==<br />
<br />
===Specification Description===<br />
SRU is a standard XML-focused search protocol for Internet search queries, utilizing CQL (Contextual Query Language), a standard syntax for representing queries. As in OpenSearch, the five basic pieces of information provided by the mechanisms of the protocol to a client trying to communicate with the search engine, are: (1) local search engine location, (2) the query grammar expected, (3) the request encoding, (4) the response encoding, and (5) the record endoding. SRU expects that the content provider will have a description record that describes the search service. The protocols define what a description record looks like and specifies that it can be obtaines from the local search engine. The location of the local search engine is provided by means outside the protocol (a priori knowledge). SRU defines also how to formulate the search URL by defining it, and specifies a standard query grammarL CQ: (Common Query Language). This means that clients of the engine only have to write one translator for all the SRU local search engines but also that all SRU local search engines have to support the CQL query grammar. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
The gCube Search engine supports CQL as its native query grammar, thus complying fully to the SRU requirements for query formulation. Providing and interface and the description mechanisms defined by the protocol would allow all SRU metasearch engines to access gCube results in a standard way and with a high integration level. <br />
<br />
In the consuming side of the protocol, gCube would act as a metasearch engine for external search engines. An SRU provider integrated in the gCube system , would allow the dissemination of its results coming along with gCube results, within a single search in gCube system. The mechanism for the registration of the information that describes the SRU search engines in the gCube system, can be integrated with the one already implemented for OpenSearch providers, since the requirements for effective communication with external search engines are common in both protocols.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol is planned to be integrated within the system, covering both consumer and producer sides and exploiting the already implemented mechanisms for OpenSearch providers subscription to the system.<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - SRU: the http front end for the protocol that allows the gCube search engine to act as an SRU provider<br />
* SRU - OpenSearch Convertor: the mechanism that will be converting the response of an 'explain' request in SRU protocol to the equivalent OpenSearch Description document, to register the provider information within the gCube System<br />
* To be defined.<br />
<br />
===References===<br />
* [http://www.loc.gov/standards/sru/index.html| Search Retrieval via URL]<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16362GCube Web Specifications and Standards Compliance2012-09-27T10:39:07Z<p>Rena.tsantouli: /* References */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
==OpenSearch==<br />
<br />
===Specification Description===<br />
OpenSearch is a collection of technologies that allow publishing of search results in a format suitable for syndication and aggregation. It is a way for websites and search engines to publish search results in a standard and accessible format. OpenSearch helps search engines and search clients communicate by introducing a common set of formats to perform search requests and syndicate search results. The five basic pieces of information that a search client needs in order to communicate effectively with a search engine supporting the protocol are:<br />
* local search engine location<br />
* the query-grammar expected<br />
* the request encoding<br />
* the response encoding<br />
* the record encoding <br />
The OpenSearch protocols define what a description document looks like, but not how it is retrieved. The location of the description document is discovered by some means outside the protocol (a priori knowledge). The description document specifies the location of the local search engine, how to formulate the search URL, and the local search engine's language to which the queries submitted must comply. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
As a producer, gCube can publish search results in a standard and accessible format, thus allowing metasesarch engines to know how to send a search to the gCube search engine and how to interpret the results.<br />
As a consumer, gCube can access external providers which publish their results through search engines conforming to the OpenSearch Specification. Therefore, it can act as a metasearch engine that combines results coming from a gCube search with the results from searching many other sites simultaneously, providing a high level of integration.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - OpenSearch: the http front end for the protocol that allows the gCube search engine to act as an OpenSearch Provider<br />
* OpenSearch Library: framework that includes a core library providing general-purpose OpenSearch functionality, and the OpenSearch Operator which utilizes functionality provided by the former<br />
* OpenSearch Service: the web service responsible for the invocation of the OpenSearch Operator in the context of the provider to be queried<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==SRU==<br />
<br />
===Specification Description===<br />
SRU is a standard XML-focused search protocol for Internet search queries, utilizing CQL (Contextual Query Language), a standard syntax for representing queries. As in OpenSearch, the five basic pieces of information provided by the mechanisms of the protocol to a client trying to communicate with the search engine, are: (1) local search engine location, (2) the query grammar expected, (3) the request encoding, (4) the response encoding, and (5) the record endoding. SRU expects that the content provider will have a description record that describes the search service. The protocols define what a description record looks like and specifies that it can be obtaines from the local search engine. The location of the local search engine is provided by means outside the protocol (a priori knowledge). SRU defines also how to formulate the search URL by defining it, and specifies a standard query grammarL CQ: (Common Query Language). This means that clients of the engine only have to write one translator for all the SRU local search engines but also that all SRU local search engines have to support the CQL query grammar. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
The gCube Search engine supports CQL as its native query grammar, thus complying fully to the SRU requirements for query formulation. Providing and interface and the description mechanisms defined by the protocol would allow all SRU metasearch engines to access gCube results in a standard way and with a high integration level. <br />
<br />
In the consuming side of the protocol, gCube would act as a metasearch engine for external search engines. An SRU provider integrated in the gCube system , would allow the dissemination of its results coming along with gCube results, within a single search in gCube system. The mechanism for the registration of the information that describes the SRU search engines in the gCube system, can be integrated with the one already implemented for OpenSearch providers, since the requirements for effective communication with external search engines are common in both protocols.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - SRU: the http front end for the protocol that allows the gCube search engine to act as an SRU provider<br />
* SRU - OpenSearch Convertor: the mechanism that will be converting the response of an 'explain' request in SRU protocol to the equivalent OpenSearch Description document, to register the provider information within the gCube System<br />
* To be defined.<br />
<br />
===References===<br />
* [http://www.loc.gov/standards/sru/index.html| Search Retrieval via URL]<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16361GCube Web Specifications and Standards Compliance2012-09-27T10:37:41Z<p>Rena.tsantouli: /* Components affected / relevant */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
==OpenSearch==<br />
<br />
===Specification Description===<br />
OpenSearch is a collection of technologies that allow publishing of search results in a format suitable for syndication and aggregation. It is a way for websites and search engines to publish search results in a standard and accessible format. OpenSearch helps search engines and search clients communicate by introducing a common set of formats to perform search requests and syndicate search results. The five basic pieces of information that a search client needs in order to communicate effectively with a search engine supporting the protocol are:<br />
* local search engine location<br />
* the query-grammar expected<br />
* the request encoding<br />
* the response encoding<br />
* the record encoding <br />
The OpenSearch protocols define what a description document looks like, but not how it is retrieved. The location of the description document is discovered by some means outside the protocol (a priori knowledge). The description document specifies the location of the local search engine, how to formulate the search URL, and the local search engine's language to which the queries submitted must comply. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
As a producer, gCube can publish search results in a standard and accessible format, thus allowing metasesarch engines to know how to send a search to the gCube search engine and how to interpret the results.<br />
As a consumer, gCube can access external providers which publish their results through search engines conforming to the OpenSearch Specification. Therefore, it can act as a metasearch engine that combines results coming from a gCube search with the results from searching many other sites simultaneously, providing a high level of integration.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - OpenSearch: the http front end for the protocol that allows the gCube search engine to act as an OpenSearch Provider<br />
* OpenSearch Library: framework that includes a core library providing general-purpose OpenSearch functionality, and the OpenSearch Operator which utilizes functionality provided by the former<br />
* OpenSearch Service: the web service responsible for the invocation of the OpenSearch Operator in the context of the provider to be queried<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==SRU==<br />
<br />
===Specification Description===<br />
SRU is a standard XML-focused search protocol for Internet search queries, utilizing CQL (Contextual Query Language), a standard syntax for representing queries. As in OpenSearch, the five basic pieces of information provided by the mechanisms of the protocol to a client trying to communicate with the search engine, are: (1) local search engine location, (2) the query grammar expected, (3) the request encoding, (4) the response encoding, and (5) the record endoding. SRU expects that the content provider will have a description record that describes the search service. The protocols define what a description record looks like and specifies that it can be obtaines from the local search engine. The location of the local search engine is provided by means outside the protocol (a priori knowledge). SRU defines also how to formulate the search URL by defining it, and specifies a standard query grammarL CQ: (Common Query Language). This means that clients of the engine only have to write one translator for all the SRU local search engines but also that all SRU local search engines have to support the CQL query grammar. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
The gCube Search engine supports CQL as its native query grammar, thus complying fully to the SRU requirements for query formulation. Providing and interface and the description mechanisms defined by the protocol would allow all SRU metasearch engines to access gCube results in a standard way and with a high integration level. <br />
<br />
In the consuming side of the protocol, gCube would act as a metasearch engine for external search engines. An SRU provider integrated in the gCube system , would allow the dissemination of its results coming along with gCube results, within a single search in gCube system. The mechanism for the registration of the information that describes the SRU search engines in the gCube system, can be integrated with the one already implemented for OpenSearch providers, since the requirements for effective communication with external search engines are common in both protocols.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - SRU: the http front end for the protocol that allows the gCube search engine to act as an SRU provider<br />
* SRU - OpenSearch Convertor: the mechanism that will be converting the response of an 'explain' request in SRU protocol to the equivalent OpenSearch Description document, to register the provider information within the gCube System<br />
* To be defined.<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16360GCube Web Specifications and Standards Compliance2012-09-27T10:34:17Z<p>Rena.tsantouli: /* gCube Use/Need/Relevance */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
==OpenSearch==<br />
<br />
===Specification Description===<br />
OpenSearch is a collection of technologies that allow publishing of search results in a format suitable for syndication and aggregation. It is a way for websites and search engines to publish search results in a standard and accessible format. OpenSearch helps search engines and search clients communicate by introducing a common set of formats to perform search requests and syndicate search results. The five basic pieces of information that a search client needs in order to communicate effectively with a search engine supporting the protocol are:<br />
* local search engine location<br />
* the query-grammar expected<br />
* the request encoding<br />
* the response encoding<br />
* the record encoding <br />
The OpenSearch protocols define what a description document looks like, but not how it is retrieved. The location of the description document is discovered by some means outside the protocol (a priori knowledge). The description document specifies the location of the local search engine, how to formulate the search URL, and the local search engine's language to which the queries submitted must comply. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
As a producer, gCube can publish search results in a standard and accessible format, thus allowing metasesarch engines to know how to send a search to the gCube search engine and how to interpret the results.<br />
As a consumer, gCube can access external providers which publish their results through search engines conforming to the OpenSearch Specification. Therefore, it can act as a metasearch engine that combines results coming from a gCube search with the results from searching many other sites simultaneously, providing a high level of integration.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - OpenSearch: the http front end for the protocol that allows the gCube search engine to act as an OpenSearch Provider<br />
* OpenSearch Library: framework that includes a core library providing general-purpose OpenSearch functionality, and the OpenSearch Operator which utilizes functionality provided by the former<br />
* OpenSearch Service: the web service responsible for the invocation of the OpenSearch Operator in the context of the provider to be queried<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==SRU==<br />
<br />
===Specification Description===<br />
SRU is a standard XML-focused search protocol for Internet search queries, utilizing CQL (Contextual Query Language), a standard syntax for representing queries. As in OpenSearch, the five basic pieces of information provided by the mechanisms of the protocol to a client trying to communicate with the search engine, are: (1) local search engine location, (2) the query grammar expected, (3) the request encoding, (4) the response encoding, and (5) the record endoding. SRU expects that the content provider will have a description record that describes the search service. The protocols define what a description record looks like and specifies that it can be obtaines from the local search engine. The location of the local search engine is provided by means outside the protocol (a priori knowledge). SRU defines also how to formulate the search URL by defining it, and specifies a standard query grammarL CQ: (Common Query Language). This means that clients of the engine only have to write one translator for all the SRU local search engines but also that all SRU local search engines have to support the CQL query grammar. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
The gCube Search engine supports CQL as its native query grammar, thus complying fully to the SRU requirements for query formulation. Providing and interface and the description mechanisms defined by the protocol would allow all SRU metasearch engines to access gCube results in a standard way and with a high integration level. <br />
<br />
In the consuming side of the protocol, gCube would act as a metasearch engine for external search engines. An SRU provider integrated in the gCube system , would allow the dissemination of its results coming along with gCube results, within a single search in gCube system. The mechanism for the registration of the information that describes the SRU search engines in the gCube system, can be integrated with the one already implemented for OpenSearch providers, since the requirements for effective communication with external search engines are common in both protocols.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - OpenSearch: the http front end for the protocol that allows the gCube search engine to act as an OpenSearch Provider<br />
* OpenSearch Library: framework that includes a core library providing general-purpose OpenSearch functionality, and the OpenSearch Operator which utilizes functionality provided by the former<br />
* OpenSearch Service: the web service responsible for the invocation of the OpenSearch Operator in the context of the provider to be queried<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16359GCube Web Specifications and Standards Compliance2012-09-27T10:27:37Z<p>Rena.tsantouli: /* gCube Use/Need/Relevance */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
==OpenSearch==<br />
<br />
===Specification Description===<br />
OpenSearch is a collection of technologies that allow publishing of search results in a format suitable for syndication and aggregation. It is a way for websites and search engines to publish search results in a standard and accessible format. OpenSearch helps search engines and search clients communicate by introducing a common set of formats to perform search requests and syndicate search results. The five basic pieces of information that a search client needs in order to communicate effectively with a search engine supporting the protocol are:<br />
* local search engine location<br />
* the query-grammar expected<br />
* the request encoding<br />
* the response encoding<br />
* the record encoding <br />
The OpenSearch protocols define what a description document looks like, but not how it is retrieved. The location of the description document is discovered by some means outside the protocol (a priori knowledge). The description document specifies the location of the local search engine, how to formulate the search URL, and the local search engine's language to which the queries submitted must comply. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
As a producer, gCube can publish search results in a standard and accessible format, thus allowing metasesarch engines to know how to send a search to the gCube search engine and how to interpret the results.<br />
As a consumer, gCube can access external providers which publish their results through search engines conforming to the OpenSearch Specification. Therefore, it can act as a metasearch engine that combines results coming from a gCube search with the results from searching many other sites simultaneously, providing a high level of integration.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - OpenSearch: the http front end for the protocol that allows the gCube search engine to act as an OpenSearch Provider<br />
* OpenSearch Library: framework that includes a core library providing general-purpose OpenSearch functionality, and the OpenSearch Operator which utilizes functionality provided by the former<br />
* OpenSearch Service: the web service responsible for the invocation of the OpenSearch Operator in the context of the provider to be queried<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==SRU==<br />
<br />
===Specification Description===<br />
SRU is a standard XML-focused search protocol for Internet search queries, utilizing CQL (Contextual Query Language), a standard syntax for representing queries. As in OpenSearch, the five basic pieces of information provided by the mechanisms of the protocol to a client trying to communicate with the search engine, are: (1) local search engine location, (2) the query grammar expected, (3) the request encoding, (4) the response encoding, and (5) the record endoding. SRU expects that the content provider will have a description record that describes the search service. The protocols define what a description record looks like and specifies that it can be obtaines from the local search engine. The location of the local search engine is provided by means outside the protocol (a priori knowledge). SRU defines also how to formulate the search URL by defining it, and specifies a standard query grammarL CQ: (Common Query Language). This means that clients of the engine only have to write one translator for all the SRU local search engines but also that all SRU local search engines have to support the CQL query grammar. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
The gCube Search engine supports CQL as its native query grammar, thus complying fully to the SRU requirements for query formulation. Providing and interface and the description mechanisms defined by the protocol would allow all SRU metasearch engines to access gCube results in a standard way and with a high integration level. <br />
<br />
As a consumer, an SRU provider integrated in the gCube system , could serve as a standard mechanism for integrating external SRU providers for the simultaneous dissemination of results. The registration of the information that describes the SRU search engines in the gCube system, can be integrated with the one already implemented for OpenSearch providers, to cover the common requirements for effective communication with external search engines.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - OpenSearch: the http front end for the protocol that allows the gCube search engine to act as an OpenSearch Provider<br />
* OpenSearch Library: framework that includes a core library providing general-purpose OpenSearch functionality, and the OpenSearch Operator which utilizes functionality provided by the former<br />
* OpenSearch Service: the web service responsible for the invocation of the OpenSearch Operator in the context of the provider to be queried<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16358GCube Web Specifications and Standards Compliance2012-09-27T10:26:27Z<p>Rena.tsantouli: /* gCube Use/Need/Relevance */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
==OpenSearch==<br />
<br />
===Specification Description===<br />
OpenSearch is a collection of technologies that allow publishing of search results in a format suitable for syndication and aggregation. It is a way for websites and search engines to publish search results in a standard and accessible format. OpenSearch helps search engines and search clients communicate by introducing a common set of formats to perform search requests and syndicate search results. The five basic pieces of information that a search client needs in order to communicate effectively with a search engine supporting the protocol are:<br />
* local search engine location<br />
* the query-grammar expected<br />
* the request encoding<br />
* the response encoding<br />
* the record encoding <br />
The OpenSearch protocols define what a description document looks like, but not how it is retrieved. The location of the description document is discovered by some means outside the protocol (a priori knowledge). The description document specifies the location of the local search engine, how to formulate the search URL, and the local search engine's language to which the queries submitted must comply. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
As a producer, gCube can publish search results in a standard and accessible format, thus allowing metasesarch engines to know how to send a search to the gCube search engine and how to interpret the results.<br />
As a consumer, gCube can access external providers which publish their results through search engines conforming to the OpenSearch Specification. Therefore, it can act as a metasearch engine that combines results coming from a gCube search with the results from searching many other sites simultaneously, providing a high level of integration.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - OpenSearch: the http front end for the protocol that allows the gCube search engine to act as an OpenSearch Provider<br />
* OpenSearch Library: framework that includes a core library providing general-purpose OpenSearch functionality, and the OpenSearch Operator which utilizes functionality provided by the former<br />
* OpenSearch Service: the web service responsible for the invocation of the OpenSearch Operator in the context of the provider to be queried<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==SRU==<br />
<br />
===Specification Description===<br />
SRU is a standard XML-focused search protocol for Internet search queries, utilizing CQL (Contextual Query Language), a standard syntax for representing queries. As in OpenSearch, the five basic pieces of information provided by the mechanisms of the protocol to a client trying to communicate with the search engine, are: (1) local search engine location, (2) the query grammar expected, (3) the request encoding, (4) the response encoding, and (5) the record endoding. SRU expects that the content provider will have a description record that describes the search service. The protocols define what a description record looks like and specifies that it can be obtaines from the local search engine. The location of the local search engine is provided by means outside the protocol (a priori knowledge). SRU defines also how to formulate the search URL by defining it, and specifies a standard query grammarL CQ: (Common Query Language). This means that clients of the engine only have to write one translator for all the SRU local search engines but also that all SRU local search engines have to support the CQL query grammar. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
The gCube Search engine supports CQL as its native query grammar, thus complying fully to the SRU requirements for query formulation. Providing and interface and the description mechanisms defined by the protocol would allow all SRU metasearch engines to access gCube results in a standard way and within a high integration level. <br />
As a consumer, an SRU provider integrated in the gCube system , could serve as a standard mechanism for integrating external SRU providers for the simultaneous dissemination of results. The registration of the information that describes the SRU search engines in the gCube system, can be integrated with the one already implemented for OpenSearch providers, to cover the common requirements for effective communication with external search engines.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - OpenSearch: the http front end for the protocol that allows the gCube search engine to act as an OpenSearch Provider<br />
* OpenSearch Library: framework that includes a core library providing general-purpose OpenSearch functionality, and the OpenSearch Operator which utilizes functionality provided by the former<br />
* OpenSearch Service: the web service responsible for the invocation of the OpenSearch Operator in the context of the provider to be queried<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16357GCube Web Specifications and Standards Compliance2012-09-27T10:07:18Z<p>Rena.tsantouli: </p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
==OpenSearch==<br />
<br />
===Specification Description===<br />
OpenSearch is a collection of technologies that allow publishing of search results in a format suitable for syndication and aggregation. It is a way for websites and search engines to publish search results in a standard and accessible format. OpenSearch helps search engines and search clients communicate by introducing a common set of formats to perform search requests and syndicate search results. The five basic pieces of information that a search client needs in order to communicate effectively with a search engine supporting the protocol are:<br />
* local search engine location<br />
* the query-grammar expected<br />
* the request encoding<br />
* the response encoding<br />
* the record encoding <br />
The OpenSearch protocols define what a description document looks like, but not how it is retrieved. The location of the description document is discovered by some means outside the protocol (a priori knowledge). The description document specifies the location of the local search engine, how to formulate the search URL, and the local search engine's language to which the queries submitted must comply. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
As a producer, gCube can publish search results in a standard and accessible format, thus allowing metasesarch engines to know how to send a search to the gCube search engine and how to interpret the results.<br />
As a consumer, gCube can access external providers which publish their results through search engines conforming to the OpenSearch Specification. Therefore, it can act as a metasearch engine that combines results coming from a gCube search with the results from searching many other sites simultaneously, providing a high level of integration.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - OpenSearch: the http front end for the protocol that allows the gCube search engine to act as an OpenSearch Provider<br />
* OpenSearch Library: framework that includes a core library providing general-purpose OpenSearch functionality, and the OpenSearch Operator which utilizes functionality provided by the former<br />
* OpenSearch Service: the web service responsible for the invocation of the OpenSearch Operator in the context of the provider to be queried<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==SRU==<br />
<br />
===Specification Description===<br />
SRU is a standard XML-focused search protocol for Internet search queries, utilizing CQL (Contextual Query Language), a standard syntax for representing queries. As in OpenSearch, the five basic pieces of information provided by the mechanisms of the protocol to a client trying to communicate with the search engine, are: (1) local search engine location, (2) the query grammar expected, (3) the request encoding, (4) the response encoding, and (5) the record endoding. SRU expects that the content provider will have a description record that describes the search service. The protocols define what a description record looks like and specifies that it can be obtaines from the local search engine. The location of the local search engine is provided by means outside the protocol (a priori knowledge). SRU defines also how to formulate the search URL by defining it, and specifies a standard query grammarL CQ: (Common Query Language). This means that clients of the engine only have to write one translator for all the SRU local search engines but also that all SRU local search engines have to support the CQL query grammar. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
As a producer, gCube can publish search results in a standard and accessible format, thus allowing metasesarch engines to know how to send a search to the gCube search engine and how to interpret the results.<br />
As a consumer, gCube can access external providers which publish their results through search engines conforming to the OpenSearch Specification. Therefore, it can act as a metasearch engine that combines results coming from a gCube search with the results from searching many other sites simultaneously, providing a high level of integration.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - OpenSearch: the http front end for the protocol that allows the gCube search engine to act as an OpenSearch Provider<br />
* OpenSearch Library: framework that includes a core library providing general-purpose OpenSearch functionality, and the OpenSearch Operator which utilizes functionality provided by the former<br />
* OpenSearch Service: the web service responsible for the invocation of the OpenSearch Operator in the context of the provider to be queried<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16356GCube Web Specifications and Standards Compliance2012-09-27T09:18:18Z<p>Rena.tsantouli: </p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
==OpenSearch==<br />
<br />
===Specification Description===<br />
OpenSearch is a collection of technologies that allow publishing of search results in a format suitable for syndication and aggregation. It is a way for websites and search engines to publish search results in a standard and accessible format. OpenSearch helps search engines and search clients communicate by introducing a common set of formats to perform search requests and syndicate search results. The five basic pieces of information that a search client needs in order to communicate effectively with a search engine supporting the protocol are:<br />
* local search engine location<br />
* the query-grammar expected<br />
* the request encoding<br />
* the response encoding<br />
* the record encoding <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
As a producer, gCube can publish search results in a standard and accessible format, thus allowing metasesarch engines to know how to send a search to the gCube search engine and how to interpret the results.<br />
As a consumer, gCube can access external providers which publish their results through search engines conforming to the OpenSearch Specification. Therefore, it can act as a metasearch engine that combines results coming from a gCube search with the results from searching many other sites simultaneously, providing a high level of integration.<br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer: OpenSearch interface over gCube search<br />
* Consumer: OpenSearch Framework accessing external OpenSearch providers<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, both from the producer and the consumer perspective. <br />
The description of the adopted methodology towards the adoption and implementation in the side of the producer, is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL#OpenSearch_Info here].<br />
The consumer side functionality of the gCube OpenSearch implementation is concentrated in the OpenSearch framework, whose description and features analysis can be found [https://gcube.wiki.gcube-system.org/gcube/index.php/OpenSearch_Framework here]<br />
<br />
===Components affected / relevant===<br />
* aslHttp Information Retrieval - OpenSearch: the http front end for the protocol that allows the gCube search engine to act as an OpenSearch Provider<br />
* OpenSearch Library: framework that includes a core library providing general-purpose OpenSearch functionality, and the OpenSearch Operator which utilizes functionality provided by the former<br />
* OpenSearch Service: the web service responsible for the invocation of the OpenSearch Operator in the context of the provider to be queried<br />
<br />
===References===<br />
* [http://www.opensearch.org/Home| OpenSearch]<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16355GCube Web Specifications and Standards Compliance2012-09-27T08:06:20Z<p>Rena.tsantouli: /* Direction */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16354GCube Web Specifications and Standards Compliance2012-09-27T08:05:17Z<p>Rena.tsantouli: </p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16353GCube Web Specifications and Standards Compliance2012-09-27T08:04:51Z<p>Rena.tsantouli: </p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE (Producer)==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16352GCube Web Specifications and Standards Compliance2012-09-27T08:02:06Z<p>Rena.tsantouli: /* Table of Protocols */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16351GCube Web Specifications and Standards Compliance2012-09-27T08:01:27Z<p>Rena.tsantouli: </p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
<br />
==OAI-ORE==<br />
<br />
===Specification Description===<br />
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide. <br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships.<br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system.<br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
Producer<br />
<br />
===gCube Adoption Status===<br />
The protocol has been recently integrated in the gCube System, from the producer perspective. The description of the adopted methodology towards the adoption and implementation is described [https://gcube.wiki.gcube-system.org/gcube/index.php/HTTP_Front_End:_OAI-ORE_Implementation here].<br />
<br />
===Components affected / relevant===<br />
* aslHttp ORE_Provider: the http front end for the protocol<br />
* applicationSupportLayer_OAI_ORE: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/ore/| Open Archives Initiative Object Reuse and Exchange]<br />
* [http://www.openarchives.org/ore/1.0/primer.html| OAI-ORE Primer]<br />
<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16350GCube Web Specifications and Standards Compliance2012-09-27T07:37:33Z<p>Rena.tsantouli: /* Table of Protocols */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OpenSearch | OpenSearch (Consumer)]] || Data Consumption || Consumer || Completed<br />
|-<br />
| [[#SRU | SRU (Consumer)]] || Data Consumption || Consumer || Planned<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16349GCube Web Specifications and Standards Compliance2012-09-27T07:35:52Z<p>Rena.tsantouli: /* Table of Protocols */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
| [[#OAI-ORE | OAI-ORE (Producer)]] || Data Consumption || Producer || Completed<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
===References===<br />
* [http://www.openarchives.org/pmh/| Open Archives Initiative Protocol for Metadata Harvesting Home Page]<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''<br />
<br />
===References===<br />
* [http://iso.org| Specification]<br />
* [https://gcube-system.org| gCube Wiki pointer]<br />
<br />
==Tentative Compliance==<br />
''Add here specifications that are not there, neither the project commits yet into supporting them, along with the need and relevance''.<br />
<br />
* LDAP: Support integration of infrastructure structure with other systems (e.g. harvesting external infrastructure resources, or publishing D4Science infrastructure resources ).<br />
* WSDM: Provide standard's compliant web API for infrastructure management.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=HTTP_Front_End:_OAI-ORE_Implementation&diff=16344HTTP Front End: OAI-ORE Implementation2012-09-25T10:45:33Z<p>Rena.tsantouli: /* ORE Solution */</p>
<hr />
<div>=OAI-ORE=<br />
==Introduction==<br />
[http://www.openarchives.org/ore/ Open Archives Initiative Object Reuse and Exchange (OAI-ORE)] defines standards for the description and exchange of aggregations of Web resources. These aggregations, sometimes called compound digital objects, may combine distributed resources with multiple media types including text, images, data, and video. The goal of these standards is to expose the rich content in these aggregations to applications that support authoring, deposit, exchange, visualization, reuse, and preservation. Although a motivating use case for the work is the changing nature of scholarship and scholarly communication, and the need for cyberinfrastructure to support that scholarship, the intent of the effort is to develop standards that generalize across all web-based information.<br />
<br />
In the physical world we create, use, and refer to aggregations of things all the time. We collect pictures in a photo album, read journals that are collections of articles, and burn CDs of our favorite songs. This practice of aggregating extends to the Web. We accumulate URL's in bookmarks or favorites lists in our browser, collect photos into sets in popular sites, browse over multiple page documents that are linked together through "prev" and "next" tags, and talk about Web sites as if they had some real existence beyond the set of pages of which they consist. Despite our frequent use of these aggregations, their existence on the Web is quite ephemeral. One reason for this is that there is no standard way to identify an aggregation. We often use the URI of one page of an aggregation to identify the whole aggregation. For example, we use the URI of the first page of a multi-page Web document to identify the whole document, or we use the URI of the HTML page that provides access to a collection of images to identify the entire set of images. But those URIs really just identify those specific pages, and not the union of pages that makes up the whole document, or the union of all images in a Flickr set, respectively. In essence, the problem is that there is no standard way to describe the constituents or boundary of an aggregation, and this is what OAI-ORE aims to provide.<br />
<br />
==Protocol Foundations==<br />
<br />
===World Wide Web Architecture===<br />
The foundations of the Web as we know it are detailed in the Architecture of the World Wide Web. This architecture defines the following core notions:<br />
* Resource, an item of interest.<br />
* URI, a global identifier for a Resource.<br />
* Representation, a datastream corresponding to the state of a Resource at the time its URI is dereferenced via some protocol (e.g. HTTP).<br />
* Link, a directed connection between two Resources.<br />
<br />
===Semantic Web===<br />
On the Web that we use on a daily basis, URIs are used primarily to identify Web documents. They are identifiers that, when dereferenced, return a human-readable Representation. However, on the Semantic Web, URIs are introduced to identify so-called real world entities, such as people or cars, or even abstract entities, such ideas or classes. Since these things are not documents, they have no Representation to indicate what these Resources mean. The Linked Data Effort [http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/20070727/ Linked Data Tutorial] describes an approach for obtaining information about those Resources despite the fact that they have no Representation. To summarize, the approach consists of:<br />
* Using HTTP URIs to identify those special Resources;<br />
* Publishing a document that provides information about the special Semantic Web Resource at a HTTP URI other than the HTTP URI of the Semantic Web Resource;<br />
* Using Cool URIs for the Semantic Web to allow discovering the HTTP URI of that document from the HTTP URI of the special Semantic Web Resource.<br />
<br />
===RDF (Resource Description Framework)===<br />
The documents that are proposed by the Linked Data effort to describe these abstract Resources are typically expressed in RDF/XML, which is an XML-based serialization for the Resource Description Framework (RDF) [http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ RDF Concepts] that forms the foundational data model of the Semantic Web. This model consists of subject-predicate-object statements called triples. Triples express relationships pertaining to a subject Resource denoted by a URI. The predicate Resource, also denoted by a URI, indicates the nature of the relationship . The object expresses the actual value for the relationship expressed by the predicate; the object can be denoted by a URI or can be a literal value, such as a string or a number. When multiple triples are expressed, or asserted, they may share subjects and objects and, as a result they conceptually join together in what is called a graph in mathematical terms. This graph consists of nodes that are the Resources denoted by the subject and object URIs, and edges that are the relationship predicates.<br />
<br />
==ORE Solution==<br />
ORE leverages the foundations described above to arrive at a solution to handle aggregations of Web resources. The essence of the ORE solution can be summarized as follows:<br />
* In order to be able to unambiguously refer to an aggregation of Web resources, a new Resource is introduced that stands for a set or collection of other Resources. This new Resource, named an Aggregation, has a URI just like any other Resource on the Web does. And, since an Aggregation is a conceptual construct, it qualifies as one of those Semantic Web Resources that does not have a Representation.<br />
* Following the Linked Data guidelines, another Resource is introduced to make information about the Aggregation available. This new Resource, named a Resource Map, has a URI and it has a machine-readable Representation that provides details about the Aggregation. In essence, a Resource Map expresses which Aggregation it describes, and it lists the resources that are part of the Aggregation. But, a Resource Map can also express relationships and properties pertaining to all these Resources, as well as metadata pertaining to the Resource Map itself, e.g. who published it and when it was most recently modified. Resource Maps can be expressed in different formats including Atom XML, RDF/XML, RDFa, n3, turtle, and other RDF serialization formats.<br />
* In order to make ORE work in the HTTP-based Web, both the Aggregation and the Resource Map are assigned HTTP URIs, and the Cool URI for the Semantic Web guidelines are adopted to support discovery of the HTTP URI of a Resource Map given the HTTP URI of an Aggregation.<br />
* ORE also introduces the notion of a Proxy resource, which stands for an Aggregated Resource in the context of a specific Aggregation. The URI of a Proxy resource provides a mechanism for denoting a resource in context.<br />
<br />
=Mapping to gCube Model=<br />
<br />
gCube Content Model aims to provide high-level functionality for manipualtion of content over the Grid-based environments. Content in gCube is stored and organized following a graph-based data model, the Information Object Model, that allows finer control of content, by incorporating the possibility to annotate content with arbitrary properties an to relate different content unities via arbitrary relationships. <br />
<br />
Starting from this model a document model has been built, in which complex documents, composed of various, eventually nested subparts, are represented as chains of Information Objects linked via appropriate relationships. For instance, an HTML document that includes a number of images may be modelled as a complex object that provides references to Information Objects (containing the images). In this respect, gCube documents are managed as compound objects comprising metadata, annotations, alternative representations and multiple parts. The notion of gCube documents is implemented and mangaged by the gCube Information Organisation Services family of subsystems that include storage services, access services, plugins and a number of distinguished clients that can be internal or external to the system. <br />
<br />
The aggregated information that constructs a gCube document can be transfered through the solution provided by OAI-ORE, without the need for clients to rely on the API's of the individual system architectures and their definition of document boundaries. The gCube ORE Provider allows the dissemination of the digital objects stored in gCube repository as OAI-ORE Resource Maps. <br />
<br />
==gCube ORE Resource Maps==<br />
The essence of a gCube document or a gCube collection is being introduced as an aggregation that denotes the entire document by publishing a machine-readable document that describes that aggregation. For example, the document describes which resources are part of the aggregation, and which are merely related to it. <br />
<br />
To this end, gCube documents and gCube collections are handled as OAI-ORE Aggregations and are being disseminated as OAI-ORE Resource Maps. Each ORE Resource Map for gCube documents and collections can be reached at<br />
<br />
http://<host>:<port>/aslHttpOREProvider/gOREProvider/rem?id=<gdocuri>&scope=<gCubescope><br />
<br />
where <host> is the address of the server where the gCube ORE-Provider application has been deployed. <br />
<br />
gOREProvider supports Resource Map serializations in Atom XML. The information registered in the Resource Map for each gCube complex object is expressed as an Atom entry and covers the ORE concepts for:<br />
* the ORE Aggregation described by the atom entry<br />
* the Resource Map that describes the Aggregation<br />
* the Aggregated Resources of the Aggregation<br />
* metadata about Aggregated Resources<br />
<br />
The Aggregated Resources registered in the Resource Map of a gCube document include the main data structures to describe the entity with broad and well-known semantics. Thus, an Aggregated Resource record is added for each one of the following: <br />
* document: the self-contained unit of content within the collection of related units;<br />
* metadata: a description of the document in a specific schema<br />
* annotations: subjective observations or records about a document<br />
* parts: components of a document<br />
* alternative represenations: secondary manifestations of a document<br />
<br />
An example of a Resource Map for a gCube document is presented bellow:<br />
<source lang="xml"><br />
<?xml version="1.0" encoding="utf-8"?><br />
<entry xmlns="http://www.w3.org/2005/Atom"<br />
xmlns:oreatom="http://www.openarchives.org/ore/atom/"<br />
xmlns:dcterms="http://purl.org/dc/terms/"<br />
xmlns:dc="http://purl.org/dc/elements/1.1/"<br />
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"<br />
xmlns:ore="http://www.openarchives.org/ore/terms/"<br />
xmlns:atom="http://www.w3.org/2005/Atom"><br />
<br />
<br />
<id>cms://7f78c200-f877-11dd-8103-acc6e633ea9e/cfefd160-f877-11dd-8103-acc6e633ea9e</id><br />
<br />
<br />
<link rel="self" type="application/atom+xml" href="cms://7f78c200-f877-11dd-8103-acc6e633ea9e/cfefd160-f877-11dd-8103-acc6e633ea9e"/><br />
<atom:link rel="describes" href="http://dl09.di.uoa.gr:8285/aslHttpOREProvider/gOREProvider/agg?id=cms://7f78c200-f877-11dd-8103-acc6e633ea9e/cfefd160-f877-11dd-8103-acc6e633ea9e"/><br />
<atom:author><br />
<atom:name>gCube ORE-Provider</atom:name><br />
</atom:author><br />
<atom:updated>2012/07/25 08:06:16</atom:updated><br />
<atom:category scheme="http://www.openarchives.org/ore/terms/" term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map"/><br />
<br />
<br />
<link rel="http://www.openarchives.org/ore/terms/aggregates" <br />
href="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpContentAccess%2FContentViewer%3FdocumentURI%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS" <br />
title="Programa de informacion de especies acuaticas - Anguilla anguilla -" <br />
type="text/uri-list" hreflang="en"/><br />
<br />
<link rel="http://www.openarchives.org/ore/terms/aggregates" <br />
href="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpContentAccess%2FMetadataViewer%3FdocumentURI%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%2F05e54b60-f878-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS" <br />
title="MetadataObject" <br />
type="text/xml"/><br />
<link rel="http://www.openarchives.org/ore/terms/aggregates" <br />
href="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpContentAccess%2FMetadataViewer%3FdocumentURI%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%2F0226e3d0-f878-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS" <br />
title="MetadataObject" <br />
type="text/xml"/><br />
<link rel="http://www.openarchives.org/ore/terms/aggregates" <br />
href="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpContentAccess%2FMetadataViewer%3FdocumentURI%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%2Ff8d18420-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS" <br />
title="MetadataObject" <br />
type="text/xml"/><br />
<br />
<br />
<link rel="http://www.openarchives.org/ore/terms/aggregates" <br />
href="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpContentAccess%2FContentViewer%3FdocumentURI%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%2Fd0eaac20-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS%26elementType%3Dalternative" <br />
title="Programa de informacion de especies acuaticas - Anguilla anguilla -" <br />
type="text/uri-list"/><br />
<link rel="http://www.openarchives.org/ore/terms/aggregates" <br />
href="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpContentAccess%2FContentViewer%3FdocumentURI%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%2Fd092ef30-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS%26elementType%3Dalternative" <br />
title="Programa de informacion de especies acuaticas - Anguilla anguilla -" <br />
type="text/uri-list"/><br />
<link rel="http://www.openarchives.org/ore/terms/aggregates" <br />
href="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpContentAccess%2FContentViewer%3FdocumentURI%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%2Fd03abd10-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS%26elementType%3Dalternative" <br />
title="Programa de informacion de especies acuaticas - Anguilla anguilla -" <br />
type="text/uri-list"/><br />
<br />
<br />
<oreatom:triples><br />
<rdf:Description<br />
rdf:about="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpContentAccess%2FMetadataViewer%3FdocumentURI%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%2F05e54b60-f878-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS"><br />
<dcterms:conformsTo rdf:resource="http://193.43.36.238:8282/fi/figis/devcon/schema/dc/qualifieddc.xsd"/><br />
<rdf:type rdf:resource="info:eu-repo/semantics/descriptiveMetadata"/><br />
</rdf:Description><br />
<rdf:Description<br />
rdf:about="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpContentAccess%2FMetadataViewer%3FdocumentURI%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%2F0226e3d0-f878-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS"><br />
<dcterms:conformsTo rdf:resource="http://193.43.36.238:8282/fi/figis/devcon/schema/dc/qualifieddc.xsd"/><br />
<rdf:type rdf:resource="info:eu-repo/semantics/descriptiveMetadata"/><br />
</rdf:Description><br />
<rdf:Description<br />
rdf:about="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpContentAccess%2FMetadataViewer%3FdocumentURI%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%2Ff8d18420-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS"><br />
<dcterms:conformsTo rdf:resource="http://193.43.36.238:8282/fi/figis/devcon/schema/dc/qualifieddc.xsd"/><br />
<rdf:type rdf:resource="info:eu-repo/semantics/descriptiveMetadata"/><br />
</rdf:Description><br />
<br />
<br />
<br />
</oreatom:triples><br />
</entry><br />
<br />
</source><br />
<br />
The links for the Aggregated Resources point to the corresponding data structures that can be reached through the HTTP Front End applications of the gCube system. The address of the nodes in which each application is deployed are configurable per gOREProvider installation. To this end, a set of initialization parameters must be configured in the web.xml file of the gOREProvider, once installed, for the definition of the following information:<br />
* metadataViewerURL: address of the MetadataViewer application used, for rendering of gCube Metadata<br />
* contentViewerURL: address of the ContentViewer application used, for rendering gCube Content, Annotations, Parts, Alternative Representations<br />
* collectionViewerURL: address of the CollectionViewer appliation used for rendering information about a gCube collection<br />
* author: the author of the disseminated Resource Documents<br />
<br />
For each aggregated resource, a triple indicating the notion (metadata, annotation, part) of the corresponding entity is added in the section of the metadata for the Aggregated Resources (inside the oreatom:triples element). <br />
<br />
The Aggregated Resources registered in the Resource Map of a gCube Collection consist of data structures for each gCube Document belonging to the collection, and are denoted as Aggregations too, using the nested Aggregations recommendation of the ORE protocol. An example of a Resource Map for a gCube collections is demonstrated bellow:<br />
<br />
<source lang="xml"><br />
<?xml version="1.0" encoding="utf-8"?><br />
<entry xmlns="http://www.w3.org/2005/Atom"<br />
xmlns:oreatom="http://www.openarchives.org/ore/atom/"<br />
xmlns:dcterms="http://purl.org/dc/terms/"<br />
xmlns:dc="http://purl.org/dc/elements/1.1/"<br />
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"<br />
xmlns:ore="http://www.openarchives.org/ore/terms/"<br />
xmlns:atom="http://www.w3.org/2005/Atom"><br />
<br />
<id>7f78c200-f877-11dd-8103-acc6e633ea9e</id><br />
<br />
<br />
<link rel="self" type="application/atom+xml" href="7f78c200-f877-11dd-8103-acc6e633ea9e"/><br />
<atom:link rel="describes" href="http://dl09.di.uoa.gr:8285/aslHttpOREProvider/gOREProvider/agg?id=7f78c200-f877-11dd-8103-acc6e633ea9e"/><br />
<atom:author><br />
<atom:name>gCube ORE-Provider</atom:name><br />
</atom:author><br />
<atom:updated>2012/07/25 08:05:48</atom:updated><br />
<atom:category scheme="http://www.openarchives.org/ore/terms/" term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map"/><br />
<br />
<br />
<link rel="http://www.openarchives.org/ore/terms/aggregates" <br />
href="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpInformationRetrieval%2FCollectionInfos%3FselectedCollections%3D7f78c200-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS" <br />
type="text/xml" hreflang="en"/><br />
<br />
<link rel="http://www.openarchives.org/ore/terms/aggregates" <br />
href="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpOREProvider%2FgOREProvider%2Fagg%3Fid%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS" <br />
title="$item.name" <br />
type="$item.mime"/><br />
<link rel="http://www.openarchives.org/ore/terms/aggregates" <br />
href="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpOREProvider%2FgOREProvider%2Fagg%3Fid%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS" <br />
title="$item.name" <br />
type="$item.mime"/><br />
<link rel="http://www.openarchives.org/ore/terms/aggregates" <br />
href="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpOREProvider%2FgOREProvider%2Fagg%3Fid%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS" <br />
title="$item.name" <br />
type="$item.mime"/><br />
<link rel="http://www.openarchives.org/ore/terms/aggregates" <br />
href="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpOREProvider%2FgOREProvider%2Fagg%3Fid%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS" <br />
title="$item.name" <br />
type="$item.mime"/><br />
<br />
<oreatom:triples><br />
<rdf:Description rdf:about="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpOREProvider%2FgOREProvider%2Fagg%3Fid%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS"><br />
<rdf:type rdf:resource="http://www.openarchives.org/ore/terms/Aggregation"/><br />
</rdf:Description><br />
<rdf:Description rdf:about="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpOREProvider%2FgOREProvider%2Fagg%3Fid%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS"><br />
<rdf:type rdf:resource="http://www.openarchives.org/ore/terms/Aggregation"/><br />
</rdf:Description><br />
<rdf:Description rdf:about="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpOREProvider%2FgOREProvider%2Fagg%3Fid%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS"><br />
<rdf:type rdf:resource="http://www.openarchives.org/ore/terms/Aggregation"/><br />
</rdf:Description><br />
<rdf:Description rdf:about="http%3A%2F%2Fdl09.di.uoa.gr%3A8285%2FaslHttpOREProvider%2FgOREProvider%2Fagg%3Fid%3Dcms%3A%2F%2F7f78c200-f877-11dd-8103-acc6e633ea9e%2Fcfefd160-f877-11dd-8103-acc6e633ea9e%26scope%3D%2Fd4science.research-infrastructures.eu%2FFARM%2FFCPPS"><br />
<rdf:type rdf:resource="http://www.openarchives.org/ore/terms/Aggregation"/><br />
</rdf:Description><br />
</oreatom:triples><br />
<br />
</entry><br />
</source><br />
<br />
==gCube ORE Aggregations==<br />
Since, each compound object is viewed conceptually as an Aggregation in the context of the protocol, a URI for the conceptual constructs is also introduced and similarly reached at<br />
<br />
http://<host>:<port>/aslHttpOREProvider/gOREProvider/agg?id=<gdocuri>&scope=<gCubescope><br />
<br />
An Agregation is one of those special Semantic Web resources for which dereferencing a URI via an HTTP protocol request does not yield a Representation. Therefore, once given the HTTP URI of an Aggregation, gORE-Provider follows the HTTP 303 Forwarding from the Aggregation URI to the Resource Map URI recommendation of ORE, to provide access to the Resource Map that describes the particular Aggregation.<br />
<br />
==gCube ORE Proxies==<br />
In the case where an Aggregated Resource represents a part of the main document, the information about the order of the part inside the compound object is being added as a metadata of the introduced record. This is achieved with the use of Proxies, as those are defined by the ORE data model to enable the establishement of lineage: the assertion that an Aggregated Resource originated or was sourced from another Aggregation.</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16332GCube Web Specifications and Standards Compliance2012-09-19T07:50:14Z<p>Rena.tsantouli: </p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Data Consumption || Producer || Completed<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Category===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16331GCube Web Specifications and Standards Compliance2012-09-19T07:49:42Z<p>Rena.tsantouli: </p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards that fall under each gCube functional area. <br />
<br />
==Table of Protocols==<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification label'''<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Functional area'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction '''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Adoption Status'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Data Consumption || Producer || Completed<br />
|-<br />
|}<br />
<br />
<br />
* '''Functional areas''': Data Consumption / Data Production / Computation Consumption / Infrastructure Management<br />
<br />
* '''Direction''': Producer / Consumer<br />
<br />
* '''Adoption Status''': Completed / On going / Planned<br />
<br />
<br />
<br />
==OAI-PMH==<br />
<br />
===Specification Description===<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
<br />
===gCube Use/Need/Relevance===<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
===Functional Area===<br />
Data Consumption<br />
<br />
===Direction===<br />
<br />
* Producer<br />
<br />
===gCube Adoption Status===<br />
<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
<br />
===Related gCube components ===<br />
* aslHttp OAI_PMH: the http front end for the protocol<br />
* applicationSupportLayer_OAI_PMH: business logic back-end component for the protocol<br />
<br />
<br />
==Protocol XX==<br />
<br />
===Specification Description===<br />
''Description and useful information about the Specification.''<br />
<br />
===gCube Use/Need/Relevance===<br />
<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
<br />
===Functional Category===<br />
''The functional category under which the services underlying the protocol fall.''<br />
<br />
===Direction===<br />
<br />
''The direction towards the system (Producer/consumer), along with any information to clarify the perspective of the interpretation as one or the other or both, if needed''<br />
<br />
===gCube Adoption Status===<br />
''Information about status of adoption of Specification within Our system. ''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
<br />
===Components affected / relevant===<br />
* ''component X: role''</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16322GCube Web Specifications and Standards Compliance2012-09-18T14:05:26Z<p>Rena.tsantouli: </p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards tha fall under each area. <br />
<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Status of System Adoption (Completed/ On going/ Planed)'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer || Completed<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* '''Use/Need/Relevance'''<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
* '''Direction'''<br />
Producer<br />
* '''Specification Info'''<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
** Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
** Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
* '''Information about status of adoption of Specification within Our system'''<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
* '''List of components affected / relevant'''<br />
** aslHttp OAI_PMH<br />
** applicationSupportLayer_OAI_PMH<br />
<br />
=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* '''Use/Need/Relevance'''<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* '''Direction'''<br />
''The direction towards the system (Producer/consumer).''<br />
* '''Specification Info'''<br />
''Description and useful information about the Specification.''<br />
* '''Information about status of adoption of Specification within Our system'''<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* '''List of components affected / relevant'''<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* '''Use/Need/Relevance'''<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* '''Direction'''<br />
''The direction towards the system (Producer/consumer).''<br />
* '''Specification Info'''<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* '''List of components affected / relevant'''<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* '''Use/Need/Relevance'''<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* '''Direction'''<br />
''The direction towards the system (Producer/consumer).''<br />
* '''Specification Info'''<br />
''Description and useful information about the Specification.''<br />
* '''Information about status of adoption of Specification within Our system'''<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* '''List of components affected / relevant'''</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16321GCube Web Specifications and Standards Compliance2012-09-18T14:04:45Z<p>Rena.tsantouli: </p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards tha fall under each area. <br />
<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Status of System Adoption (Completed/ On going/ Planed)'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer || Completed<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* '''Use/Need/Relevance'''<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
* '''Direction'''<br />
Producer<br />
* '''Specification Info'''<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
** Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
** Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
* '''Information about status of adoption of Specification within Our system'''<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
* '''List of components affected / relevant'''<br />
** aslHttp OAI_PMH<br />
** applicationSupportLayer_OAI_PMH<br />
<br />
=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* '''Use/Need/Relevance'''<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* '''Direction'''<br />
''The direction towards the system (Producer/consumer).''<br />
* '''Specification Info'''<br />
''Description and useful information about the Specification.''<br />
* '''Information about status of adoption of Specification within Our system'''<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* '''List of components affected / relevant'''<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* '''Use/Need/Relevance'''<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* '''Direction'''<br />
''The direction towards the system (Producer/consumer).''<br />
* '''Specification Info'''<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* '''List of components affected / relevant'''<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* '''Use/Need/Relevance'''<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* '''Direction'''<br />
''The direction towards the system (Producer/consumer).''<br />
* '''Specification Info'''<br />
''Description and useful information about the Specification.''<br />
* '''Information about status of adoption of Specification within Our system'''<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* '''List of components affected / relevant'''</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16320GCube Web Specifications and Standards Compliance2012-09-18T14:03:17Z<p>Rena.tsantouli: /* Data Consumption */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards tha fall under each area. <br />
<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;width:250px" |'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;width:250px"|'''Status of System Adoption (Completed/ On going/ Planed)'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer || Completed<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* '''Use/Need/Relevance'''<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
* '''Direction'''<br />
Producer<br />
* '''Specification Info'''<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
** Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
** Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
* '''Information about status of adoption of Specification within Our system'''<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
* '''List of components affected / relevant'''<br />
** aslHttp OAI_PMH<br />
** applicationSupportLayer_OAI_PMH<br />
<br />
=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16319GCube Web Specifications and Standards Compliance2012-09-18T14:02:28Z<p>Rena.tsantouli: /* Data Consumption */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards tha fall under each area. <br />
<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;" style="width:375px"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption (Completed/ On going/ Planed)'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer || Completed<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* '''Use/Need/Relevance'''<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
* '''Direction'''<br />
Producer<br />
* '''Specification Info'''<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
** Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
** Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
* '''Information about status of adoption of Specification within Our system'''<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
* '''List of components affected / relevant'''<br />
** aslHttp OAI_PMH<br />
** applicationSupportLayer_OAI_PMH<br />
<br />
=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16318GCube Web Specifications and Standards Compliance2012-09-18T14:00:37Z<p>Rena.tsantouli: /* OAI-PMH */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards tha fall under each area. <br />
<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption (Completed/ On going/ Planed)'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer || Completed<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* '''Use/Need/Relevance'''<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
* '''Direction'''<br />
Producer<br />
* '''Specification Info'''<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
** Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
** Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
* '''Information about status of adoption of Specification within Our system'''<br />
The protocol has already been integrated in the gCube system, from the 'Data Provider' perspective. The description of the adopted methodology towards the integration is described [https://gcube.wiki.gcube-system.org/gcube/index.php/ASL:_OAI-PMH_Implementation here].<br />
* '''List of components affected / relevant'''<br />
** aslHttp OAI_PMH<br />
** applicationSupportLayer_OAI_PMH<br />
<br />
=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16317GCube Web Specifications and Standards Compliance2012-09-18T13:54:54Z<p>Rena.tsantouli: /* OAI-PMH */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards tha fall under each area. <br />
<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption (Completed/ On going/ Planed)'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer || Completed<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* '''Use/Need/Relevance'''<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates the hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
* '''Direction'''<br />
Producer<br />
* '''Specification Info'''<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
** Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
** Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
<br />
=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16316GCube Web Specifications and Standards Compliance2012-09-18T13:53:47Z<p>Rena.tsantouli: /* OAI-PMH */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards tha fall under each area. <br />
<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption (Completed/ On going/ Planed)'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer || Completed<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* '''Use/Need/Relevance'''<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates its hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the gCube collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
* '''Direction'''<br />
Producer<br />
* '''Specification Info'''<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
** Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
** Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
<br />
=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16315GCube Web Specifications and Standards Compliance2012-09-18T13:53:08Z<p>Rena.tsantouli: /* Data Consumption */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards tha fall under each area. <br />
<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption (Completed/ On going/ Planed)'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer || Completed<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* Use/Need/Relevance<br />
Through OAI-PMH protocol, gCube infrastructure acts as a 'Data Provider' and disseminates its hosted metadata records in a standard fashion, thus allowing for interoperation with other data e-Infrastructures that run autonomously. Other infrasturctures can harvest the metadata descriptions of gCube content in archives so that their services can exploit the gCube collections. The protocol provides an application-independent interoperability framework for metadata exchange between the online parties. <br />
<br />
* Direction<br />
Producer<br />
* Specification Info<br />
The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is a well-established standard in the content management and library science worlds that is gaining in importance. It provides a low-barrier mechanism for repository interoperability and defines the following parties and software components: <br />
* Data Providers are repositories that expose structured metadata via OAI-PMH. A 'Data Provider' such as an academic library runs a Repository that supports OAI-PMH as a means of exposing metadata information about resources, for instance academic publications.<br />
* Service Providers then make OAI-PMH service requests to harvest that metadata. A 'Service Provider' uses Harvester software to harvest metadata from Data Providers. The harvested metadata can then be used to provide valued-added services, such as a website that allows browsing and searching through their catalog. <br />
<br />
OAI-PMH is a set of six verbs or services that are invoked within HTTP. An implementation of OAI-PMH must support representing metadata in Dublin Core, but may also support additional representations.<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
<br />
=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16314GCube Web Specifications and Standards Compliance2012-09-18T13:07:17Z<p>Rena.tsantouli: /* Data Consumption */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards tha fall under each area. <br />
<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption (Completed/ On going/ Planed)'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer<br />
|-<br />
| Completed<br />
|}<br />
==OAI-PMH==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
<br />
=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16313GCube Web Specifications and Standards Compliance2012-09-18T13:06:35Z<p>Rena.tsantouli: /* Data Consumption */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards tha fall under each area. <br />
<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption (Completed/ On going/ Planed)'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
<br />
=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16312GCube Web Specifications and Standards Compliance2012-09-18T13:06:12Z<p>Rena.tsantouli: /* Data Consumption */</p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards tha fall under each area. <br />
<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption (Completed/On going/Planed)'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
<br />
=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16311GCube Web Specifications and Standards Compliance2012-09-18T13:05:25Z<p>Rena.tsantouli: </p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards tha fall under each area. <br />
<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
<br />
=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16310GCube Web Specifications and Standards Compliance2012-09-18T11:05:03Z<p>Rena.tsantouli: </p>
<hr />
<div>This area collects the Standard Specifications supported by the gCube system APIs, as part of the WP11 activities and towards meeting the integration and interoperability objectives for promoting the openness of the e-Infrastructure to other neighbouring and external ones. The collection focuses on the widely used, HTTP-based Specifications and generic interchange protocols (data/content standards, metadata standards, Web interface standards, security standards, data sharing protocols) that service both disseminating and consuming system's needs. This analysis is conducted per functional category and addresses the use, need and relevance of the standards tha fall under each area. <br />
<br />
=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16309GCube Web Specifications and Standards Compliance2012-09-17T12:57:14Z<p>Rena.tsantouli: </p>
<hr />
<div>=Data Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
<br />
=Computation Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
=Infrastructure Management=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#Protocol | Protocol]] || Producer<br />
|-<br />
|}<br />
==Protocol==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16308GCube Web Specifications and Standards Compliance2012-09-17T12:55:04Z<p>Rena.tsantouli: /* OAI-PMH */</p>
<hr />
<div>=Data Management=<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* Use/Need/Relevance<br />
''Describe the use/need/relevance of the specification in respect to the functional area of the system.'' <br />
* Direction<br />
''The direction towards the system (Producer/consumer).''<br />
* Specification Info<br />
''Description and useful information about the Specification.''<br />
* Information about status of adoption of Specification within Our system<br />
''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented.''<br />
* List of components affected / relevant<br />
<br />
=Computation Consumption=<br />
=Infrastructure Management=</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16307GCube Web Specifications and Standards Compliance2012-09-17T12:54:21Z<p>Rena.tsantouli: </p>
<hr />
<div>=Data Management=<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* Use/Need/Relevance<br />
'''Describe the use/need/relevance of the specification in respect to the functional area of the system. <br />
* Direction<br />
'''The direction towards the system (Producer/consumer).'''<br />
* Specification Info<br />
'''Description and useful information about the Specification.'''<br />
* Information about status of adoption of Specification within Our system<br />
'''Whether the specification has already been integrated and supported within the system, or it is under implementation, or soon to be implemented. <br />
* List of components affected / relevant<br />
=Computation Consumption=<br />
=Infrastructure Management=</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16306GCube Web Specifications and Standards Compliance2012-09-17T12:45:00Z<p>Rena.tsantouli: </p>
<hr />
<div>=Data Management=<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* Use/Need/Relevance<br />
* Direction towards the System (Producer/Consumer)<br />
* Specification Info<br />
* Information about status of adoption of Specification within Our system<br />
* List of components affected / relevant<br />
==OAI-PMH==<br />
=Computation Consumption=<br />
=Infrastructure Management=</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16305GCube Web Specifications and Standards Compliance2012-09-17T12:44:40Z<p>Rena.tsantouli: </p>
<hr />
<div>=Data Management=<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
| align="center" style="background:#f0f0f0;"|'''Status of System Adoption'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer<br />
|-<br />
|}<br />
==OAI-PMH==<br />
* Use/Need/Relevance<br />
* Direction towards the System (Producer/Consumer)<br />
* Specification Info<br />
* Information about status of adoption of Specification within Our system<br />
* List of components affected / relevant<br />
<br />
=Computation Consumption=<br />
=Infrastructure Management=</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16304GCube Web Specifications and Standards Compliance2012-09-17T12:39:54Z<p>Rena.tsantouli: </p>
<hr />
<div>=Data Management=<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer<br />
|-<br />
|}<br />
==OAI-PMH==<br />
label<br />
use / need / relevance of spec strictly in one's area<br />
information about spec<br />
information about status of adoption of spec in our system<br />
perhaps list of components affected / relevant<br />
direction (our part in this spec producer/consumer)<br />
functional area<br />
<br />
=Computation Consumption=<br />
=Infrastructure Management=</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16303GCube Web Specifications and Standards Compliance2012-09-17T12:38:40Z<p>Rena.tsantouli: </p>
<hr />
<div>=Data Management=<br />
=Data Consumption=<br />
==OAI-PMH==<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
|-<br />
| [[#OAI-PMH | OAI-PMH]] || Producer<br />
|-<br />
|}<br />
=Computation Consumption=<br />
=Infrastructure Management=</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16302GCube Web Specifications and Standards Compliance2012-09-17T12:37:29Z<p>Rena.tsantouli: </p>
<hr />
<div>=Data Management=<br />
=Data Consumption=<br />
==OAI-PMH==<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
|-<br />
| [#OAI-PMH] || Producer<br />
|-<br />
|}<br />
=Computation Consumption=<br />
=Infrastructure Management=</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16301GCube Web Specifications and Standards Compliance2012-09-17T12:36:45Z<p>Rena.tsantouli: </p>
<hr />
<div>=Data Management=<br />
=Data Consumption=<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
|-<br />
| [#OAI-PMH] || Producer<br />
|-<br />
|}<br />
=Computation Consumption=<br />
=Infrastructure Management=</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16300GCube Web Specifications and Standards Compliance2012-09-17T12:29:08Z<p>Rena.tsantouli: </p>
<hr />
<div>{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
|-<br />
| [#OAI-PMH] || Producer<br />
|-<br />
|}</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16299GCube Web Specifications and Standards Compliance2012-09-17T12:28:55Z<p>Rena.tsantouli: </p>
<hr />
<div>{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
|-<br />
| [#OAI-PMH]] || Producer<br />
|-<br />
|}</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16298GCube Web Specifications and Standards Compliance2012-09-17T12:28:18Z<p>Rena.tsantouli: </p>
<hr />
<div>{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
|-<br />
| [#OAI-PMH]]<br />
|-<br />
| [Producer]<br />
|-<br />
|}</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16297GCube Web Specifications and Standards Compliance2012-09-17T12:27:35Z<p>Rena.tsantouli: </p>
<hr />
<div>{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
| align="center" style="background:#f0f0f0;"|'''Direction towards the System (Producer/Consumer)'''<br />
|-<br />
| [[#Tree Manager API|Tree Manager]]<br />
|-<br />
|}</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16296GCube Web Specifications and Standards Compliance2012-09-17T12:25:35Z<p>Rena.tsantouli: </p>
<hr />
<div>{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
|-<br />
| [[#Tree Manager API|Tree Manager]]<br />
|-<br />
|}</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Web_Specifications_and_Standards_Compliance&diff=16295GCube Web Specifications and Standards Compliance2012-09-17T12:24:46Z<p>Rena.tsantouli: Created page with '{| {{table}} | align="center" style="background:#f0f0f0;"|'''Specification Label''' |- | Tree Manager||Tree-based CRUD operations over pluggable sources of …'</p>
<hr />
<div>{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Specification Label'''<br />
|-<br />
| [[#Tree Manager API|Tree Manager]]||Tree-based CRUD operations over pluggable sources of structured data||WS||SOAP||[https://gcore.wiki.gcube-system.org/gCube gCore]<br />
|-<br />
|}</div>Rena.tsantoulihttps://wiki.gcube-system.org/index.php?title=GCube_Integration_and_Interoperability_Facilities_Development_Methodology&diff=16294GCube Integration and Interoperability Facilities Development Methodology2012-09-17T12:17:24Z<p>Rena.tsantouli: /* Functional Area Cases Identification Template */</p>
<hr />
<div>The methodology presented in this page has been defined to drive the development of the [[GCube_Integration_and_Interoperability_Facilities | gCube Integration and Interoperability Facilities]].<br />
{|align=right<br />
||__TOC__<br />
|}<br />
<br />
== Objective ==<br />
The objective of this area is to define and record the procedures followed towards the development of the set of facilities targeted from the WP. These facilities will manifest sets of Application Programming Interfaces (APIs) and of Interoperability cases. The described activities target the establishment of the definition of the integration and interoperability frameworks of gCube. They will lead to the identification and implementation of standards at the boundaries of services and the entire infrastructure for interactions with its elements or its entity. The main focus is the provision of programmatic APIs that enable integration and interoperability, for and beyond the specifications adopted. <br />
<br />
The perspective of the workpackage faces interoperability at both a top-down and a bottom-up approach:<br />
* bottom-up approach: definition of a framework in terms of principles, architecture and procedures, to which the implementing programmable APIs will comply<br />
The tasks are as follows:<br />
<br />
# Analysis of APIs at infrastructure layer boundaries, i.e. external access points, internal services, libraries etc.<br />
# Identification of opportunities and needs for: homogenization, consistency, standards compliance, ease of use etc.<br />
# Aggregation of findings into a framework<br />
* top-down approach: API-domains (functionality + protocol) are the main vehicles of the top-down approach. The technologically concrete outcome of each case analysis will be the definition of the specifications of the resources interaction, that will drive implementations and support of the programmable APIs. <br />
The tasks in this path are as follows:<br />
<br />
# Definition of Functional Categories<br />
# Identification of Functional Areas in each Functional Category.<br />
# Identification of Integration and Interoperability Cases in each functional areas.<br />
# Evaluation of Integration and Interoperability Cases (protocols, use cases, needs, interoperability flows, SWOT analysis, prioritization etc) - at this point the analysis must meet the Bottom Up approach.<br />
# Conclusions and selection of implementation path<br />
<br />
In the bottom-up approach the main direction is defined towards the removal of internal boundaries and dependencies to specific technologies. In the top-down approach the options will be identified towards the adoption of standards and the cases per domain will be analyzed in a cost/benefit manner. <br />
The two approaches are launched sequentially. The principles of the framework on which the well organized set of APIs will be based are being analyzed while the API cases that are oriented towards main functional areas are being investigated on the basis of those principles. The most important concern within the WP objectives is to adopt higher level standards and to build interoperable APIs.<br />
The two paths, meet at the the point of consumption of lower level artifacts via their API for the satisfaction of functional area needs, and they mutually affect each other, as the top-down approach will drive needs from APIs while the bottom-up approach will promote specific cases over alternative ones and will raise the opportunities for more cases.<br />
<br />
Not all tasks mentioned above belong to the Integration and Interoperability Framework Definition, whoever there is a strong relationship according to this two-direction approach.<br />
<br />
== Bottom-Up Approach: Framework Evolution Roadmap in Brief ==<br />
* Conceptualization of "Framework"<br />
* Activity partitioning: split work in layers and functional areas + assign work to WGs<br />
* Activity partitioning outcome into framework - The Framework definition : aggregation of findings in several areas<br />
* Facilities development: APIs (outside this activity)<br />
* Framework evolution: as a response to feedback and RTD WP progress<br />
<br />
The roadmap defines the steps through which the designation and development of integration facilities will lead to the framework definition and adoption. The first tasks include the conceptualization of the framework and its elements and the assignement of tasks for analysis to working groups. The next step will be the definition of the principles governing the various framework elements. In the third stage, the aggregation of findings in several areas will gradually lead to the formalization of the framework definition in terms of procedures and technologies. The definition of technologies that form integral part of the framework will lead to the formalisation of framework toolkits. After each stage indicated by the roadmap completes, an interaction with other RTD WPs is required. Through this interaction an assessment of developments will be performed for refining and extending the initial concepts and integrate the finalization of framework definition.<br />
<br />
The full plan of the activity can be found [[GCube_Integration_and_Interoperability_Facilities_Development#Work_plan | here]].<br />
<br />
=== Framework Conceptualization ===<br />
<br />
In this section, the structure of the analysis that will lead to the framework conceptualization is briefly described. In particular, the following matters need to be defined:<br />
<br />
==== Principles ====<br />
Definition of the principles and policies of Integration and Interoperability, identifying both the roadmap and the primary specifications (protocols) to be covered by the various facilities and tasks of the WP. Define the main rules and guidelines through which the compliant APIs will be hiding the complexity of the distributed infrastructure and will be dealing with common functionality.<br />
<br />
==== Architecture ====<br />
Definition of a formal architectural view of Integration and Interoperability Layer, as an evolution of the current Application Service Layer. <br />
<br />
==== Technologies ====<br />
Technologies that will be used and will further define the investigation domains of the API cases. <br />
<br />
==== Adopted specifications ====<br />
(to evolve continuously)<br />
<br />
==== Components following the definition ====<br />
Reference to components following the definition of the framework<br />
<br />
The definition of the framework is conducted in the "[[Integration and Interoperability Facilities Framework]]" section.<br />
<br />
== Top-Down Approach: Functional Categories and Areas Definition ==<br />
The resources offered by the infrastructure are exposed through functionality that falls into several functional categories. The primary ones are [[Integration_and_Interoperability:_Data_Management|Data Management]] and [[Integration_and_Interoperability:_Data_Consumption|Data Consumption]], however more can be identified in the vast landscape of a D4Science ecosystem.<br />
<br />
The main objective is the organisation of the design and implementation of the APIs that allow access to the system resources and their binding to standards specific to each area. Each functional category is divided into more targeted functional areas for which a number of cases will be identified. The cases relate to the provision of multi-protocol APIs (e.g. Java, REST, SOAP, depending on the need and relevance) and related implementation components for easy consumption for a number of facilities that fall into the area. <br />
An analysis of the resources involved is being performed per functional area. Gathering of resources is an essential part of the functional areas, especially as a result of their evolution to more concrete cases and ultimately to solutions. Resources are the entities that at the bottom line have to become interoperable. As such the achievement of interoperability ultimately leads to resource specifications that capture policies and interfaces. An examination of the overall infrastructure's capabilities and the requirements for the exploitation by other resources will lead to the definition of the given options and needs. The analysis of the technological solutions will lead to the designation of API specific case analysis and the creation of bindings to specific protocols and standards.<br />
<br />
Cases are linked in several ways:<br />
* in thematically related groups that fall under the same functional category<br />
* in hierarchies that move from protocol/technology to resource interoperability specifications <br />
* in dependencies nets that guarantee that a case will survive in the complex e-Infrastructures environment<br />
<br />
The functional categories identified are the following: <br />
* [[Integration_and_Interoperability:_Data_Management| Data Management]]<br />
* [[Integration_and_Interoperability:_Data_Consumption| Data Consumption]]<br />
* [[Integration_and_Interoperability:_Computation_Consumption| Computation Consumption]] (tentative)<br />
* [[Integration_and_Interoperability:_Infrastructure_Management| Infrastructure Management]] (tentative)<br />
<br />
For each functional area, a number of cases can be identified as candidates for fulfilling its requirements. This creates a 3-level hierarchy: Functional Category -> Functional Area -> API Case. A concrete example of this hierarchy is the following:<br />
<br />
Data Consumption -> Generic Information Retrieval -> Open Search<br />
<br />
=== Functional Area Cases Identification Template ===<br />
In order to facilitate the analysis of the functional areas, a template has been constructed. This template foresees the description analysis of a functional area, with the inclusion of one or more cases that satisfy the respective functionality. More info can be found on the template.<br />
<br />
The template can be located here [[Integration and Interoperability Functional Area Analysis Template | here]].<br />
<br />
<!-- *== API Specific Case Analysis Template ==<br />
[[WP11: API Cases Identification Report Template | Report Template]] --><br />
<br />
<br />
[[WP11 Specifications Overview]]</div>Rena.tsantouli