I definitely think something is better than nothing, in this area, and
in many areas of bibliographic control.
In general, actual controlled data is always better than trying to guess
from unicode ranges and such. Unicode ranges can never be more than a
heuristic, the same unicode code points can and do appear in multiple
languages. (Isn't the chinese character set used for several languages,
for instance?). But yeah, without actual controlled structured data,
software will be reduced to attempting complicated heuristic best guesses.
Jonathan
Karen Coyle wrote:
> Jonathan, this was exactly the motivation behind the work we started
> on the authority file. We didn't get far enough to leave a useful
> legacy, unfortunately.
>
> There are two interesting and converging points in your post: 1) that
> it would be very important to know WHOSE authoritative form this is. I
> believe the VIAF is heading in this direction. (All of the
> "non-English" forms in the LCNA records are see references; by
> definition the LCNA preferred form is the one used in libraries whose
> language of cataloging is American English.) You could have more than
> one authoritative form in a given language, e.g. a British Library
> form and a Library of Congress form; 2) you want to know the language,
> because your user is likely to express herself in terms of language,
> not agencies and authoritative forms.
>
> Maybe if the VIAF gets far enough we can make use of the intersection
> between cataloging agency and language -- no, I already saw the flaw
> in that one (Archives Canada). Well, we'll keep thinking about it. It
> may end up being one of those "something is better than nothing"
> solutions.
>
> As for transliteration v. vernacular, I think that Unicode ranges help
> you out a lot with that. If we could get the vernacular into authority
> records, that would provide another clue.
>
> kc
>
> 2008/12/2 Jonathan Rochkind <[log in to unmask]>:
>
>> If you can assign languages to names in the authority file, it is VERY
>> useful to software.
>>
>> If my software knows a user prefers the Japanese language, and knows that
>> one of the names in the authority file is the preferred Japanese language
>> name, then my software can display it to the Japanese-preferring user.
>>
>> But if we have no idea what language "Touen, Makû" is, then my software
>> can't do much with it.
>>
>> Of course, if that IS a Japanese name, that is an example of one of the
>> problems. That might be romanized Japanese, but it's not Japanese
>> 'vernacular' (as we say), actual Japanese characters. Which I think could
>> theoretically be in an authority file too/instead.
>>
>> So it's not clear exactly how to label these. It definitely needs some work.
>> If it's too complicated for now, so it goes, but don't give up on it
>> forever, it's of immense value. Having all these alternate-language names of
>> authors and works but having no way for the software to have any idea
>> _which_ language significantly limits the utility of these listings.
>>
>> Jonathan
>>
>> Karen Coyle wrote:
>>
>>> I read through scenario 5 as well as I could (I didn't go through all
>>> of the code, of course.). I don't have many comments, but it did give
>>> me some ideas for some new scenarios to test out some things. See
>>> below.
>>>
>>> First, the comments:
>>> 1) the scenario lists "place of production" and "publisher". This
>>> may be music bibliography practice, but I would have expected "... of
>>> production" and "producer" or "of publication" and "publisher."
>>> 2) the scenario lists copyright date; I suspect this is being used
>>> as the date of publication in the bibliographic record, and therefore
>>> that field should be included in the scenario.
>>> 3) I found the order of the FRBR Group 1 statements backwards to how
>>> I think of them, e.g.:
>>> "ex:C frbr:embodiment ex:D"
>>> means that D is the embodiment of C. or perhaps C is embodied by D.
>>> How does one determine the direction? Is it clear in the
>>> registered FRBR relationships? (also, I'm assuming that we're using
>>> the group listed as "FRBR relationships as concepts" - right,
>>> Alistair?)
>>>
>>> 4) persons are getting coded with language indicators:
>>> ex:I rdf:type frbr:Person ;
>>> rdfs:label "Jerome Kessler"@en ;
>>>
>>> I've always thought it was very difficult to assign languages to
>>> names. Do we want to do this? There was a whole committee that was
>>> supposed to figure out languages for authority record fields (Diane,
>>> you and I were on that, weren't we?). It fell apart for various
>>> reasons, not the least of which that there may not be an answer. At
>>> the same time, the authority files are filled with language variations
>>> on names (e.g. "Touen, Makû" for Mark Twain (jp?)). I'm just not sure
>>> what to do about this, but it rang some bells for me.
>>> [Aside: when people want to assign languages to titles, etc., I always
>>> pull out my various examples: Book in English with title: "Marie
>>> Antoinette" - English or French? Same book in French. ? or my favorite
>>> bad restaurant name: "Pasta Cuisine" - Italian? French? or
>>> all-American?)
>>>
>>> As for new scenarios, here are three that I'm planning to add:
>>>
>>> 1. Manifestation that is part of a series; the catalog also has a
>>> record for the series.
>>> 2. Manifestation that is part of a series; the catalog does not have
>>> (and doesn't want to have) a record for the series
>>> 3. Manifestation that is an expression of a work, but there is no
>>> information about the work (I'll do one that is a translation of a
>>> work for which you have no catalog entry and no info)
>>>
>>> As an avowed non-cataloger, I will welcome appropriate modifications
>>> to my scenarios when I get them done.
>>> Thanks,
>>> kc
>>>
>>>
>>>
>> --
>> Jonathan Rochkind
>> Digital Services Software Engineer
>> The Sheridan Libraries
>> Johns Hopkins University
>> 410.516.8886 rochkind (at) jhu.edu
>>
>>
>
>
>
>
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
|
