Facility and Instrument

[Ray Plante]

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