 |
 |
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