(pseudo)authorities: what is supported in Invenio/Inspire?
Good morning to all, In order to be able to plan ahead in my installation, I would like to know if there is any way to deal with authorities in Invenio. The BibAuthority module (described in detail here: https://twiki.cern.ch/twiki/bin/view/CDS/BibAuthority) is EXACLY what i would like to have, but i cannot find it in my installation nor in the invenio/inspire repo. Was the module abandoned/postponed/replaced by something even better? On the other hand, inspirehep.net seems to have such functionality (HepNames, Institutions, Conferences) seem to be 'authority' records that are considered when performing a search. Could you please shed a light on what's being available now and what's planned for the near future? Best regards, Theodoropoulos Theodoros ps. I apologize for sending a similar mail in the past too. It's quite urgent that i know at least some general information and the best practices for the current/next Invenio version in order to make the right decisions for my next milestone. I'll do the reading/implementation/testing myself.
Re: (pseudo)authorities: what is supported in Invenio/Inspire?
On 30.11.2012 11:09, Theodoros Theodoropoulos wrote: Hi! In order to be able to plan ahead in my installation, I would like to know if there is any way to deal with authorities in Invenio. The BibAuthority module (described in detail here: https://twiki.cern.ch/twiki/bin/view/CDS/BibAuthority) is EXACLY what i would like to have, but i cannot find it in my installation nor in the invenio/inspire repo. Was the module abandoned/postponed/replaced by something even better? We currently use some sort of authority control in JuSER where we mainly implemented the functionality within websubmit type of things. This however does not (yet?) use bibauthority. Unfortunately, the searchengine does not yet know about authorities. If we can be of some help here, drop me a note. You can check out what we did at http://juser.fz-juelich.de/ in the Authorities-collections. You might also want to check out the Marc we used. E.g. for an institute http://juser.fz-juelich.de/record/98380 You may use the arrow links to go to predecessors, successors or top. On the other hand, inspirehep.net seems to have such functionality (HepNames, Institutions, Conferences) seem to be 'authority' records that are considered when performing a search. We would definitely also want to know how they can be used within search. I mean not simple stuff like searching for an ID, we have this already but searching for an ID x and find all records for ID x and y as the authority record of x list's y as addional identifier. We work around our current limitations e.g. using the index cid (contributing institutes also gathering all former forms of the institute) but this is not really done in a nice way. Bascially a record here just has enough collection entires, but it's no real authority lookup. ps. I apologize for sending a similar mail in the past too. It's quite urgent that i know at least some general information and the best practices for the current/next Invenio version in order to make the right decisions for my next milestone. I'll do the reading/implementation/testing myself. When we started to implement this stuff I checked closely with Annette Holtkamp, so I think we should indeed use the same or at least a very similar authority record layout as Inspire. HTH :) -- Kind regards, Alexander Wagner Subject Specialist Central Library 52425 Juelich mail : a.wag...@fz-juelich.de 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
Re: (pseudo)authorities: what is supported in Invenio/Inspire?
Hello Alexander, It's been a while since we talked at the last Invenio Users Meeting, but i'm following the list and I've seen the great work you've done at Juelich. We currently use some sort of authority control in JuSER where we mainly implemented the functionality within websubmit type of things. This however does not (yet?) use bibauthority. Unfortunately, the searchengine does not yet know about authorities. If we can be of some help here, drop me a note. I'm too using a way to correctly SELECT a user (with all proper IDs, affiliations, etc) from a list in websubmit part. However, the values are copied to 100/700__0,a,e,u bib record fields. This ensures consistency across records, but it's really a plan-b solution -but the only way to do things because authorities are not(?) supported. Plus, I think that there is no easy way to use this data in BibEdit: one could select from a list of authors in 100/700__a, but i'm not sure that this selection could update other subfields of 100/700 accordingly. Ideally, with authorities, in the bib record, only the 'reference' to the authority would be used, so that if anything changes in the author, all the 'connected' records will know the change, plus you get see/see also fields, alternate/translated names support etc. That would also involve indexing and searching, and this is described nicely, here http://twiki.cern.ch/twiki/bin/view/CDS/BibAuthority You can check out what we did at http://juser.fz-juelich.de/ in the Authorities-collections. You might also want to check out the Marc we used. E.g. for an institute http://juser.fz-juelich.de/record/98380 You may use the arrow links to go to predecessors, successors or top. You seem to have it nicely ordered. I'm currently interested mostly on authors, but Institutions will come next. I'll check your marc to get an idea of what you've used. Thanks again for sharing your work! We would definitely also want to know how they can be used within search. I mean not simple stuff like searching for an ID, we have this already but searching for an ID x and find all records for ID x and y as the authority record of x list's y as addional identifier. We work around our current limitations e.g. using the index cid (contributing institutes also gathering all former forms of the institute) but this is not really done in a nice way. Bascially a record here just has enough collection entires, but it's no real authority lookup. Exactly! When we started to implement this stuff I checked closely with Annette Holtkamp, so I think we should indeed use the same or at least a very similar authority record layout as Inspire. Hmm.. I didn't go yet too much into Inspire's (pseudo?)authority marc, but will do soon. I also believe that we should always try to use common fields when possible, keeping always in mind the marc standards. Having said that, I am mostly interested in more fundamental issues: - (Is/was/will there be) support for authorities soon -indexing/searching/bibedit support included- and what can i do now to be ready? - Is the final module going to be something similar to what's being described in that wiki page? - Is it planned for 1.2 1.x or 2.x series? My best regards to all, Theodoros
Re: (pseudo)authorities: what is supported in Invenio/Inspire?
On 30.11.2012 15:41, Theodoros Theodoropoulos wrote: Hi! It's been a while since we talked at the last Invenio Users Meeting, but i'm following the list and I've seen the great work you've done at Juelich. I admit that I had been a bit busy recently. We currently use some sort of authority control in JuSER where we mainly implemented the functionality within websubmit type of things. This however does not (yet?) use bibauthority. Unfortunately, the searchengine does not yet know about authorities. If we can be of some help here, drop me a note. I'm too using a way to correctly SELECT a user (with all proper IDs, affiliations, etc) from a list in websubmit part. However, the values are copied to 100/700__0,a,e,u bib record fields. Sure. This ensures consistency across records, but it's really a plan-b solution -but the only way to do things because authorities are not(?) supported. Well, it's also Marc philosophy in a way. They usually store everything within the datasets all the time. But you're right, in principle one could just generate one record for the authority and get the values on the fly. However, this is a bit more in league with e.g. our german cataloguing system and not so much with Marc. Plus, I think that there is no easy way to use this data in BibEdit: one could select from a list of authors in 100/700__a, but i'm not sure that this selection could update other subfields of 100/700 accordingly. You're right again, at the moment bibedit is a bit pita if you have authority controled data. However, there was some work done by Christpher in this direction. And I admit, that I could in a way live with bibedit to be a bit cumbersome (for bibedit I have a librarian to handle it, they usally work quite precisely etc.) but what's really a bit bad is that I can't use authority control in the search. Consider an author with an ID like P:(DE-Juel1)123456, ie. one of our IDs. Now I know that he also has an ORCID of -1234-5678-9123. I store this in my authority record and we could even use the ORCID for input or even if fed by data import to identify our author. All is well as long as we catalogue the dataset: we search for the orcid and store our own ID in $0. However, things break as soon as I get foreign data. Those sets probably store the ORCID only and don't know a thing about our own ID. Now, in searches it would of course be nice if I search for P:(DE-Juel1)123456 that I also get all those records that match the ORCID of this author as well. Ideally, with authorities, in the bib record, only the 'reference' to the authority would be used, so that if anything changes in the author, all the 'connected' records will know the change, plus you get see/see also fields, alternate/translated names support etc. Right. Not exactly Marc philosophy, but this is indeed authority control as it should be. Except one point, that it might very well be that you store Wagner, A. in your record referencing Wagner, Alexander and for some reason you want to preserve exactly the form as written on the document. This would make a point for storing $a as well. (Similar for $e, $u.) That would also involve indexing and searching, and this is described nicely, here http://twiki.cern.ch/twiki/bin/view/CDS/BibAuthority This is mainly what Christopher did, I think. We discussed that stuff while ago. You can check out what we did at http://juser.fz-juelich.de/ in the Authorities-collections. You might also want to check out the Marc we used. E.g. for an institute http://juser.fz-juelich.de/record/98380 You may use the arrow links to go to predecessors, successors or top. You seem to have it nicely ordered. I'm currently interested mostly on authors, but Institutions will come next. I'll check your marc to get an idea of what you've used. Thanks again for sharing your work! And you'll probably want to have research grants, and periodicals as well. I admit that currently journals in Invenio are modeled a bit too closly to a very small community. At Jülich we couldn't handle journals by static lists of abbreviations, I fear. When we started to implement this stuff I checked closely with Annette Holtkamp, so I think we should indeed use the same or at least a very similar authority record layout as Inspire. Hmm.. I didn't go yet too much into Inspire's (pseudo?)authority marc, but will do soon. I also believe that we should always try to use common fields when possible, keeping always in mind the marc standards. As mentioned, I checked with Annette back then and if Inspire didn't make changes to the records I were not aware we should be quite well on the same lines here. Having said that, I am mostly interested in more fundamental issues: - (Is/was/will there be) support for authorities soon -indexing/searching/bibedit support included- and what can i do now to be ready? - Is the final module going to be something similar to what's being described in that wiki page? I strongly hope
