getCapabilities() for standard services
Ray Plante
rplante at poplar.ncsa.uiuc.edu
Thu Apr 26 05:58:17 PDT 2007
Doug, Pedro, et al.,
Sorry I've fallen behind on this discussion. You guys have respectfully
tried to bring me in, but it seemed so daunting ;-)
I do want to catch you up on how I have been involved "behind the scenes"
and make some observations along the way. Doug and I have discussed
getCapabilities() in the context of SSA. The early dicussion centered on
the question, does the metadata Doug wants to be returned by
getCapabilities() covered by what we do in VOResource. My conclusion was
not only was it covered, but it also it wasn't "over-covered"; that is,
the desired capability description is essentally the information put in
the registry.
The two attached files illustrate this. One shows a mapping of the
capabilities metadata from the SSA document. The other is a sample
VOResource document that captures this information. It assumes that
VOResource has been extended in the standard way to capture the
SSA-specific information.
Now, I claim that it is the responsibility of the developers of an IVOA
standard protocal (like SSA & TAP) to define the protocol-specific
metadata that is to appear in the registry. In particular, they need to
define the specific VOResource extension schema in the standard way. To
help with this, I will be giving a short tutorial on how to do this
extension at DAL1 and REG2 in Beijing.
OBSERVATION #1: Whether or not we have a getCapabilities() method, the
SSA and TAP authors have to define their capability metadata.
We know it is not trivial for an end publisher to create VOResource
records: a tool is needed to create them, and a tool is needed to check
them (and a person is needed to make sure they make sense!). These tools
are not cheap to create; nevertheless we have built them: the first one
is the resource registration page that is part of each public registry,
and the second one is a validater that I have just deployed.
OBS #2: If we make service providers serve their own VOResource
record, the easiest way to provide them with the authoring and checking
tools is to provide a "download" VOResource button on our registration
pages.
OBS #3: If someone provides other tools that provide these functions,
that is no problem for registries.
Many people for a long time have argued that services should be
self-describing, the two main reasons being:
a. The descriptions are more likely to be kept up to date if they are
served by the service itself.
b. Clients can adapt their usage of the service by looking at its
capabilities first.
OBS #4: If services are self-describing, the process of registration
becomes simpler, only because the publisher has already paid the price
of describing the capabilities.
As long as updating capabilities is a matter of the developer/publisher
updating a static file, then I'm dubious as whether it will be kept more
up to date if the file lives with the service or with the registry. Only
when this information (or at least the bits most likely to change) gets
generated automatically by the server software (because it can detect its
own capabilities) does argument a. make sense to me. There's an
advantage, though, if it resides at the registry: the registry can check
the validity of the description while it has the publisher on the hook.
If it is at the service, it's a bit more complicated contacting the
publisher when the description goes bad. Nevertheless, I like to be open
to innovation, and we can probably deal with this one.
OBS #8: Client capability negotiation is a new thing in the VO; we
currently have have no (little?) software/experience making use of it.
OBS #7: if getCapabilities() is essentially about returning a VOResource
document, then it is essentially identical to the getMetadata() that
was proposed by GWS as part of the support services standard.
One way we discussed deploying the support services standard was
as a set of optional functionality added to a service. We would encourage
support for the standard as a way of reaching a "gold" status.
My own recommendation regarding getCapabilities() would be to spin it off
as an optional bit (a la the support services standard) that can be easily
made part of any DAL service. This would allow us to go ahead and deploy
it with new services and get more experience using it. We need time to
develop support for it in the registry as well as in other client
software. In the future, new DAL specs could say "you MUST support the
support services spec vX.X".
hope this helps,
Ray
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssavor.xml
Type: text/xml
Size: 7786 bytes
Desc: sample VOResource description
URL: <http://www.ivoa.net/pipermail/dal/attachments/20070426/ebddbe67/attachment-0001.xml>
-------------- next part --------------
From rplante at poplar.ncsa.uiuc.edu Thu Dec 14 13:32:37 2006
Date: Thu, 14 Dec 2006 13:32:35 -0600 (CST)
From: Ray Plante <rplante at poplar.ncsa.uiuc.edu>
Reply-To: Ray Plante <rplante at ncsa.uiuc.edu>
To: Doug Tody <dtody at nrao.edu>
Subject: Re: SSA getCapabilities metadata
Hi Doug,
This information maps into the VOResource data model very well. The
bits fall into three categories:
1. Core Resource metadata: metadata already defined in RM and
supported by the VOResource core schema.
2. Interface metadata: extensions that describe how to access a
service and use the protocol.
3. Service-specific Capability metadata: extensions that describe
how the service behaves.
(3) is essentially where we create new metadata terms specific to
SSA. We can get by with what is currently defined for interfaces;
however, given where you are trying to push things with DAL interfaces
and making them somewhat uniform, we (i.e. the DAL WG) may wish to
create some new interface extensions (more on that later).
Below I've taken your list of capabililty metadata on the left-hand
side and indicated on the right how it maps into VOResource. In
general, I've identified the metadatum by its XPath; otherwise,
comments are in [ ]. "capability/[new]" indicates a new element we
would need to define to cover this concept. Finally, notes are mark
{#}. This will make more sense, after I've put an example together.
SSA_Capabilities
Version (1.0) (SSA getCapabilities capability/@standardURI
version) {1}
Schema reference/link [SSA VOResource extension
schema namespace] {2}
Possibly other schema references [use the schema namespace
mechanism] {2}
General Service Metadata
Title (short description of service) title
Description (longer description of content/description
service)
Identifier URI (registry identifier identifier
for service)
Service Info URL (Web page describing content/referenceURL
service or service provider)
Publisher (publisher name) curation/publisher
PublisherID (registry URI of curation/publisher/@ivo-id
publisher)
Contact Info curation/contact
Service type here? (or only [As I think you will see,
in Capabilities) these are not necessary.]
Collection info here? (or replicate
in each Capabilities record)
Capabilities list here? (or just
scan Capabilities)
Capability Metadata (SOAP interface) [see {3}]
n/a (similar to HTTP capabilities;
some info probably duplicated)
Capability Metadata (HTTP interface)
Distributed computing platform (HTTP) [what is this?]
Service type (SSA) capability/@xsi:type
Interface version (SSA interface interface/@version
version)
SSA-defined level of compliance
(minimal, query, full) capability/[new]
HTTP Service BaseURL capability/interface/accessURL
Collections (shortName and URI for
each collection)
Access restrictions (public, rights
proprietary, mixed)
DataSource (survey, pointed, custom, capability/[new]
theory, artificial)
CreationType (archival, cutout, capability/[new]
filtered, mosaic, ...)
Keywords (for searches) content/subject
Boolean Features Supported {4}
Native data pass-through supported capability/[new]
Query by object name supported capability/[new]
Query by bandpass name supported capability/[new]
Bandpass range-list supported capability/[new]
Query ranking heuristic supported capability/[new]
Protocol compression supported capability/[new]
Associations supported capability/[new]
Large queries supported via paging capability/[new]
Other Properties
Operations supported (omit at present
as all defined ops are mandatory)
Output formats supported (list of MIME format
types, possibly parameterized)
Interface WCS frames supported (list of capability/[new]
strings; for POS etc.) [use std STC frames?]
Query response page size (nrecords; capability/[maxRecords?]
one page of QR)
Query response total size (nrecords; capability/[maxRecords?]
maximum size of QR)
Max search radius capability/maxSR
Max aperture capability/[new]
Service-defined parameters (list: name, capability/interface/...
type, description) [see {4}]
Notes:
1. capability/@standardURI contains an IVOA identifier that
identifies the standard, including major version. That implies
that there is a registry record that describes the standard itself.
Minor versions that don't affect the protocol or metadata can be
handled a little differently; more on that after looking at an
example.
2. We can use the standard XML namespacing to identify the special
purpose schemas.
3. The Data and Service metadata model naturally allows one to
group and segregate metadata. See example for details.
4. This could be with a simple <supports> element; e.g.:
<supports> NativePassthru </supports>
<supports> QueryByBandpass </supports>
<supports> Compression </supports>
<supports> Paging </supports>
Here, the values are defined and controled by the SSA extension
schema. One problem with this, is that every time you add a
feature, you have to update the schema, which breaks all the
applications that use it.
An alternative approach being picked up by VOSpace is to identify
these features via an IVOA identifier. That is, it might look
like this:
<supports> ivo://ivoa.net/ssa#NativePassthru </supports>
<supports> ivo://ivoa.net/ssa#QueryByBandpass </supports>
<supports> ivo://ivoa.net/ssa#Compression </supports>
<supports> ivo://ivoa.net/ssa#Paging </supports>
The resource record describing the SSA standard
(ivo://ivoa.net/ssa) could then include a definition of each of
these terms after the #. Thus, you could add a feature without
updating the schema. (Plus, others could define, register, and
then claim to support other non-standard features.)
5. The so-called HTTPParam Interface type is used to describe how to
call a simple GET service. This is where a provider can list
local, service-defined parameters.
The data model for HTTPParam assumes a pretty flat view of
parameters--that is, each parameter is somewhat independent of
another. If we want to better capture the DAL approach of a set
of "commands" or "verbs" that imply a corresponding set of
parameters, we might want to define a new interface type to
capture this.
More information about the dal
mailing list