Facility and Instrument

[Tony Linde]

Hi Ray,

As the base of *all* resources of every kind, the contents of the Resource
type should only contain elements which might apply to each resource type.
Any element which categorically does not belong to any type of resource
should not be part of the Resource schema but should apply at a lower level.
This is definitely the case with Facility and Instrument so they should not
be part of Resource.

Optional elements are those which are optionally applied between instances
of a schema. If an element is *never* to be used in a subclass then it
should not be included in the parent class. The only way of getting rid of
it would be to inherit by restriction which we've agreed is a bad idea.

As for examples: a service which takes a VOTable and returns a plotted
image; a service which takes two VOTables and merges them; a service which
takes an image and returns a catalogue; etc. In short, any service which
does not query a facility- or instrument-related data source.

Why not just make it part of DataCollection and SkyService?

Cheers,
Tony. 

> -----Original Message-----
> From: Ray Plante [mailto:rplante at poplar.ncsa.uiuc.edu] 
> Sent: 02 October 2003 20:24
> To: Tony Linde
> Cc: registry at ivoa.net
> Subject: RE: Facility and Instrument
> 
> 
> Hi Tony,
> 
> We discussed this issue about Facility and Instrument a bit 
> at our NVO 
> telecon today.  I think we agree that we would like to avoid an extra 
> layer in the inheritance tree to add these two items.  
> However, on our 
> end, we do have a preference to keep these as optional 
> elements rather 
> than relationships.  
> 
> On Wed, 1 Oct 2003, Tony Linde wrote:
> > > I presume that the motivation for this idea comes from the
> > > concern that 
> > > Facility and Instrument do not apply consistently to all possible 
> > > resources.  Is this still a concern?  If yes, what classes of 
> > > resources 
> > > would want to prevent the application of these metadata?  
> > 
> > This is indeed my concern - I definitely oppose having them as 
> > standard parts of Resource. It is less of a problem is classes down 
> > the inheritance tree include information not always used 
> but we should 
> > avoid this at the very top level.
> 
> Encoding them as relationships still makes them part of the 
> core Resource 
> metadata.  We would, presumably, define 
> "associated-with-facility" and 
> "associated-with-instrument" relationship names; they are, 
> thus, available 
> for associating with any resource.  This seems equivalent to having 
> optional elements.  Furthermore, I'm not clear exactly what 
> the harm is to 
> having them as elements (an example would be helpful).  
> 
> I think there are two key points that favor optional elements:
>   *  we have not identified a class of resource (either 
> current or future) 
>      where these two items should never be applied. 
>   *  the elements will likely apply to most resources that 
> are registered.  
> 
> Also, I would prefer to see the use of the RelatedResource be focused 
> relating one registered resource to another registered 
> resource.  For now, 
> we do not expect to separately register facilities and instruments in 
> their own right (though that could happen for some in the future).  
> Granted, the RelatedResource XML does not require the other 
> resource to be 
> registered, and the Facility & Instrument elements do allow 
> IDs to point 
> to registered descriptions; however, these two things will be used 
> differently in the registry.  Facility and Instrument will be 
> commonly 
> used as searchable fields by users; the RelatedResource will 
> be used to 
> untangle apparent redundancies in results (e.g. recognizing 
> mirrors and 
> derivations, distinguishing data collections and the services 
> that access 
> them).  
> 
> In closing, we should be clear that this is *not* an issue of meeting 
> requirements:  both approaches will allow one to locate 
> resources based 
> on, say, the telescope name.  It's a matter of the more nebulous 
> attributes like clarity, robustness, etc.
> 
> cheers,
> Ray
> 
>