[seek-dev] implement XQuery in EcoGrid and SRB

[Dave Vieglais]

David Stockwell wrote:

> Dave Vieglais wrote:
> 
>> David Stockwell wrote:
>>
>>> Matt, others.
>>>
>>> I'd like to bring OGC into the discussion. Would not the XML output 
>>> of a GetCapabilities call
>>> in an OGC WMS be another metadata standard to incorporate?
>>> For interest Yang has implemented Dave's WMS client  at 
>>> http://landscape.sdsc.edu/~yyu/index.html
>>> on a couple of test layers.  mgv0001 is coarse 0.167deg (~2MB) and 
>>> hydro_dem is medium 0.01 deg (~2G)
>>> for speed comparisons.
>>>
>>> Now, do we need to install and input data into SRB to get the 
>>> metadata functions?
>>> It would be easier if the ecogrid infrastructure could just use the 
>>> results of the GetCapabilities call.
>>> Also, other OGC: WMS sites could be registered in the ecogrid.
>>>
>>> Cheers
>>>
>>
>> OGC WMS is a type of service, and hence an instance would likely be 
>> registered in the ecogrid registry as a "WMS service" as opposed to an 
>> "Ecogrid Query Service".  The capabilities document in this case could 
>> not be searched with the ecogrid query service since it does not 
>> expose the query API.
> 
> 
> Are you considering that the capabilities output of the WMS includes the 
> metadata descriptions of the data layers
> served by the WMS? GetCapabilities describes both function and content.
> 

Yes, but I was just pointing out that since the OGC WMS doesn't have the 
  ecogrid query API, an ecogrid client querying the grid could not query 
the GetCapabilities metadata directly.  This is more a comment about the 
ecogrid design rather than the OGC WMS.

>>
>> In order to search the OGC capabilities with the current view of the 
>> ecogrid query service design, it would be necessary to implement the 
>> ecogrid query API as part of the OGC WMS service instance. 
>> Alternatively, a metadata store such as morpho or srb could be used to 
>> provide eml descriptions of the wms service (probably derived directly 
>> from the output of getCapabilites).
> 
> 
> The first option would preclude legacy OGS WMS's wouldn't it? 

Yep.  Unless someone wrote a kind of "meta-wrapper" that provided an 
interface to a multitude of legacy OGC WMS services.

The second
> would fly and may
> be better considering the output of GetCapabilities is not necessarily 
> complete.  I am thinking of
> the lifemapper WMS where the list of species mapped is not obtained from 
> GetCapabilities
> due to issues with ESRI IMS (from what I understand). In this case the 
> auxillary metadata store
> could extend the usefulness of the WMS.

Yeah, there are a lot of WMS services that do not have static layers, 
hence storing the output from a getcapabiltiies document in a metadata 
registry someplace would not help (unless of course the dynamic layers 
were fully described in the getcapabilities doc).  There's all sorts of 
concurrency issues with this approach as well.

> 
>>
>> There was some attempt a while back to get OGC service providers to 
>> register their instances with UDDI, but for political reasons I think, 
>> this did not eventuate (at least not with the public uddi registries). 
>> Seems odd to me that it didn't fly, since it would be great to be able 
>> to query a registry for a list of mapping services and build dynamic 
>> maps on the fly.  I suspect there may have been some contention with 
>> the spatial data clearinghouse folks, but that's just a guess.
>>
> I havn't got that far but there do seem to be registries of WMS out 
> there.  They are probably
> not adequate as we want to be able to integrate the use of disperate 
> data sources to the point
> of developing heterogeneous distributed data systems don't we?
> 
> Cheers
> 
>