Resources = services!

[Tony Linde]

How's that for efficiency - I answer your email two hours before it gets
posted :)

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Ray Plante
> Sent: 06 June 2003 19:28
> To: registry at ivoa.net
> Subject: RE: Resources = services!
> 
> 
> 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
>