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 10:52:05 UTC