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
>
>
Received on 2003-09-15Z22:02:23