Here is an example of a VIAF work title I would like to have a solution
for. It is a common one used for evaluating the effect of cataloging
rules in german speaking countries: Franz Kafka, "Der Prozess" (see below).
<datafield tag="100" ind1="1" ind2=" ">
<subfield code="a">Kafka, Franz</subfield>
<subfield code="t">˜Derœ Prozess</subfield>
100 1 _ ‡a Kafka, Franz ‡d 1883-1924 ‡t Der Prozess
100 1 0 ‡a Kafka, Franz, ‡d 1883-1924. ‡t Prozess
100 1 ‡a Kafka, Franz, ‡d 1883-1924. ‡t Prozess. ‡l
100 1 0 ‡a Kafka, Franz ‡d 1883-1924 ‡t Der Prozess
Uniform Title Links (15)
DNB has established a gnd:preferredNameForTheWork element which carries
a '@' character for supporting filing positions (I can't find the
In the Marc21 record, DNB is using also a start/stop symbol pair to
point out the word "Der" is an exception and should not be considered
for filing/sorting. The codepoints are \u0098 (˜) and \u009c
(œ). An alternative would have been to mark this title with a
cataloging code ("RAK-WB" for example), but, as it is obvious to german
catalogs, the name of the cataloging code was just left out, it is not
explicitly stated. Also, Kafka's Prozess has been translated and renamed
into many languages, with different filing/sorting, outside of the scope
of the DNB catalog.
Now, what happens in VIAF? VIAF has no knowledge about filing/sorting
rules it seems. It uses SKOS concepts to create a mechanism to organize
work titles from many national authority libraries from many countries.
VIAF selected "Prozess" as uniform title, but also "Der Prozess". I
think it is the work set algorithm of OCLC how the uniform titles are
created, but I'm not sure. Biblioteca Nacional de España has submitted
"Der Prozess" to VIAF. This created also a conflict with the spanish LC
And, the german filing/sorting information disappeared. So, my
conclusion is, VIAF does not have a notion of maintaining local
filing/sorting information. As a programmer, I use DNB and not VIAF for
creating alphabetic catalogs for german audience.
From Bibframe, I hope it remedies this situation and allows that local
filing/sorting rules can be carried (if any rules exist, which can be
per title form, not per record).
An alternative to the start/stop symbols would be annotating the title
form with the cataloging code name that is responsible for
filing/sorting. That is, filing/sorting rules should be made identifiable.
With this semantics, it should be possible to reconstruct alphabetically
ordered catalogs for all audiences, the audience of the country the work
is originating from, and also for international audiences, who is not
interested in applying this information.
Moreover, with the Linked Data architecture, Bibframe is targeted to
carry much more title data from all kind of sources, not only data from
library (authority) catalogs. Yes, I dare to say, Bibframe should also
be able to carry title forms that were not created by library catalog
rules. For example, title of works from archives or museums, or from
academic research projects.
I think one good use case for Bibframe based applications would be to
identify the titles that need to get applied to certain local
filing/sorting rules. I hope Bibframe will have a method to respect the
original and the internationalized forms of a title. In the past, lots
of manual effort has been made to mark title forms according to local
For the audience who does not require filing/ordering rules, Bibframe
could allow implicitly to resolve this, maybe by stating a default rule,
that Unicode collation algorithm can safely be applied in such cases.
Am 16.02.13 07:03, schrieb Karen Coyle:
> Jeff, I've looked at VIAF. Many of us have looked at and used VIAF.
> And I must say that I am not entirely comfortable with the use of
> skos:concept for persons. This is why I would like more of an
> explication of the reasoning for using skos for things that are not
> concepts. Unless, perhaps, that the use of skos:concept in VIAF is
> something like the LC authorities designation of a name authority
> heading being usable ALSO for subjects. A bit more documentation about
> the decisions made in the development of VIAF would be very useful.
> The code itself doesn't provide those explanations, at least not to me.