 |
 |
On 7/11/12 2:19 AM, [log in to unmask] wrote: > On 22 June 2012 at 14:42 Karen Coyle <[log in to unmask]> wrote: > > <snip> >> >> (Just a few days ago I was with TomB in Florence and suggested a >> "macro-ISBD" that treats each ISBD area as a single string -- which is >> to my mind how ISBD treats the data. I will do a short email on that, >> perhaps.) >> > </snip> > > The draft ISBD AP [1] takes this approach, I think. The first set of statement > templates treat each ISBD area (0-8) as an aggregated statement with > corresponding SES. The components of each aggregated statement are (often) > themselves aggregated statements, and this can cascade for four or so levels of > aggregation. Gordon, So could those area SES's be used alone? Or are they the super-areas for the aggregated statements that follow? In my approach, the areas would be properties that take literal strings that are not treated as SES's. So I guess that's step above the area -> SES. I have to admit that I am unsure how the "parts" of an ISBD area can be implemented as an SES, and would like to see an example. I know that the ISBD AP relies heavily on the SES, but I don't understand where the SES is defined in an actionable way that meets the ISBD rules for order, etc. Perhaps that would be a good discussion for the next DCAM meeting. Along with Richard Urban, I can see the strictly structured SES of dates, and even the SES of DC BOX, but I can't make the leap to the coded strings of ISBD. The difference that I see is that dates and BOX are made up of (non-repeatable, if I am correct) parts that can be used in various combinations and orders, while ISBD is made up of repeatable parts whose order must be maintained in the creation order, and that latter is not algorithmically predictable. So I guess I need to see the rules that would govern such an SES. The examples that I gave in the notes were: London ; Chicago : Penguin, 2003 New York : Columbia University ; Boston : Computer Research Institute where the patterns are: place - place - publisher - date place - publisher - place - publisher - date and I also gave an example from MARC using names $a Black Foot, $c Chief, $d d. 1877 $c (Spirit) which is: name - title - date - title but here are some other examples: 100 10 |a Cayce, Edgar, |d 1877-1945 |c (Spirit) 100 0_ |a Sixtus |b V, |c Pope, |d 1520-1590 respectively: name - date - title name - enumeration - title - date In these you can see that the relative order between the name, the date and the title (spirit or pope) are not fixed, but depend on the context. (Note: the reason for this, of course, is that the library world has given two different semantics to the same data element, but unfortunately that occurs in various places in our data today.) kc > > > ISBD is generally concerned only with transcriptions of strings found on the > resource being described. The exception, newly introduced to the latest > consolidated edition, is the use of controlled vocabularies in area 0 (content > and media type); these are treated as VESs in the AP. Whether ISBD continues > this trend towards things rather than strings is a moot point. The primary > purpose of ISBD is to create whole records that can be exchanged between > national bibliographic agencies. The content of the record is intended to be > descriptive (strings, not things). ISBD does not address relationships between > the resource being described, or relationships with other entities such as > agents, places, etc. (things). The next revision of ISBD will take place in > around 3-4 years' time, and the ISBD Review Group is keen to hear arguments for > best practice, linked data, etc. to inform that revision. It should be noted, > however, that the I in ISBD needs to accommodate the needs of environments where > little or no machine processing is available. > > Cheers > > Gordon > > [1] http://wiki.dublincore.org/index.php/DCAM_Revision_Design_Patterns#ISBD_DSP > -- Karen Coyle [log in to unmask] http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet