Re: holdings-schema proposal

Thanks Jo, the working examples make it quite clear to me.  If we have
agreement (Leif??) Is it worth adding this as an official clarification?

Janifer Gatenby
Pica ITC Consultancy
+31 71 5246  500 (tel)
+31 71 5223 119 (fax)
janifer.gatenby@pica.nl)
----- Original Message -----
From: "Johan Zeeman" <joe.zeeman@tlcdelivers.com>
To: "Leif Andresen" <LEA@bs.dk>; <www-zig@w3.org>; "Janifer Gatenby"
<Janifer.Gatenby@pica.nl>; <rden@loc.gov>
Sent: Friday, November 30, 2001 4:50 PM
Subject: Re: holdings-schema proposal


> I've done some example XML for the various alternatives that have been
> talked about so far.  I have omitted the highest levels of the hierarchy,
> since they are the same in all examples :
>
> <holdingsStructure>
>     <bibItemInfo>
>         <targetItemId>
>             00123445678
>         </targetItemInfo>
>     </bibItemInfo
>     <holdingsStatement>
>         <holdingsSiteLocation>
>             ...
>            <institutionOrSiteId>
>                 myLibSymbol
>             </institutionOrSiteId>
>             ...
>         </holdingsSiteLocation>
>             ...
>             <localHoldings>
>                 ...
>                 <bibView> ... -- our examples go here
>                 </bibView>
>                 ...
>             </localHoldings>
>             ...
>     </holdingsStatement>
>     ...
> </holdingsStructure>.
>
> I've also omitted the schema tagSet tag number from the element names -
the
> DanZig schema includes them. I've used an elipsis ( ... ) to show where
> additional or repeated elements may, but need not, be present.  In all the
> examples I have included only the minimally required elements.  No
required
> elements have been omitted.
>
>
> If my understanding is correct, Leif wants to have:
>
> <bibView>
>     ...
>     <bibPartEnumeration>
>         <enumCaption> vol. </enumCaption>
>         <specificEnumeration> 5 </specificEnumeration>
>         <bibPartEnumeration>
>             <enumCaption> no. </enumCaption>
>             <specificEnumeration> 2 </specificEnumeration>
>         </bibPartEnumeration>
>     </bibPartEnumeration>
>     ...
>     <numberOfPieces> 1 </numberOfPieces>   -- this element is required
> (probably erroneously!)
> </bibView>
>
>
> The schema currently allows you to have:
>
> <bibView>
>     ...
>     <bibPartEnumeration>
>         <enumCaption> vol. </enumCaption>
>         <specificEnumeration> 5 </specificEnumeration>
>     </bibPartEnumeration>
>     ...
>     <numberOfPieces> 1 </numberOfPieces>
>     <childBibPart>
>         ...
>         <bibPartEnumeration>
>             <enumCaption> no. </enumCaption>
>             <specificEnumeration> 2 </specificEnumeration>
>         </bibPartEnumeration>
>         ...
>         <numberOfPieces> 1 </numberOfPieces>
>     </childBibPart>
> </bibView>
>
>
> or, using childEnumChronSummary (structured choice):
>
> <bibView>
>     ...
>     <bibPartEnumeration>
>         <enumCaption> vol. </enumCaption>
>         <specificEnumeration> 5 </specificEnumeration>
>     </bibPartEnumeration>
>     <childEnumChronSummary>
>         <childEnumChronSummaryStructured>
>             <primaryEnum>
>                 <startingEnum>
>                     <enumCaption> no. </enumCaption>
>                     <specificEnumeration> 2 </specificEnumeration>
>                 </startingEnum>
>             </primaryEnum>
>         </childEnumChronSummaryStructured>
>     </childEnumChronSummary>
>     ...
>     <numberOfPieces> 1 </numberOfPieces>
> </bibView>
>
>
> or (unstructured choice):
>
> <bibView>
>     ...
>     <bibPartEnumeration>
>         <enumCaption> vol. </enumCaption>
>         <specificEnumeration> 5 </specificEnumeration>
>     </bibPartEnumeration>
>     <childEnumChronSummary>
>         <childEnumChronSummaryUnstructured>
>             no. 2
>         </childEnumChronSummaryUnstructured>
>     </childEnumChronSummary>
>     ...
>     <numberOfPieces> 1 </numberOfPieces>
> </bibView>
>
>
> So, when we add issue no. 3 Leif would have:
>
> <bibView>
>     ...
>     <bibPartEnumeration>
>         <enumCaption> vol. </enumCaption>
>         <specificEnumeration> 5 </specificEnumeration>
>         <bibPartEnumeration>
>             <enumCaption> no. </enumCaption>
>             <specificEnumeration> 2 </specificEnumeration>
>         </bibPartEnumeration>
>         <bibPartEnumeration>
>             <enumCaption> no. </enumCaption>
>             <specificEnumeration> 3 </specificEnumeration>
>         </bibPartEnumeration>
>     </bibPartEnumeration>
>     ...
>     </numberOfPieces> 2 </numberOfPieces>
> </bibView>
>
>
> and the schema currently allows you to have:
>
> <bibView>
>     ...
>     <bibPartEnumeration>
>         <enumCaption> vol. </enumCaption>
>         <specificEnumeration> 5 </specificEnumeration>
>     </bibPartEnumeration>
>     ...
>     <numberOfPieces> 2 </numberOfPieces>
>     <childBibPart>
>         ...
>         <bibPartEnumeration>
>             <enumCaption> no. </enumCaption>
>             <specificEnumeration> 2 </specificEnumeration>
>         </bibPartEnumeration>
>         ...
>         <numberOfPieces> 1 </numberOfPieces>
>     </childBibPart>
>     <childBibPart>
>         ...
>         <bibPartEnumeration>
>             <enumCaption> no. </enumCaption>
>             <specificEnumeration> 3 </specificEnumeration>
>         </bibPartEnumeration>
>         ...
>         <numberOfPieces> 1 </numberOfPieces>
>     </childBibPart>
> </bibView>
>
>
> or, using childEnumChronSummary (structured choice):
>
> <bibView>
>     ...
>     <bibPartEnumeration>
>         <enumCaption> vol. </enumCaption>
>         <specificEnumeration> 5 </specificEnumeration>
>     </bibPartEnumeration>
>     <childEnumChronSummary>
>         <childEnumChronSummaryStructured>
>             <primaryEnum>
>                 <startingEnum>
>                     <enumCaption> no. </enumCaption>
>                     <specificEnumeration> 2 </specificEnumeration>
>                 </startingEnum>
>                 </endingEnum>
>                     <specificEnumeration> 3 </specificEnumeration>
>             </primaryEnum>
>         </childEnumChronSummaryStructured>
>     </childEnumChronSummary>
>     ...
>     <numberOfPieces> 2 </numberOfPieces>
> </bibView>
>
>
> or (unstructured choice)
>
> <bibView>
>     ...
>     <bibPartEnumeration>
>         <enumCaption> vol. </enumCaption>
>         <specificEnumeration> 5 </specificEnumeration>
>     </bibPartEnumeration>
>     <childEnumChronSummary>
>         <childEnumChronSummaryUnstructured>
>             no. 2, 3
>         </childEnumChronSummaryUnstructured>
>     </childEnumChronSummary>
>     ...
>     <numberOfPieces> 2 </numberOfPieces>
> </bibView>
>
>
> Note that, if there is no requirement to transmit information about a
> childBibPart other than its enumeration and/or chronology, the
childBibParts
> required by the current schema need contain no elements other than the
> bibPartEnumeration or bibPartChronology (and the required "numberOfPieces"
> element).  If there is other information, such as piece information for an
> unbound serial part, this can easily be carried in the childBibPart.  Such
> information could not be carried if the childChronEnumSummary element is
> used or if Leif's proposed change is adopted.
>
> The schema already supports multiple mechanisms for carrying enumeration
and
> chronology hierarchies, and those in the current schema are not, in my
view,
> significantly more verbose or complex than the additional new mechanism
that
> Leif is proposing.  I continue to think it would be a disservice to the
> community to add yet another mechanism to the ones that have been defined.
>
> I would support an amendment to make the numberOfPieces element optional
(I
> actually think it is a technical error, since a bibPart might not have a
> corresponding piece).  There could be some processing and display
> efficiencies to be gained by adding elements for "childEnumCaption" and
> "childChronCaption" to BibPart, so that captions don't need to be
repeated,
> but this is a minor issue.
>
> j.
>
>
>
>

Received on Friday, 30 November 2001 11:13:51 UTC