Time  Nick          Message
11:58 thd           hdl: http://library.neu.edu.tr/kohanamespace/koharecord.xsd
11:57 thd           hdl: his XML schema enclosing MARCXML is also easy to follow.
11:55 thd           hdl: http://library.neu.edu.tr/kohanamespace/koha2index.xsl
11:55 thd           hdl: however tumer's xsl index files are easy to follow.
11:53 thd           hdl: as usual, the Zebra documentation is less detailed than might be helpful.
11:52 thd           hdl: there is no new Zebra 2.0 manual in PDF format, the HTML documentation has been updated for the new features.
11:46 thd           hdl: tumer has it working but he has promised everyone not to commit his changes for Koha 3.2 to HEAD until you have synchronised HEAD with Koha 2.4 and 3.0.
11:45 hdl           But considering moving to ubuntu for some machines some day
11:44 hdl           still.
11:43 thd           hdl: Do you usually use Mandreva?
11:42 thd           hdl: if you use Debian you can have both Zebra 1.3 and 2.0 simultaneously on the same system with a separately versioned name space.
11:40 thd           hdl: it is considered beta.
11:39 thd           hdl: Also searching is much faster than joining indexes would be in SQL.
11:39 hdl           It crashes my old zebra base.
11:38 hdl           I just installed zebra2.0
11:38 hdl           ok.
11:37 thd           hdl: therefore if all the information needed for indexing is in one meta-record the lack of index joining in Zebra is overcome.
11:36 thd           hdl: the one thing that Zebra will not do without giving too much money to Index Data is that you cannot join indexes for different records on a common key of linking number and record number.
11:35 thd           hdl: so if you add some record type to a distinctive XPath you can have distinctive indexing.
11:34 thd           hdl: XPath statements describe how indexing is done.
11:33 thd           hdl: XSL can contain indexing data that would otherwise have been in *.abs and other related files.
11:31 thd           hdl: in Zebra 2.0 indexing files can themselves be XSL for indexing XML.
11:30 thd           hdl: yet you have to provide indexing files which describe the structure
11:29 hdl           But it seems that when you import things in zebra using a peculiar structure, it recognizes the structure and stores it somewhere.
11:29 thd           hdl: UNIMARC does not even store encoding in a consistent place in 100.
11:28 thd           hdl: that is an indexation problem for example UNIMARC has different positions for 100 depending upon the type of record.
11:28 hdl           thd: I don't know precisely how it works.
11:28 hdl           thd : you're rigth for the latter problem.
11:27 thd           hdl: how does the framework identify which are which?
11:27 hdl           Anyway, zebra is already distingishing them throug the "framework you get them from.
11:27 thd           yet it is real
11:26 thd           hdl: overlap of field numbers with competing meanings is small for a given syntax, MARC 21, UNIMARC, etc.
11:26 thd           hdl: there is the further problem that the same field number of a different type has a different meaning
11:24 thd           leader position 06 distinguishes record type
11:24 thd           s/000\/09/000\/06/
11:23 thd           hdl: however, since 000/09 has multiple values for one basic type bibliographic, authorities, holdings, etc. all have subtypes with different letters using 000/06 is not efficient.
11:21 thd           hdl: yes we could already put them in the same database and distinguish them by 000/09
11:19 thd           hdl: meta-records could have a place for storing authority records related to the biblios.
11:18 hdl           Will we have USMARC and USMARC-A in the same database ?
11:18 hdl           Is it through the frameworks ?
11:17 hdl           Is it needed ?
11:17 hdl           How can you manage to get along heading forms and rejected forms in biblios ?
11:16 thd           if you add related authorities to a biblio meta-record
11:15 thd           hdl: yes
11:15 hdl           Are you telling me that if you search for unused form, you will find them in biblios database ?
11:15 thd           hdl: the lazy user who did not know any of the authorised forms could have a faster search.
11:14 thd           hdl: not that we actually do that we build the query in advance by finding needed authorised forms as separate searches to use in the query.
11:14 thd           hdl: presently, in SQL we could simply join indexes to search using the non-authorised forms for authorities held at a given branch or for two non-authorised forms without choosing them individually before the query is run.
11:11 thd           hdl: authorities could still be stored separately as the primary non-duplicated authority repository which functions as it does now.
11:09 thd           hdl: if you store authorities with the biblios to which they are related you can have much more efficient retrieval and better search possibilities using authorities.
11:08 thd           hdl: I saw duplication starting with better indexing for authority records.
11:07 thd           hdl: if matching bibliographic records for the same material were actually perfectly identical only one would be needed so still no duplication.
11:06 thd           hdl: then both duplicate MARC records for the same material that were not necessarily identical records could be stored in the same meta-record biblio.
11:05 thd           hdl: double storing would only start to come in for the case of what tumer has already done if one combined the holdings of multiple institutions which had multiple MARC records for the same manifestation of a work.
11:03 thd           as separate records have more easily describable separate XPaths.
11:01 thd           hdl: using separate records makes the indexation of multiple holdings easier with XPath than merely repeating the holdings field in a bibliographic record.
11:00 thd           hdl: a holdings record could be a bibliographic record with a linking field and field 995.
10:59 thd           hdl: what tumer has working already is indexing on a bibliographic record and multiple attached holdings records.
10:57 thd           hdl: the collection provides the possibility of containing more than one record.
10:56 thd           hdl: collection is actually used as the top level tag for a single MARCXML record in the MARCXML schema.
10:55 thd           hdl: I thought I understood that he would be building a Turkish union catalogue but I may have been mistaken
10:54 thd           hdl: I am not perfectly clear how tumer intends to use collections.
10:54 hdl           Am I wrong ?
10:54 thd           hdl: I am afraid that is unavoidable with Zebra indexing limits once you want to index authorities as well as bibliographic records.
10:53 hdl           When updating biblio level, you will update collections.
10:52 thd           hdl: I expect to not to have the best meta-record design at the first attempt.
10:52 hdl           thd : so then, you will double store information if I understand clearly.
10:51 thd           hdl: The structure would not be really absolute because it can be altered by changing the XPaths used in indexation.
10:50 thd           hdl: much effort would be required for filling some possible meta-record relationships.
10:49 thd           hdl: The idea initially would be to have an added platform for experimentation to get the scripts for filling meta-records right but as part of a working system.
10:48 thd           hdl: so the system should be fully functional without whatever advantages meta-records may provide beyond the basic functionality that Koha already has.
10:46 thd           hdl: the only need for them is to overcome indexation limitations
10:46 thd           hdl: meta-records, when populated would provide additional indexation
10:45 thd           hdl: the system should be able to function fairly much as it does now even if the meta-records are mostly unpopulated.
10:44 thd           hdl: well only one record would be modified and then the modifications would propagate at various rates to accommodate either real time or batch performance
10:43 hdl           and also VERY strictly structured.
10:43 hdl           Provided that things are SURE and well coded.
10:43 hdl           Obviously, this will increase speed and security...
10:42 hdl           thd: It was not that but the fact that instead of modifying one MARC record at a time, we should modify four and four database.
10:42 thd           hdl: additional coding effort would need to take advantage of meta-records so that they were filled with the correct standard records and indexed properly with XPath.
10:40 thd           hdl: so no additional frameworks would be required for displaying and editing records
10:39 thd           hdl: the system silently fills the meta-records in the background using information contained in the standard records
10:38 thd           hdl: the user or librarian only ever sees the real individual records
10:37 thd           hdl: meta-records as tumer had conceived them are mere containers for standard records
10:37 thd           hdl: yesterday you seemed to have left with the thought that meta-records would be edited directly by the librarian
10:36 hdl           yes
10:36 thd           hdl: are you still there?
10:35 thd           hello hdl
08:29 hdl           oops.
08:29 hdl           thd: is that pines
08:28 hdl           hi thd
05:21 thd           hdl: are you there?
03:40 OrangeWindies hello, anyone online?
13:33 thd           owen: they have no scheme for approval slips or searching by LCSH, LCC, or DDC
13:31 thd           on Amazon
13:31 thd           owen: approval slips and their search system in general uses book trade data not library records for finding what you want to order
13:30 thd           owen: I know Amazon has been buying MARC records for years.  I am surprised they have only just now started distributing them with purchases to libraries
13:30 owen          But I'm not surprised...They've built an empire based on real-world data searching. Why bring MARC into it? ;)
13:29 owen          to be honest, thd, I didn't look at it in detail
13:29 thd           owen: Amazon can supply MARC records but they do not know how to search them
13:28 thd           owen: they are still missing library searching
13:26 thd           ?
13:26 thd           owen: did you see that part of Amazon processing
13:25 thd           For a limited time, we're offering all processing for no additional cost. To take advantage of this offer, simply use the coupon code, AMZTRU733321, when placing your order. (There's no obligation when you sign up, and you control which orders receive processing.)
13:20 shedges       hey, folks
13:08 kados         that's big news
13:08 kados         wow
13:08 kados         hehe
13:07 dewey         rumour has it shedges is with us for a few minuts
13:07 kados         hey shedges
13:07 owen          http://vielmetti.typepad.com/superpatron/2006/07/amazon_library_.html
13:05 owen          Hi shedges