AQ Use Case 1: Register Resources

Transverse Use Cases 1-10  are activity / capability  elements common to most SBA scenarios.  This is a workspace for the implementation of Transverse Use Case 1 specific to the Air Quality/Health SBA. The implementation of the UC components is accessible through the links.


Use Case A

 Title

Registration of Air Quality Community Catalog in GEOSS Service Registry (CSR)

 Overview

This use case covers the registration of the AQ Community Catalog as a Catalog/Component in the GEOSS Registry (link) . The registerd AQComCat is 'found' through AQ Use Case 3 and its catalog content harvested through the GEOSS Clearinghouse.

 Actors and Interfaces


Actors:

(1) AQ Community Catalog Service Provider;
(2) GEOSS Common Infrastructure Registry (CSR)
Interfaces:
AQ Community Catalog <- GEOSS Common Infrastructure Registry (CSR) 

Initial Status and preconditions


1. AQ CoP has deployed  AQComCat as an online resource, Web Accessible Folder (done)
2. AQ CoP as provider is registered as organization in the GEOSS CSR (not done - AQ CoP registered?)

 Evolution


1. AQ CoP as Service Provider chooses to provide AQComCat as a Catalog/Component . links (done - same as pre-condition 1)
2. AQ CoP determines that metadata to add through web links (needs work - what does this mean?).
3. AQ CoP registers AQCoMCat as a Catalog with metadata links and update logistics. (registered, update??)


 Post Condition

 The AQ Community Catalog can be harvested by the Clearinghouse and found by GEOSS users. UC 1 is a Precondition for UC 2.  (dunno?)



Use Case B

 Title

 Registration of OGC WMS or WCS Service in the Air Quality Community Catalog

 Overview

 This use case describes the process of registering an OGC WCS service with the Air Quality Community Catalog. The OGC WCS is subsequently harvested by the GEOSS Clearinghouses via AQ Use Case #3.

 Actors and Interfaces

  • Service Provider
  • Community Catalog Steward

Initial Status and preconditions

  •  A smoke forecast OGC WCS has been deployed following AQ Use Case #2
  • An Air Quality Community Catalog has been established

 Evolution

(basic flow steps)

    1. Create an ISO 19115 metadata document
    2. Copy the ISO 19115 metadata document into the AQ Community Web Accessible Folder
in process of transitioning to a semi-automated registration process:

1) An XSLT is used to convert OGC WCS GetCapabilities elements to appropriate ISO 19115 metadata elements
2) An ISO 19115 metadata web form is auto-filled with the information from the GetCapabilities
2) The ISO 19115 metadata elements that are not auto-filled using GetCapabilities input are completed manually via human input
3) An ISO 19115 document is created and saved in the Air Quality Community Web Accessible Folder


 


 Post Condition

The smoke forecast OGC WCS is included in the Air Quality Community Catalog. In this particular case, the OGC WCS service's metadata file is included in the Air Quality Web Accessible Folder which is registered with the GEOSS registry following AQ Use Case #1.

 
Strategy: 
Need to register ogc wms/wcs services for each dataset parameter in community catalog. Each layer can be described with keywords/tags. Layers can be found and viewed through clearinghouse or applications built on clearinghouse can regroup layers into datasets or other ways... 

At DataFed a dataset is the parent to several parameter layers - i.e. Airnow dataset has pm fine point, pm fine grid, pm point, pm grid, ozone point, ozone grid and all of these layers for WMS and WCS (12 parameter/service combinations). Originally, we registered all of this in the community catalog as two metadata records for Airnow one for wms and one for wcs. We encoded the parameter layers as coverage description > attribute description. The problem with this is that the dataset is the smallest item discoverable object in the GEOSS clearinghouse and really we'd rather discover dataset parameters and be able to group by different methods including dataset, but also similar parameters or others... 

So, I think in ISO talk maybe the DataFed dataset is a 'dataset series' and the paramter layers (pm fine, pm, ozone) would be datasets? Within the each dataset they would have a service id for wms/wcs/... ? or would we need two dataset registrations each having a single service id object? I think smaller atomic entities would allow the dynamic creation of metadata records for data series.
 
Comments