Schema 0.8.3

[Tony Linde]

Hi Ray,

> The intended operational difference between the Resource class and the 
> metadata "Type" is that a resource falls into only one class but can have 
> multiple types.  This allows, for example, a data collection to contain 
> survey data and simulations for educational and outreach purposes.  

I was seeing type and class as equivalent since there was no Class element
or attribute. Do we simply use the element name to identify the 'class'?

> making Description a complex type, it diverges from the Dublin Core 
> definition.  Also, I gather from the schema that 

<rant>
I really wish we could stop constraining what we do to fit DC. The VO
Registry does not fit the OAI model. If we want to interoperate with OAI we
can simply provide harvesting methods which convert registry info into OAI
structures. This is a simple programming task. We should *forget* about DC
while we're designing the registry and focus on astronomy.
</rant>

> "Description" and "ReferenceURL".  It should probably also contain 
> "Source" (which was temporarily left out of 0.8.2).  How 
> about "Summary"?

Sounds good.

> This is okay.  URL should be optional (with note that it is intended 
> particulary for cases when related resource does not have an 
> identifier).  

I only added this for the case of the Facility/Instrument pointers. I'm
happy to stick with *registered* resources only if we also come up with,
say, a SeeAlso type which includes a URL and a Description - might be neater
in fact.

> >   drop Facility and Instrument
> >     - use Relationship (see above vr:RelatedResourceType)
> 
> This is a tricky one.  

These certainly shouldn't go in Resource unless they can be generalised into
something similar to Relationship (or SeeAlso).

> >   ? Subject should be called Keyword
> 
> As you know, there is still strong desire to use Dublin Core names where 
> applicable unless there is a compelling reason not to.  I'm not sure we 
> have on for this.

See above rant! I assumed Keyword meant more to astronomers and people
writing astronomy software which will use these resources.

> I find Creator more applicable than Contributer; I would recommend 
> keeping this.  These are optional, so they don't impose a burden on 
> registrants.  Even registries could choose not to cache this info.  
> However, by retaining it, we enable interoperability with the 
> DL world via DC.  

See above rant! We don't 'enable interoperability with the DL world via DC'
if a meaningless field in the schema is not used or, worse, misused by users
and developers.

We already have Publisher and Contact. Do we really need these other fields?
The primary use of the VO registry is for software to find data and services
which can be plugged into a workflow or used as a tool, not for people to
flick through. And even if people do want to just browse the registry,
they're unlikely to do so looking for publishers, contacts, cresators and
contributors.

Cheers,
Tony. 

> -----Original Message-----
> From: Ray Plante [mailto:rplante at poplar.ncsa.uiuc.edu] 
> Sent: 01 October 2003 07:00
> To: Tony Linde
> Cc: registry at ivoa.net
> Subject: Re: Schema 0.8.3
> 
> 
> Hi Tony,
> 
> Thanks for this note.  (I was out of email contact last Wed. 
> & Thur.  I 
> can't believe that it's taking more 3 days to catch up with 2 days of 
> email.)
> 
> On Fri, 26 Sep 2003, Tony Linde wrote:
> > vr:ResourceType
> >   vr:Type
> >     should be mandatory
> >     should only be single occurrence
> 
> The intended operational difference between the Resource 
> class and the 
> metadata "Type" is that a resource falls into only one class 
> but can have 
> multiple types.  This allows, for example, a data collection 
> to contain 
> survey data and simulations for educational and outreach purposes.  
> 
> Do you have a particular need to have this be a single occurance?  
> 
> If we this freer association with Type, should we really make it 
> mandatory?  The generic "Resource" element allows the registration of 
> resources that do not fall into one of the defined specific 
> classes.  What 
> if none of the currently defined Types apply.  
> (Alternatively, we could 
> add a catch-all "other" type.)
> 
> >   combine vr:Description and vr:ReferenceURL into complex type
> >     (use Relationship?)
> 
> The combining idea is okay, but the naming has some difficulties.  By 
> making Description a complex type, it diverges from the Dublin Core 
> definition.  Also, I gather from the schema that 
> "Description/Title" is 
> intended to contain the text description; however, given the 
> definition of 
> "Title"--the full name of a resource--this is not a good 
> element for this 
> purpose.  
> 
> If we want to combine these, we should come up with another 
> name for the 
> parent element (which you've called "Description") and have 
> it contain 
> "Description" and "ReferenceURL".  It should probably also contain 
> "Source" (which was temporarily left out of 0.8.2).  How 
> about "Summary"?
> 
> > vr:RelatedResourceType
> >   add description & make identifier optional (see 
> RelatedResourceType.jpg)
> >   ? add url as well?
> 
> This is okay.  URL should be optional (with note that it is intended 
> particulary for cases when related resource does not have an 
> identifier).  
> 
> >   drop Facility and Instrument
> >     - use Relationship (see above vr:RelatedResourceType)
> 
> This is a tricky one.  
> 
> I like this better than adding another class level just to add these; 
> however, I'm not sure that Relationships is the best place.  
> 
> I see how we might conclude that RelatedResource would be the place 
> to handle this since our last version allowed an identifier.  
> However, I 
> don't expect that we will commonly register Facilities and 
> Instruments 
> initially.  Relationships, as I understand them, is primarily 
> intended for 
> relating one resource to another *registered* resource.  
> 
> What's your motivation for this move?  Is it primarily to be 
> consistant in 
> relating one resource to another (which may or may not be 
> registered)?  Or 
> is it related to the concern that these elements are not universally 
> applicable?
> 
> >   ? Subject should be called Keyword
> 
> As you know, there is still strong desire to use Dublin Core 
> names where 
> applicable unless there is a compelling reason not to.  I'm 
> not sure we 
> have on for this.
> 
> >   ** if above accepted, move Keyword & ContentLevel to Resource
> >   **  & derive everything from Resource
> 
> There is general concensus for some variation on this.  
> 
> >   Date should be CreateDate and LastUpdateDate
> 
> I agree we need both of these; I would say this need is 
> compelling enough 
> to diverge from DC naming.  
> 
> To be consistant with similar cases (e.g. Contact), the RM 
> document could 
> be updated to define two dates this way:
> 
>   Date.Creation
>   Date.Update
> 
> This is naturally rendered in XML as 
>   <Date>
>     <Creation>...</Creation>
>     <Update>...</Update>
>   </Date>
> 
> How does this sound?
> 
> > vr:CurationType
> >   drop Creator
> >   add Logo to CurationType
> >   do we need Contributor?
> >   Version - is this really relevant
> 
> I find Creator more applicable than Contributer; I would recommend 
> keeping this.  These are optional, so they don't impose a burden on 
> registrants.  Even registries could choose not to cache this info.  
> However, by retaining it, we enable interoperability with the 
> DL world via 
> DC.  
> 
> > vr:ContactType
> >   ? drop Address and Phone
> 
> this is okay by me.  
> 
> cheers,
> Ray
> 
>