Resources = services!

[Ray Plante]

On Fri, 6 Jun 2003, Tony Linde wrote:
 > > Do you see "supertypes" as...
 > >   o  essentially the same thing as "classes" (that is, it captures
 > most
 > >        of what you're going for),
 >
 > Yep!

Okay, cool.

 > (I am perfectly happy with the name 'class' instead of
 > supertype):

The terminology is clunky either way.  The idea was to differentiate
it from the metadatum "Type", which takes its name from the Dublin
Core metadatum of the same name.  A resource can have more than one
"Type", but these do not imply any extra metadata as the
"supertype/class" does.

 > - I think 'Resource' is redundant - everything is a resource.

This is allowed for describing resources that (in the eyes of the
registrant/curator) do not fall into one of the specific classes.
Nevertheless, one could discover it in a registry, read its
description, and access its ReferenceURL.

 > - I would class 'Organization' and 'Project' as community-type
 > resources.

I think this makes sense.  While some might think of these as
semantically different, an important test is whether the two imply a
different set of extended metadata.  If not, the semantic difference
could be delineated via the "Type" metadatum.  Should we call the combined
entity 'Organization'?  Can it allow descriptions of individuals, or
should they be a different type.

 > - What is 'DataCollection' and why would one want to list it if it is
 > not the service which gives access to the data?

The VOResource schema defines a DataCollection as a logical grouping
of data which, in general, is composed of one or more accessible
datasets.  (BTW, I put a metadata dictionary for VOResource at
http://www.ivoa.net/internal/IVOA/IVOARegWp03/VOResource.html that may
be helpful.)

I called this out as a separate class on the assumption that a single
data collection may be accessible by more than one service (each of
which being separately registered).  For example, the ADIL has three
registered services: its browser-based web form, a Cone Search
interface, and an SIA interface.

It is also possible that one may want to register data collections
that are not accessible by any registered service.  Examples:
   o  a legacy space mission that may require a custom request
      by email to the curator for copy to CDROM.
   o  a proprietary collection with no publicly available interface; by
      registering it, people can at least know that it exists.
   o  a collection that for some reason (e.g. it's too raw) is not
      itself available but from which other collections are derived and
      are available.  By registering the unavailable collection, the
      derived collections can to refer to it as part of a "derived
      from" piece of metadata.

What is less clear is how we might handle the trivial case: e.g. a
small collection of images that are just available via FTP.  Should
this interface be registered separately?

An important feature of the XML Schema is extensibility (which should
apply to our metadata framework in general).  In defining the initial
set of classes, it was not my intention that we define all the
possible classes now, but rather that we be able to add new classes as
we see necessary in the future (thus, the need for a generic
Resource).  On the other hand, the value of being more encompassing in
our definition of classes now is to help learn which Resource metadata is
truely generic.

All that said, I would add "Standard" (or "StandardSpec"), a description
of a VO standard specification.  Besides providing a pointer to the
document that defines the standard, it allows us to uniquely refer to the
standard in the descriptions of other resources.  That is, a Service can
be recognized unambigously as an SIA service via its ServiceStandardID.

 > > While I'm not against multiple MFs, I'm still unclear on the
 > > how you see this being used.  Are MFs and extensions
 > > synonymous?  Do expect that subcommunities (or sub-VOs; e.g.
 > > AstroGrid) wanting to use a specialized format that is only
 > > supported within a realm of resources?  Is this a hedge
 > > against new formats in the future?
 >
 > All of the above!

(I was afraid you would say this :-)  My main concern is that, in
practice, the difference between a Metadata Format and an extension
will be confused.  This needs to be examined in the details of how the
XML is rendered (and schemas identified).  This is do-able, but it
needs to be clearly designed.

 > Allowing a resource to contract to provide multiple sets of metadata
 > gives us more flexibility. A resource which provides a multi-faceted
 > service can contract to provide metadata on all the types of service it
 > offers. We can subdivide the sets of metadata more finely (if we want)
 > making it less likely that resources will have to put N/A in many of the
 > fields. A user/agent can select the MFs to be returned thus providing
 > only relevant information. And, yes, it provides more flexibility for
 > the future.

I wonder if MFs make more sense only in the context of a specific
service.  In the case of OAI, the MFs are part of the meta-meta
information describing the harvesting interface (i.e. the
"ListMetadataFormats" operation).  For a Web Service, this would be
effectively handled in the WSDL description.  It's a little tricky
because it's an attribute of both the resource and the service that
emits the resource description.  That is, some resource descriptions
may not be convertable to some MFs due to sufficient semantic
mismatch; however, it's the service that is responsible for do the
conversion, and so it needs to know how.

So if I get a resource description that says, "I can be gotten in
these other formats", I can go back to the place I got it and request
it in that format.  Who determines which formats are supported?  I
think its ultimately the service (e.g. regsitry) and not the creator
of the resource description.

cheers,
Ray