W3C home > Mailing lists > Public > www-zig@w3.org > November 2001

Re: holdings-schema proposal

From: Janifer Gatenby <janifer@wanadoo.fr>
Date: Fri, 30 Nov 2001 17:12:44 +0100
Message-ID: <019601c179b9$da2bd1a0$efc1fdc1@q09bd>
To: "Johan Zeeman" <joe.zeeman@tlcdelivers.com>, "Leif Andresen" <LEA@bs.dk>, <www-zig@w3.org>, "Janifer Gatenby" <Janifer.Gatenby@pica.nl>, <rden@loc.gov>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 29 October 2009 06:12:22 GMT