schemas

[Tony Linde]

Hi Ray,

> Among the Relationship values is SERVESDATACOLLECTION.  Do 
> you see this as 
> a generic relationship or just applying to services.  Does 
> this concern 
> you at all? 

I didn't know if there was any way to subdivide the relationship values. If
this is possible that'd be good. I just tried altering the enumerations
(deleting existing ones, adding a new one) in Relationship but XmlSpy
stopped me so it may be that we just have to maintain a single list at the
top. Needs more research.

> In the DataCollection resource class, I defined an Access 
> element that 
> includes references to services that access that data collection 
> (Access/ServiceRef).  Should this relationship be expressed 
> at the generic 
> resource level?  If so, then we have the situation of metadata being 
> possibly applied to non-applicable resource classes.  

It certainly shouldn't be at the resource level and is fine where it is
(though I think I'd have the Access as 0-many with AccessType consisting of
Format+Rights+ServiceRef (should ServiceRef be IdentifierType? - do we need
to duplicate Title?).

I think the Relationship set is for documenting simple relationships that we
don't want to define any further.

Come to think of it, maybe we shouldn't have Access defined here. A simple
pointer to the Service via Relationship would enable the system to get all
the relevant data from the Service resource, which is where it should be
held. Maybe Access could be dropped completely?

In which case maybe we should also drop ManagingOrg from AuthorityType since
this could also be dealt with by Relationship.

Or should we keep some relationships specifically named for ease of
searching?

> Also, we talked about having references to other resources 
> having both a 
> displayable title and a identifier.  Should we change the RelatedTo 
> element's type to "ResourceReferenceType"?

Could do, but as I say above, this is a duplication of information - maybe
saves some time but will quickly get out of step unless every relationship
has a reverse pointer - not something we should insist on I think. I'd go
for dropping the title and just using IdentifierType.


On that point, I changed the IdentifierType so that ResourceKey is mandatory
but nillable. I think this is more appropriate when only the Authority
resource should miss out the ResourceKey.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Ray Plante
> Sent: 15 September 2003 19:56
> To: registry at ivoa.net
> Subject: Re: schemas
> 
> 
> Hi Tony,
> 
> this looks good.  The Registry type looks sufficient.  When we get 
> to defining the registry interface, we can think about what needs to 
> go into the Capability element.  
> 
> Couple questions...
> 
> Among the Relationship values is SERVESDATACOLLECTION.  Do 
> you see this as 
> a generic relationship or just applying to services.  Does 
> this concern 
> you at all? 
> 
> In the DataCollection resource class, I defined an Access 
> element that 
> includes references to services that access that data collection 
> (Access/ServiceRef).  Should this relationship be expressed 
> at the generic 
> resource level?  If so, then we have the situation of metadata being 
> possibly applied to non-applicable resource classes.  
> 
> Also, we talked about having references to other resources 
> having both a 
> displayable title and a identifier.  Should we change the RelatedTo 
> element's type to "ResourceReferenceType"?
> 
> cheers,
> Ray
> 
>