Separating MARC Framework Structure from Display
Colleagues and Friends, I've been doing a training for a library in Maine, and working with their cataloguers has got me thinking a lot about the MARC Frameworks. Right now, our Frameworks are doing two jobs: defining what MARC means, and determining how that information will display in the editor and MARC views. It seems to me that we may benefit from separating these two functions more thoroughly. Doing so would allow us to have one or two framework structures per MARC flavour, but as many displays as we like. I'm thinking of the further future of Koha where we support more than just MARC (like native DC, MOD, METS or EAD data), and having the semantics and display separated is more critical (so we can provide a common display layer to all those formats) To that end, I'd recommend some changes to how the display information is handled in the GUI. First off, having 'basic' constraints and 'advanced' constraints (hidden by JQuery) should be eliminated in favour of a semantic section and a display section. Secondly, the 'hidden' value should no longer be an integer (at least in the GUI), but a dropdown, or series of dropdowns, laying out in plain text under what conditions you're hiding the value. Does this make sense to others, or am I writing too late into the evening? Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
2011/2/23 Ian Walls <ian.walls@bywatersolutions.com>
To that end, I'd recommend some changes to how the display information is handled in the GUI. First off, having 'basic' constraints and 'advanced' constraints (hidden by JQuery) should be eliminated in favour of a semantic section and a display section. Secondly, the 'hidden' value should no longer be an integer (at least in the GUI), but a dropdown, or series of dropdowns, laying out in plain text under what conditions you're hiding the value.
I've had this conversation with Ian many times and I usually throw in that I'd go a step further and say that cataloging shouldn't be dependent on Frameworks at all! We should have the option to use a Framework if we want one, but for us professional catalogers we want freedom to add and remove fields as we see fit - while cataloging - not before we start cataloging. I'd like to see a blank cataloging form that I can tab through and add fields and subfields as needed. If I'm understanding right, the first step in this process would be to make the changes Ian is suggesting and then we can move forward from there.
Does this make sense to others, or am I writing too late into the evening?
Makes sense to me - but like I said I've heard it all before :) Thanks Nicole
I very much agree with Nicole on this one. One of my problems with the frameworks in our institutions is that while it is true that visual materials, books, serials, and manuscripts can use different frameworks, it would be very helpful to be able to add/remove fields and subfields as needed while cataloging. On 2/24/2011 6:13 AM, Nicole Engard wrote:
2011/2/23 Ian Walls <ian.walls@bywatersolutions.com <mailto:ian.walls@bywatersolutions.com>>
To that end, I'd recommend some changes to how the display information is handled in the GUI. Â First off, having 'basic' constraints and 'advanced' constraints (hidden by JQuery) should be eliminated in favour of a semantic section and a display section. Â Secondly, the 'hidden' value should no longer be an integer (at least in the GUI), but a dropdown, or series of dropdowns, laying out in plain text under what conditions you're hiding the value.
I've had this conversation with Ian many times and I usually throw in that I'd go a step further and say that cataloging shouldn't be dependent on Frameworks at all! We should have the option to use a Framework if we want one, but for us professional catalogers we want freedom to add and remove fields as we see fit - while cataloging - not before we start cataloging. I'd like to see a blank cataloging form that I can tab through and add fields and subfields as needed. If I'm understanding right, the first step in this process would be to make the changes Ian is suggesting and then we can move forward from there.
Does this make sense to others, or am I writing too late into the evening? Â
Makes sense to me - but like I said I've heard it all before :)
Thanks Nicole
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Linda Culberson lculber@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824
participants (3)
-
Ian Walls -
Linda Culberson -
Nicole Engard