As far as I can tell, call number handling is generally broken in 3.0, with no realy standard for how to display call numbers. Some templates use <!--TMPL_VAR NAME="itemcallnumber" -->, some use <!--TMPL_VAR NAME="classification" -->, some use <!-- TMPL_VAR name="dewey" -->. Which is correct, or is there a better way to handle call numbers in a more generalized way? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Yeah, we cant use these variables in the templates, as what is in them is controlled by sysprefs, ie itemcallnumber is going to be empty unless people are using item level callnumbers Its a tricky one as Nicole says, some libraries use dewey and LC .. so we need to display both. Chris On 2/26/08, Owen Leonard <oleonard@myacpl.org> wrote:
As far as I can tell, call number handling is generally broken in 3.0, with no realy standard for how to display call numbers. Some templates use <!--TMPL_VAR NAME="itemcallnumber" -->, some use <!--TMPL_VAR NAME="classification" -->, some use <!-- TMPL_VAR name="dewey" -->.
Which is correct, or is there a better way to handle call numbers in a more generalized way?
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
Yeah, we cant use these variables in the templates, as what is in them is controlled by sysprefs, ie itemcallnumber is going to be empty unless people are using item level callnumbers item-level callnumbers are really the only valid type of callnumber, since callnumber refers to shelf location and bibs don't have shelf location. There's a separate concept of 'classification' that can appear at the bib level, but it's really not used very much in
On 2/25/08, Chris Cormack <chris@bigballofwax.co.nz> wrote: practice in libraries, other than as a reference point. Shelf browse lists, etc., are generated from the item-level itemcallnumber, which should always be populated for every item.
Its a tricky one as Nicole says, some libraries use dewey and LC .. so we need to display both. The fields dewey and classification don't exist anymore, we now have:
itemcallnumber (combined full call number at the item level) and we have cn_source and cn_sort (for sorting rules based on the cn_source value as defined in Administration->Classification Filing Rules) At the bib level we have biblioitems: cn_source cn_class cn_item cn_suffix cn_sort dewey and classification no longer exist and should be replaced at the bib level with a concatenation of cn_item . cn_item . cn_suffix and at the item level with itemcallnumber. Please see the following reference: http://wiki.koha.org/doku.php?id=en:development:callnumbers Hope that helps. -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Chris
On 2/26/08, Owen Leonard <oleonard@myacpl.org> wrote:
As far as I can tell, call number handling is generally broken in 3.0, with no realy standard for how to display call numbers. Some templates use <!--TMPL_VAR NAME="itemcallnumber" -->, some use <!--TMPL_VAR NAME="classification" -->, some use <!-- TMPL_VAR name="dewey" -->.
Which is correct, or is there a better way to handle call numbers in a more generalized way?
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
On 2/26/08, Joshua Ferraro <jmf@liblime.com> wrote:
Yeah, we cant use these variables in the templates, as what is in them is controlled by sysprefs, ie itemcallnumber is going to be empty unless
On 2/25/08, Chris Cormack <chris@bigballofwax.co.nz> wrote: people
are using item level callnumbers
item-level callnumbers are really the only valid type of callnumber, since callnumber refers to shelf location and bibs don't have shelf location. There's a separate concept of 'classification' that can appear at the bib level, but it's really not used very much in practice in libraries, other than as a reference point. Shelf browse lists, etc., are generated from the item-level itemcallnumber, which should always be populated for every item.
Ahh yes I keep forgetting that we have completely killed the biblioitem level. And are back at 2 tiers. Chris
On Tue, Feb 26, 2008 at 12:10 AM, Joshua Ferraro <jmf@liblime.com> wrote:
Yeah, we cant use these variables in the templates, as what is in them is controlled by sysprefs, ie itemcallnumber is going to be empty unless people are using item level callnumbers item-level callnumbers are really the only valid type of callnumber, since callnumber refers to shelf location and bibs don't have shelf location. There's a separate concept of 'classification' that can appear at the bib level, but it's really not used very much in
On 2/25/08, Chris Cormack <chris@bigballofwax.co.nz> wrote: practice in libraries, other than as a reference point. Shelf browse lists, etc., are generated from the item-level itemcallnumber, which should always be populated for every item.
Its a tricky one as Nicole says, some libraries use dewey and LC .. so we need to display both. The fields dewey and classification don't exist anymore, we now have:
itemcallnumber (combined full call number at the item level) and we have cn_source and cn_sort (for sorting rules based on the cn_source value as defined in Administration->Classification Filing Rules)
In light of this, I have removed the 'Dewey' field from the Label Layout screen. Regards, Chris -- Chris Nighswonger Faculty Member Network & Systems Director Foundations Bible College & Seminary www.foundations.edu www.fbcradio.org
Shelf browse lists, etc., are generated from the item-level itemcallnumber, which should always be populated for every item.
This is not the case in the sample data I have. This is sure to cause confusion for beta-testers.
dewey and classification no longer exist and should be replaced at the bib level with a concatenation of cn_item . cn_item . cn_suffix and at the item level with itemcallnumber.
How to handle this on the OPAC search results screen? If I replace 'classification' with 'itemcallnumber' I get a concatenation of call numbers for that record's items: PZ7.S2744 Bi | PZ7.S2744 Bi | PZ7.S2744 Bi Unfortunately, this is also wrapped in a call number search link: opac-search.pl?q=callnum:PZ7.S2744%20Bi%20%7C%20PZ7.S2744%20Bi%20%7C%20PZ7.S2744%20Bi In this case should we be displaying cn_item . cn_item . cn_suffix? Without additional context for those three identical call numbers, it's pretty nonsensical. The alternative is to switch to the more verbose style of the staff client's search results. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
For search results, I suggest a list of libraries with holdings, and hidden divs that list the call numbers and item availability for a given library. If 'SearchMyLibraryFirst' or independentBranches is ON , then the user's home library's specific holdings are shown by default, and you click other library names to display the holdings for that library. Otherwise, the library name is followed by a parenthetical summary, e.g. LibraryName (2/5 available). Ryan On 2/26/08, Owen Leonard <oleonard@myacpl.org> wrote:
Shelf browse lists, etc., are generated from the item-level itemcallnumber, which should always be populated for every item.
This is not the case in the sample data I have. This is sure to cause confusion for beta-testers.
dewey and classification no longer exist and should be replaced at the bib level with a concatenation of cn_item . cn_item . cn_suffix and at the item level with itemcallnumber.
How to handle this on the OPAC search results screen? If I replace 'classification' with 'itemcallnumber' I get a concatenation of call numbers for that record's items:
PZ7.S2744 Bi | PZ7.S2744 Bi | PZ7.S2744 Bi
Unfortunately, this is also wrapped in a call number search link:
opac-search.pl?q=callnum: PZ7.S2744%20Bi%20%7C%20PZ7.S2744%20Bi%20%7C%20PZ7.S2744%20Bi
In this case should we be displaying cn_item . cn_item . cn_suffix? Without additional context for those three identical call numbers, it's pretty nonsensical. The alternative is to switch to the more verbose style of the staff client's search results.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
-- Ryan Higgins LibLime * Open-Source Solutions for Libraries Featuring KohaZOOM ILS 888-564-2457 x704
item-level callnumbers are really the only valid type of callnumber, since callnumber refers to shelf location and bibs don't have shelf location. There's a separate concept of 'classification' that can appear at the bib level, but it's really not used very much in practice in libraries, other than as a reference point. Shelf browse lists, etc., are generated from the item-level itemcallnumber, which should always be populated for every item.
Now take the example of Lists in the OPAC: When you open a list for viewing, you're looking at a list of titles. If call numbers are only relevant at the item level, then does it make sense to simply leave out call number information from the display of Lists? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Ryan's answer seems apt for searches. To answer Owen's question specifically about Lists a.k.a. Shelves, in my recent patches (that should be pushed up now), I have actually done as Owen suggests and replaced the "Call Number" column with other more relevant data. Call numbers wouldn't necessarily make sense anyway for items across different libraries, anyway. --Joe Atzberger On Tue, Feb 26, 2008 at 5:55 AM, Owen Leonard <oleonard@myacpl.org> wrote:
item-level callnumbers are really the only valid type of callnumber, since callnumber refers to shelf location and bibs don't have shelf location. There's a separate concept of 'classification' that can appear at the bib level, but it's really not used very much in practice in libraries, other than as a reference point. Shelf browse lists, etc., are generated from the item-level itemcallnumber, which should always be populated for every item.
Now take the example of Lists in the OPAC: When you open a list for viewing, you're looking at a list of titles. If call numbers are only relevant at the item level, then does it make sense to simply leave out call number information from the display of Lists?
-- Owen
Web Developer Athens County Public Libraries http://www.myacpl.org
participants (6)
-
Chris Cormack -
Chris Nighswonger -
Joe Atzberger -
Joshua Ferraro -
Owen Leonard -
Ryan Higgins