Print

Print


Thanks a lot for the answer.

About the ambiguity introduced by multiple registry entries, IMHO that's
the problem of the schema users. The schema users will have to make sure
multiple registry entries point to the same format and no ambiguity is
introduced. 

So the schema will need to be modified accordingly, to something like
this:

<xs:complexType name="formatComplexType">
  <xs:choice>
    <xs:element minOccurs="1" maxOccurs="1"
      name="formatDesignation" type="formatDesignationComplexType">
    </xs:element>
    <xs:element minOccurs="1" maxOccurs="unbounded"
      name="formatRegistry" type="formatRegistryComplexType">
    </xs:element>
    <xs:sequence>
      <xs:element minOccurs="1" maxOccurs="1"
        name="formatDesignation" type="formatDesignationComplexType">
      </xs:element>
      <xs:element minOccurs="1" maxOccurs="unbounded"
        name="formatRegistry" type="formatRegistryComplexType">
      </xs:element>
    </xs:sequence>
  </xs:choice>
</xs:complexType>


Thanks,

Zhiwu Xie

Graduate Research Assistant
Research Library
Los Alamos National Lab


On Mon, 2006-02-06 at 07:38, Priscilla Caplan wrote:
> That's a good question.  I went back through committee minutes and found 
> this entry:  "We should add in a note that if you are using a 
> fileformatName, you don't need to also use a pointer into a registry; 
> use one or the other (or both if you'd like)."  Thanks to Erin Rhodes, 
> who was the best minute-taker ever.  The "both if you'd like" never made 
> it into the data dictionary, but I can't find anything in subsequent 
> minutes to indicate a change of mind.
> 
> So apparently there was no intent by PREMIS to make these elements 
> mutually exclusive, and you can use both a format name and a pointer 
> into a registry if you desire.
> 
> Regarding the ambiguity of multiple registries, yes, I can see this 
> would be a problem.  We made the registry pointer repeatable because we 
> envisioned there could be many different registries containing different 
> types of information.  For example, one registry might have format 
> specifications, while another might contain detailed environment 
> information but no specifications.  You would indicate what kind of 
> information you were getting from each registry by using the "role" 
> element.  BUT, there would be nothing preventing you from pointing to 
> two registries for the same information.  If there were multiple 
> registries, it seems to me their content is more likely to be 
> overlapping than globally unique.
> 
> Since we don't really have much experience with registries yet, we just 
> have to make our best guesses.
> 
> p
> 
> Bronwyn Lee wrote:
> > Re Zhiwu Xie's comment: "Just to clarify, this is one or the other, not
> > one and/or the other, meaning I can't have both. Am I right?"
> > 
> > Would there be any reason to not allow both? If the formatRegistryKey
> > contained the format name (and version) it would be OK not to have
> > formatName as well, but if the formatRegistryKey was just a record
> > number, it would be nice to 'see' the format name without having to go
> > to the registry. If you allowed both, I suppose there could be ambiguity
> > if the formatName didn't match what was in the registry entry - however
> > even if you didn't allow both, ambiguity could occur, since
> > formatRegistry is repeatable and the occurrences could potentially
> > indicate different formats.
> > 
> > Bronwyn Lee
> > Australian Partnership for Sustainable Repositories
> > (http://www.apsr.edu.au)
> > National Library of Australia
> > Canberra ACT 2600 Australia
> > 
> >