koha-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Koha-devel] New KOHA3 API -design issue


From: Thomas Dukleth
Subject: RE: [Koha-devel] New KOHA3 API -design issue
Date: Thu, 20 Jul 2006 19:28:06 -0000 (GMT)
User-agent: SquirrelMail/1.4.7

On Mon, July 17, 2006 7:53 pm, Tümer Garip wrote:
> It has another column called "attr". There we can define what is the
> corresponding ZEBRA attribute to this virtual_field_name "title",
> "publisherid", "barcode" or whatever.

The appropriate table or other configuration location would seem to need
more than merely the designation of an attribute or attribute sequence
from the Bib-1 attribute set corresponding to the original Koha SQL
database columns if the goal is to avoid hard coding in Perl.  Sufficient
flexible generalisation of the Perl code would need at least one more
column in addition to a column for attributes.

There ought to be a column for the attribute set, without presuming Bib-1
is the attribute set for a given attribute sequence appearing in
koha_attr.attr.  We might presume Bib-1 to be the default attribute set
for some basic context but we know it may not be the exclusive attribute
set.

Bib-1 is not sufficient for every purpose.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY 10003
USA
http://www.agogme.com
212-674-3783


On Mon, July 17, 2006 7:53 pm, Tümer Garip wrote:

[snip]

>
> Regarding koha_attr table.
> Well i needed the old field names to exist somewhere so i can use them
> in our framework (marc_subfield_structure) designs to map 245$a to
> "title" 300$a "publisherid" etc. The old API got these names from the
> tables themselves (biblio,biblioitems,items,subject,additionalauthors).
> So I created a table with all the old field names in so that all the old
> templates and most of the code can work with <!--TMPL VAR
> NAME="title"--> notations.
> But to create a table just for this was unneccessary so I added extra
> functionality to it.
> It has another column called "attr". There we can define what is the
> corresponding ZEBRA attribute to this virtual_field_name "title",
> "publisherid", "barcode" or whatever.
> It has data like this:
> Koha field            ATTR                            LABEl
> SORT          SERVER
> itemnumber            @attr 1=1032            Item number
> No    itemserver
> classification        @attr 1=16                      LC classification
> No    biblioserver
> conference_name       @attr 1=3                       Conference name
> No    biblioserver
> copyrightdate         @attr 1=30 @attr 4=5    Copyright date           No
> biblioserver
>
> This table now provides me two more functionalities. (I am talking about
> the backend workings by the way not front end searching). While we
> evolve ZEBRA functionality we are all using different search attributes
> for our fields. Such as you are using Identifier-standard (@attr 1=1007)
> for you biblionumber I am using Number-db (@attr 1=52). Even at one
> stage we all use the same attributes for indexing in time people will
> want to add more or change their indexing attributes. This table is
> Sysytme admin editable. So within KOHA API I still call
> biblionumber=some number and do not use any @attr notation at all. The
> code is free of Bib-1 or GILS or KOHA designed attributes.
>

[snip]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]