On 2/12/13 9:43 AM, Jörg Prante wrote:The old procedure is not a
preferable solution for Bibframe because
>
> - the filing/sorting variants should no longer be required for being
> entered manually in a repetitive fashion, they should no longer be
> erroneous or incomplete
>
> - not every Bibframe package will come with all the variant texts
> needed for filing/sorting a document collection, raising the question
> what is taking precedence in case of conflicting or missing variants
I want to add another motivator to Jörg's excellent post:
- Bibframe data will interact with non-bibframe data that is unlikely to
use the same -- or even any -- method for marking non-filing portions.
kc
>
> - not every sorting/filing rule of all international contexts can be
> included, and if it could, there must be a method to distinguish
> between them all. It's also raising the question how Bibframe data
> should be merged when there are different filing/ordering rules for
> the same text.
>
> - and, maybe most important, there are other mechanisms for expressing
> filing/sorting rules that software engineers have invented since when
> filing/sorting indicators for MARC have been introduced ;-)
>
> I would like to extend the statements made in "Assessment of Options
> for Handling Full Unicode in Character Encodings in MARC 21"
> http://www.loc.gov/marc/marbi/2005/2005-report01.pdf
>
> For example, there is a suggestion "The bibliographic community needs
> to examine the Unicode components of normalization and collation and
> consider whether they can be adopted across scripts."
>
> In contrast to the "Assessment of Options for Handling Full Unicode in
> Character Encodings in MARC 21" where the functions
> "Indexing/Searching, Sorting, Record matching" (p. 7) are subsumed and
> assigned to the reponsibility of an individual institution, I think
> Bibframe should define at least a common sense of how to embrace
> Unicode sorting rules.
>
> My suggestions in the context of Bibframe are:
>
> - Bibframe should enable codes for filing/sorting rules. The Unicode
> consortium has made great efforts on dealing with a plethora of
> collation rules (either by collation keys or by rule based
> collations). See also http://cldr.unicode.org/ and
> http://cldr.unicode.org/index/cldr-spec/collation-guidelines for how
> to generate new collation rules.
>
> - Bibframe should provide links to the collation rule information from
> the text the cataloger wants to describe. It does not help much to add
> language information, sorting/nonsorting variants and other
> localization information at other places in the bibliographic
> description. For example, in RDF, literals can be encoded with a
> language tag, directly attached to the text. For Bibframe, special
> library catalog rule context tags could be appropriate, if language
> tags are not.
>
> - Bibframe should add internationalization also to filing/sorting rules
>
> - Bibframe should oblige to apply a default Unicode-based procedure to
> filing/sorting texts if there is missing or conflicting information
> about internationalization
>
> - computer systems that export/import Bibframe data should be able to
> apply filing/sorting rules automatically, recognizing the source and
> the target environment of the Bibframe transport
>
> The results of the Unicode consortium are also immediately available
> for software programming languages, thanks to projects like ICU
> http://site.icu-project.org/
>
> For example, there is a Unicode Collation Algorithm (UCA) that could
> be applied to combined bibliographic data originating from many
> international sources. Or, if that's not sufficient, another
> Unicode-based collation algorithm could be developed for Bibframe.
>
> Just as there are authority data sources for controlled vocabulary in
> library catalogs, there should be freely available authoritative
> resources for the filing/sorting rules that should apply to Bibframe
> texts in locally defined contexts and environments. My hope is, in the
> near future, library catalog users and software engineers, who are
> used to applications that use Unicode, will no longer get frustrated
> about library catalog data and the many methods of expressing
> filing/sorting.
>
> Best regards,
>
> Jörg
>
> Am 11.02.13 02:36, schrieb J. McRee Elrod:
>> I've noticed no discussion on Bibframe of filing indicators, nor
>> indication of such in posted examples. Did I miss it?
>>
>> There was a recent discussion on another list of titles which should
>> file under what appears to be an initial article, e.g, "A is for ...".
>>
>> How will this be handled in Bibframe? Initial articles differ between
>> languages, as well as "A", "An" and "The" being occasionally the word
>> by which to file. Programming to recognize this would be very
>> complex. I have seen no discussion concerning indication of language
>> in Bibframe, on which to base such programming.
>>
>> Are we to no longer have alphabetical browse lists, only web style
>> searching? I would miss alphabetical browse lists apart from subject
>> searches, which I prefer to have in inverse chronological order. That
>> too would be more difficult to program based on imprint date in the
>> absence of a date fixed field. The imprint date may even be lacking,
>> if that CONSER provision is carried over.
>>
>>
>> __ __ J. McRee (Mac) Elrod ([log in to unmask])
>> {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
>> ___} |__ \__________________________________________________________
--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
|