Schema 0.8.3

[Ray Plante]

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