Hi Roy -
(I hate to expand this further, but I am adding Ray to this as he has been involved in these discussions for some time as well).
It has always been this way (except for cone search, which is the trivial exception). SIA V1 has FORMAT=metadata, which returns service metadata; this is the previous incarnation of getCapabilities. So does SLAP, and probably others based on this pattern as well. The SIA spec defines the service metadata returned, as does the SCS spec, edited by Ray only several months ago, and now in PR. The VOResource for these services is based on the service metadata defined in these service specifications. We *wanted* greater compatibility between DAL services and Registry, so getCapabilities tries to be more compatible with an actual VOResource record.
A use-case where this comes into play is a client application, which queries the service to find out what its capabilities, limitations, and any custom extensions are, in order to pose a query. For example, for theory data, a client application using SSAP or SLAP can query the a service which front-ends a theoretical model to determine any custom theory model parameters it supports, and use these to drive a specialized theoretical model (Pedro and the guys at ESAC already have applications which do this for example).
I think it is fairly fundamental that a service be self-contained and self-describing in terms of its core functionality; a service knows what its capabilities are. This makes the service more useful as it provides everything essential to use (as opposed to discover) the service. In addition, if anything changes the service implementation can update (or even autogenerate) its own service metadata, and the integrity of this information is much more likely to be preserved. Between Registry and DAL, we have even been discussing mechanisms to (for example) automatically update this information in the registry if anything should change at the service level.
Many of these same arguments apply to dataset metadata by the way; a service which manages access to a data collection, including possibly actively mediating dataset metadata, should be self-contained in terms of access to metadata for the data which it manages. One might *cache* this information elsewhere to build more powerful global data discovery mechanisms, but in terms of reliable information management, the information should ultimately be controlled by the service.
I will stop there, but additional arguments are possible, e.g, in terms of overall system automation and integrity (this metadata can be autogenerated from the more fundamental resources which the VO layer accesses).
On Wed, 25 Apr 2007, Roy Williams wrote:
> Doug
>
> So long as the table metadata is available through queryData(), the TAP can
> be used effectively. Therefore we are good to go.
>
> But the getCapabilities() function is, I gather, is to get the VOResource
> registry record for the service from the service itself rather than from the
> registry.
>
> I wonder if we can make the getCapabilities() method optional, and/or put it
> into the next version of the TAP standard? The VO architecture puts the
> ultimate truth in the *registry*, not in the service; in this sense we are
> different from OpenGIS who do it the other way around.
>
> Did something change when I wasn't looking? Is the registry now just a cache
> and the services have ultimate truth? When was this decided? Are cone-search
> implementors now forced into providing a getCapabilities() method?
>
> Roy
>
>
>> This ability to query table metadata, e.g., the list of tables and their
>> properties, and the columns of an individual table, is an important feature
>> of TAP, and is required to be able to query arbitrary data tables.
>>
>> getCapabilities on the other hand, is a separate service operation, used
>> to return the service metadata, describing the capabilities of the service.
>> Any client can use this information, but one very important one is the
>> Registry, which will cache this information in a VOResource, so that
>> clients can search for services based on their capabilities.
>
Received on 2007-04-25Z19:07:02