What do user groups look for (in the GCI?) and what criteria do they know how to apply?
This is a response from the AQ CoP to the call for discussion on the usefulness of the GEOSS Commom Infrastructure to find things.
Lieberman email, Apr 3, 2008: We have been working in AIP-2 on various aspects of exercising the Geoss Common Infrastructure to find things. Because questions have been raised about how well these aspects integrate, and because, well, it is time to do so, we will focus in the telecon next Wednesday on the end-to-end experience of going to a geoportal and finding geoss service resources.
Summary of AQ Requests to CCRM Workgroup:
- Can we agree on a common list of queriable 'discovery' parameters.. at least for now?
Can we agree on a minimum set of returnable parameters?
- E2E Call: Minimum set of queryable and returnable properties for now is the CSW:Record (GCI Requirements)
Will there be an API for searching the Clearinghouses by the queriable parameters?
- E2E Call: All clearinghouses are required to support CSW 2.0.2 interfaces (GCI Requirements)
- E2E Call: Still no clarification on if all clearinghouses could harvest on the same schedule
Lieberman questions and AQ WG responses below:
Rudy: For AQ applications, users would need to find AQ-relevant data and associated metadata and then access (bind to) the data. The 'find' criteria for data should include at least: space (BBOX), time (TimeRange), Dataset/Parameter, Platform/Sensor, Keyword (both thematic and freetext). For metadata: Provider, AccessServiceType, Links to AccessService and Link to more Metadata Stefan: Also need to ask who are the user groups - their user interface needs to GCI are likely to be different. For example, air quality analysts are more likely to make queries for specific datasets/parameters and platform/sensors than a high school student researcher who may only search based on a general keyword, like 'air quality.' So the air quality analyst may be better served by an air quality community portal/application based search while the student may be better served by one of the geo portals (perhaps as the geo portals evolve they end up catering to particular user types?). There are different needs not only in how to formulate a search but also how to view and interact with the results of the search.
David: Currently the user groups are not defined. As a result, many who investigate the portals will conclude that they fail to deliver the "web-based interface for searching and accessing the data, information,
imagery, services and applications available through GEOSS."
How strong is the connection between applied criteria and available queryable properties in the clearinghouse?
Rudy: In the current Clearinghouses the queriable ('discovery'?) properties are few and different for the 3 CHs. We should agree on the minimum queriable set soon..so we can differ everywhere else.Stefan: A related question is, "What is the connection between applied criteria and available queryable properties in the clearinghouses?"If agreement on a minimum set of queryable properties common across clearinghouses is not feasible, then clear documentation of each clearninghouses implementation is needed. Users of the clearinghouses need to know which metadata fields are associated with which query fields. If the clearinghouses each handle harvesting and searching differently, users of the clearhinghouses need to know how they differ in order to determine which clearinghouse best suites their particular search needs.
Does the clearinghouse harvests enough information to respond adequately to geoportal (or community portal?) queries? If not, where is the breakdown.
Rudy: The USGS CH harvests (collects from the AQ Community Catalog Web Accessible Folder) the full metadata record. However, most of the metadata fields are not queriable...other than by full text search. Is everything of interest to a geoportal user getting registered in order to be harvested?
Rudy: The AQ Community Catalog records are now harvested (somewhat sporadically) by all 3 CHs. Do we need to register both services /components themselves and the metadata services which describe them?
Rudy: No. If we register data as a service, then the data registration should contain some and link to more metadata.Stefan: Maybe the questions is, "do we need to accomodate the registration of both services/components and the metadata services which describe them?" In other words, how much standardization is there on the registration process side? It's possible that a service provider would register a service with minimal metadata and someone else register a metadata record that references that service. The community catalogs help with this as they take care of some of the reconciliation but there's probably also a need to do reconciliation post-GCI registration.Is too much findable, e.g. duplicates and stale records?
Rudy: Yes, too much and too little. David: An example of too much: services that are in development. Service providers may need some sort of test mode, so that the portals do not return results for services that are not ready for general use.
Lionel: Stale records are not deleted from Clearinghouse after removed from WAF (See Lionel's comment below)What should be the minimum set of returnable parameters from the Clearinghouses?
Rudy: links to full harvested metadata record, links to extended metadata
Lionel: URL Links from metadata record (see Lionel's comment below)
Rudy: For the 3 Clearinghouses:
Can we agree on a common harvesting procedure and schedule?
For additional details on the current state of AQ AIP - GEOSS Common Infrastructure (GCI), see the Air Quality Use Cases: