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
|