Hi, I found a solution by adding new logical fields in BibIndex, this is since the library database structure am dealing with has lots of fields whose marc values exceed the standard codes. But of course I'm sticking to Marc as defined at LoC as much as possible.
Thanks, On Tue, Jul 9, 2013 at 9:27 AM, Alexander Wagner <[email protected]>wrote: > On 08.07.2013 21:35, Maungu Oware wrote: > > Hi! > > Is there a way to label marc codes in Invenio so that the field names >> are displayed instead of marc codes in human view in the record editor ? >> I realize that human view helps for the standard marc codes but what if >> there are custom codes existing, e.g I use *250__a* to denote the >> *continent* a publication originated from. It would help if users saw >> >> continent instead of 250__a in the record editor. >> > > Besides that it might be indeed interesting to learn how to configure > the record editor some point that might be helpful for you here. > > If you're using FireFox you probably might want to add a bookmark like > this: > > Name : m: MARC 21 Field Description > URL : http://www.loc.gov/marc/**bibliographic/bd%s.html > Keyword: m > > This allows you to just type > > m 250 > > in your URL bar to get the definition of Marc 250. > > For Authority definitions one might use > > Name : ad: MARC 21 Authority Field Description > URL : http://www.loc.gov/marc/**authority/ad%s.html > Keyword: ad > > Having used m 250 as above shows you that Marc 250 a might /not/ be a > good idea to store the originating continent. Simply cause it has a > defined meaning in Marc, being the edition statement. (Ie. something > like "2nd enlarged edition". Think of exporting your data to whatever > format you'd always need to take care of your "house rule" for this. > E.g. 250__a would go to bibtex edition and also be exposed to some > Dublin Core.) You might run into trouble if you "missuse" predefined > fields, especially if, at any point of your project, you want to > interchange data, but also if you want to make them visible to others. I > think that's what it's all about ;) > > Thus I'd strongly suggest to stick to Marc as defined at LoC as much as > possible. So 260__e might be a better place for your information, though > it is meant for the city, I wouldn't missuse it eiter. (Except you with > something like "Berlin, Germany, Europe" though I think this is not nice > at all.) > > In your mentioned case I see some ways to handle this in a bit a cleaner > way. > > - Marc 751: "Added Entry-Geographic Name". If I check the fields > description some coding like $a for the continent, $e for the > "relationship of geographic name and described item" sounds almost to > the point of what you want to describe here. I'd opt for a $0/$2 like > describe in the next paragraph. E.g. > > 751__$a Africa > $e Publishing Continent > $0 COP:(YourOrg)12345 > $2 ContinetOfProdcution > > (Even gives nice simple output formatting for this.) > > - General keywording (similar to the just mentioned), in your case > something like Marc 653. If you check out it is "Subject Added > Entry-Geographic Name" which sounds good, however does not reflect on > "production continent of the entry". Therefore, I'd use it in > conjunction with the second indicator 7. E.g. like > > 653_7 $2ContinetOfProdcution $aAfrica $0 COP:(YourOrg)12345 > > defining a vocabulary "ContinentOfProduction" (a better name would be > good) a literal meaning in $a, and, as names are usually a difficult > entity, I'd go with an identfier in $0 and also some authority record. > > We have a similar usecase for our grants hierarchy (e.g. > http://juser.fz-juelich.de/**record/92363<http://juser.fz-juelich.de/record/92363>and > one of the vocabulary > authority records > http://juser.fz-juelich.de/**record/92148<http://juser.fz-juelich.de/record/92148> > ) > > BTW: keywording is a quite general and clean excuse to add data to a > record for searching and display that doesn't fit into Marc otherwise. > Especially in conjunction with the _7 indicators it allows for almost > all your needs as ther're specific fields for Subject, People, Geography > and so on. cf. > http://www.loc.gov/marc/**bibliographic/bd6xx.html<http://www.loc.gov/marc/bibliographic/bd6xx.html> > > In case of emergency you could even opt for 69x, but I'd do that only if > I have a very good reason not to put it otherwise. "Local usage" usually > means: not interachangeable easily (simply cause another instance doen't > know about it automatically). > > - Collections, ie. 980__a which is a bit more the "invenio way". Though > I'd be a bit careful to define too many of those guys, as your webcoll > will take it's time. (Having some 400 on JuSER I can tell ;) > > - If all else breaks: custom extensions. In Marc they live in 9xx fields. > > HTH :) > > -- > > Kind regards, > > Alexander Wagner > Subject Specialist > Central Library > 52425 Juelich > > mail : [email protected] > phone: +49 2461 61-1586 > Fax : +49 2461 61-6103 > www.fz-juelich.de/zb/DE/zb-fi > > > ------------------------------**------------------------------** > ------------------------------**------ > ------------------------------**------------------------------** > ------------------------------**------ > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > ------------------------------**------------------------------** > ------------------------------**------ > ------------------------------**------------------------------** > ------------------------------**------ > > Das Forschungszentrum oeffnet seine Tueren am Sonntag, 29. September, von > 10:00 bis 17:00 Uhr: http://www.tagderneugier.de > -- Maungu Oware
