Resources = services! (fwd)

[Tony Linde]

Hi Ray,

> Marcus tells me that my recent messages to the registry list 
> are not going 
> through due to some problems they're having with the list.  

That's a nuisance - I can see mine up there - maybe part of Markus' attempt
to shut out the spam. Anyway, I'm copyingthis to you and Bob to keep things
going...

> resource can have more than one "Type", but these do not 
> imply any extra metadata as the "supertype/class" does.  

I'm happy with having Type as a simple list from which a resource chooses
one or more entries as long as it can also select (contract to provide)
specific MMs (metadata modules - sounds better than metadata formats - MFs -
or subclasses or extension or anything that implies inheritance). Whether we
can tie one Type to one MM might prove to be more problematic.

> > - 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'm still not sure I like the idea of 'anything' being dropped into the
registry with no idea of what it is (ie, no way of automatically identifying
its class and type).

> > - 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.

I think you misunderstood me. They are not the same entity: both would be of
class 'Community' while they would have different Types: 'Organisation' and
'Project'. And they would contract to provide different MMs. So I do see
them as semantically different and having different metadata.

> > - What is 'DataCollection' and ...
> 
> The VOResource schema defines a DataCollection as ...

I could not see DataCollection in VOResource.xsd but I'm not used to looking
at schemas.

> BTW, I put a metadata dictionary 
> for VOResource at 
> http://www.ivoa.net/internal/IVOA/IVOARegWp03/VOResource.html 

Very helpful - and a good idea!

> I called this out as a separate class on the assumption that 
> a single data collection may be accessible by more than one 
> service 

Got that and I agree with the idea. In my 'TonyOnRegistryStructure' document
(see previous message) I generalised it to a Reference resource, ie anything
which may be referenced but is not usually queried directly.
  
> It is also possible that one may want to register data 
> collections that are not accessible by any registered 
> service.  Examples: ...

Hadn't thought of them but sounds a good idea.

> 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?

Yes, as a service - doesn't have to be a web service - a service just has to
'do' something, optionally returning something.

> > 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. 

I think MMs (see renaming above) and extensions are the same.

> I wonder if MFs make more sense only in the context of a 
> specific service. 

More in the context of a specific 'class' and 'type' of service.

>  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.  

You've lost me - probably because I don't know much about web services.
Resources should be fully described in the registry - whether or not some of
this description is duplicated in the WSDL - maybe we can ultimately create
a tool that generates the WSDL from a registry entry. But many resources
won't be services and many services won't be web service delivered. So the
WSDL must be subordinate to the registry metadata.

I've tried to create a schema based on my 'TonyOnRegistryStructure'
document:
  http://wiki.astrogrid.org/bin/view/Main/TonyOnRegistryStructure
and have attached early picture and draft xsd (possibly good example of
powerful tool - XMLSpy - in the hands of the ignorant!).

In this a resource must have identity and class metadata (Md). The
identityMd consists of the resourceID structure plus optional name, title
etc. the classMd consists of a class identifer (either registry, authority,
Service, Community or perSpace) followed by metadata relating to that class
which I've not defined.

Each resource can also have one or more sets of metadataModule metadata and
I've tried to imagine some examples: serviceMd (which can include one of
dataAccessMd, imageCutoutMd or catalogExtractionMd), referenceMd (which can
include dataCollectionMd), personMd, groupMd, projectMd (should these be
within a communityMd group?), etc...

Even given the very simplistic view, I hope this and the
'TonyOnRegistryStructure' document gives a better view of what I am getting
at.


Cheers,
Tony. 

> -----Original Message-----
> From: Ray Plante [mailto:rplante at poplar.ncsa.uiuc.edu] 
> Sent: 09 June 2003 16:40
> To: Tony Linde
> Subject: RE: Resources = services! (fwd)
> 
> 
> Hi Tony,
> 
> Marcus tells me that my recent messages to the registry list 
> are not going 
> through due to some problems they're having with the list.  
> For now, I'm 
> forwarding this and another message from Friday to you 
> personally to keep 
> the discussion going.  You'll probably get another copy from 
> the list when 
> they get it straightened out. 
> 
> cheers,
> Ray
> 
> ---------- Forwarded message ----------
> Date: Fri, 6 Jun 2003 13:28:04 -0500 (CDT)
> From: Ray Plante <rplante at poplar.ncsa.uiuc.edu>
> Reply-To: Ray Plante <rplante at ncsa.uiuc.edu>
> 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
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlRegistry.png
Type: image/png
Size: 11291 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/registry/attachments/20030610/574c7b25/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlRegistry.xsd
Type: text/xml
Size: 4479 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/registry/attachments/20030610/574c7b25/attachment-0001.xml>