Time |
S |
Nick |
Message |
15:40 |
|
kados |
paul_away: you don't happen to be present do you? |
16:23 |
|
kados |
thd: you there? |
16:23 |
|
kados |
thd: I'm looking at the ISBD display for authorities currently |
16:24 |
|
thd |
kados: good morning :) |
16:24 |
|
kados |
I think what we want to be able to do is something like this: |
16:24 |
|
kados |
<heading> |
16:24 |
|
kados |
<auth_heading>[100a] [100d]</auth_heading> |
16:24 |
|
kados |
<see>[400a] [400d]</see> |
16:24 |
|
kados |
<see_also>[500a] [500d]</see_also> |
16:24 |
|
kados |
</heading> |
16:24 |
|
kados |
(for the markup) |
16:24 |
|
kados |
(good morning :-)) |
16:24 |
|
kados |
each <see> and <see_also> tag is repeatable |
16:25 |
|
thd |
kados: where is that code? |
16:26 |
|
kados |
it doesn't exist yet |
16:26 |
|
thd |
:) |
16:26 |
|
kados |
I spent a frustrating morning trying to figure out how the headings _should_ display |
16:26 |
|
thd |
kados: where is the place where it goes? |
16:26 |
|
kados |
uthoritiesMarc.pm |
16:26 |
|
kados |
AuthoritiesMarc.pm even |
16:26 |
|
kados |
wait ... no ... the xml you see above would go in the 'summary' |
16:27 |
|
thd |
kados: what is there currently that serves that function? |
16:27 |
|
kados |
another alternative is to just have the system be smart enough to generate the summary from the data |
16:27 |
|
kados |
that's what you wanted I think |
16:28 |
|
thd |
by summary do you mean authorised heading? |
16:29 |
|
thd |
kados: remember you changed the column name from summary in at least one place |
16:29 |
|
kados |
yep |
16:30 |
|
kados |
but the variable is still called $summary and summary |
16:30 |
|
kados |
anyway, I think I have an idea for how to do it |
16:30 |
|
kados |
since the 'See' is always of form 4XX and 'See also' is always of form '5XX' |
16:31 |
|
thd |
kados: I think that variable was meant to hold the authority framework type summary |
16:31 |
|
kados |
headings are always of the form 1XX |
16:32 |
|
kados |
yep it was |
16:32 |
|
kados |
but that has problems |
16:32 |
|
kados |
it can't deal with ordering |
16:32 |
|
thd |
kados: maybe it is too much code to change for the moment but identifying the framework type if searching for more than one framework type would be helpful |
16:32 |
|
kados |
and repeatability |
16:32 |
|
kados |
give me 5 minutes and I'll have something impressive :-) |
16:33 |
|
thd |
kados: are you intending to display the 4XX and 5XX returned from the authority? |
16:33 |
|
kados |
yep |
16:34 |
|
thd |
kados: If you had real authorities would that not make a crowded display |
16:35 |
|
thd |
kados: why would you not display only the 1XX or 7XX (where displaying 7XX is dependent upon the context being past $a) |
16:36 |
|
thd |
kados: also I have been up earlier than I should have looking at the current display |
16:38 |
|
thd |
kados: the authorised form that appears in the matching bibliographic record is what should be a hyperlink. |
16:39 |
|
thd |
kados: The biblio count should just be a count with no link embedded. |
16:40 |
|
thd |
kados: The additional link with the authority record number or set of record numbers would be another link to the MARC record for the authority or even an authority detail display. |
16:42 |
|
kados |
thd: I was using loc as a model |
16:43 |
|
thd |
kados: Existing systems link the authorised heading not the biblio count to the biblios. The authorities.loc.gov representation is unusual, not extensively developed, and fortunately not widely used. |
16:43 |
|
kados |
k ... that's easy enough to change |
16:44 |
|
kados |
so the heading should display 1XX entries ... or else 7XX entries ... right? |
16:44 |
|
kados |
no See or See also entries? |
16:44 |
|
thd |
kados: LC is using left anchored searches only eeeewwww :0 |
16:44 |
|
kados |
thd: if we could reproduce the functionanlity there I would be happy as a clam :-) |
16:44 |
|
kados |
thd: though I agree it could be better |
16:45 |
|
thd |
kados: see also would be useful if it led to a different authority |
16:45 |
|
kados |
http://www.loc.gov/marc/uma/pt1-7.html#pt4 |
16:45 |
|
kados |
in that document (maybe the next page) |
16:45 |
|
thd |
kados: see also is 5XX I think |
16:46 |
|
kados |
they describe display of See and See also entries for opac interfaces |
16:48 |
|
thd |
kados: so is Clements, Samuel Langhorne, 1835-1910 a different authority record from Twain, Mark ? |
16:49 |
|
thd |
kados: that display is stuck in the printed card age |
16:50 |
|
kados |
thd: look at the name auth record for Lewis now |
16:51 |
|
thd |
kados: although that would make it explicit to the user why searching for Samuel Clements found Mark Twain |
16:51 |
|
thd |
kados: I take back what I said about the printed card age and crowded displays |
16:52 |
|
thd |
kados: making the connection to the search term used by the user to arrive at the result is useful |
16:52 |
|
thd |
s/connection/connection explicit/ |
16:54 |
|
thd |
kados: I have seen Lewis now but it does not match the LC model |
16:54 |
|
thd |
kados it is missing some lines |
16:54 |
|
thd |
actually the see is in the wrong place |
16:55 |
|
kados |
thd: you sure? |
16:55 |
|
thd |
kados: nevemind |
16:56 |
|
thd |
kados: those are different people |
16:57 |
|
thd |
kados: no they are the same person are the not? |
16:58 |
|
thd |
kados: I had it right originally you need extra lines |
16:58 |
|
thd |
kados: you now have ... |
16:59 |
|
thd |
Lewis, C. S.1898-1963 (Clive Staples), |
16:59 |
|
thd |
See Lewis, Jack,1898-1963 |
16:59 |
|
thd |
See Hamilton, Clive, |
16:59 |
|
thd |
kados: you need to add |
17:02 |
|
thd |
the equivalent of ... |
17:02 |
|
thd |
Clemens, Samuel Langhorne, 1835-1910 |
17:02 |
|
thd |
see also: Twain, Mark, 1835-1910 |
17:02 |
|
thd |
Conte, Louis de, 1835-1910 |
17:02 |
|
thd |
see: Twain, Mark, 1835-1910 |
17:02 |
|
thd |
kados: underneath what you have already |
17:04 |
|
kados |
I did |
17:05 |
|
thd |
kados: otherwise the user thinks that searching under a different 4XX term is going to find different set of bib hits |
17:05 |
|
thd |
kados: let me explain the difference |
17:06 |
|
kados |
how is what you posted above different from: |
17:06 |
|
kados |
Lewis, C. S.1898-1963 (Clive Staples), |
17:06 |
|
kados |
see: Lewis, Jack,1898-1963 |
17:06 |
|
kados |
see: Hamilton, Clive, |
17:06 |
|
thd |
you have only the equivalent of . |
17:06 |
|
thd |
Twain, Mark, 1835-1910 |
17:06 |
|
thd |
see also: Clements, Samuel Langhorne, 1835-1910 |
17:07 |
|
thd |
kados what I last posted comes before what I had first posted |
17:07 |
|
thd |
for the LC example. |
17:08 |
|
kados |
ahh ... so both the authorized and unauthorized should show up ... |
17:08 |
|
kados |
is that what you mean? |
17:08 |
|
thd |
kados: if all the user sees is see Lewis, Jack 1898-1963 then |
17:09 |
|
kados |
thd: if you search 'anywhere' for Lewis, Jack |
17:09 |
|
kados |
thd: it will still return the correct authorized heading |
17:09 |
|
thd |
the user may expect that searching on Lewis Jack you would get different bib hits |
17:10 |
|
kados |
thd: the user will never see Lewis, jack as a main heading result |
17:10 |
|
kados |
with the current scheme |
17:10 |
|
thd |
kados: exactly but you have not made that clear to the user as in the LC example |
17:10 |
|
kados |
so maybe we should have 'highlighting' so they can see where it matches |
17:10 |
|
kados |
what do you think? |
17:11 |
|
thd |
kados: look at the LC example for every see they also have the line showing that you get right back to the record you have already |
17:11 |
|
kados |
thd: we have no results for 'see' that I know of |
17:12 |
|
kados |
thd: the user is always sent to the authority record |
17:12 |
|
thd |
kados: I am doing a poor job of explaining this |
17:12 |
|
thd |
kados: I will change the LC example to match the extra lines needed for Lewis |
17:13 |
|
thd |
kados: I did not want you to wait while I typed them |
17:13 |
|
thd |
kados: I will do 2 lines at a time |
17:14 |
|
kados |
ok |
17:14 |
|
thd |
kados: this much is fine for now although indentation and authorised term in bold would help |
17:15 |
|
thd |
Lewis, C. S.1898-1963 (Clive Staples), |
17:15 |
|
thd |
see: Lewis, Jack,1898-1963 |
17:15 |
|
thd |
see: Hamilton, Clive, |
17:15 |
|
kados |
that's what I have already |
17:20 |
|
thd |
kados: it should be as follows |
17:20 |
|
thd |
Lewis, C. S.1898-1963 (Clive Staples), |
17:20 |
|
thd |
see: Lewis, Jack,1898-1963 |
17:20 |
|
thd |
see: Hamilton, Clive, |
17:20 |
|
thd |
oops |
17:21 |
|
thd |
kados starting again ... |
17:21 |
|
thd |
Lewis, C. S.(Clive Staples), 1898-1963. |
17:21 |
|
thd |
see: Lewis, Jack,1898-1963 |
17:21 |
|
thd |
see: Hamilton, Clive, |
17:21 |
|
thd |
Lewis, Jack,1898-1963 |
17:21 |
|
thd |
see also: Lewis, C. S. (Clive Staples), 1898-1963. |
17:21 |
|
thd |
Hamilton, Clive, |
17:21 |
|
thd |
see also: Lewis, C. S. (Clive Staples), 1898-1963. |
17:21 |
|
thd |
kados: note the change in date ordering |
17:27 |
|
kados |
thd: try searching now for Hamilton, Clark |
17:27 |
|
kados |
thd: or Lewis, Jack |
17:28 |
|
kados |
thd: it will now style the terms you used in the results |
17:28 |
|
thd |
kados: #100||{ 100a }{ 100b }{ 100c }{ 100q }{ 100d }{ 100e}| |
17:29 |
|
kados |
thd: tell me what you think of my change |
17:29 |
|
kados |
thd: what did you post? |
17:31 |
|
thd |
kados: I pasted just now the correct place for X00q and also spacing separating the subfields |
17:31 |
|
thd |
i.e. the correct relative place for $q |
17:32 |
|
kados |
thd: currently, the display is ordered in the same way as the record |
17:32 |
|
kados |
thd: (in my modified display that is) |
17:32 |
|
thd |
kados: the record is wrong :) |
17:32 |
|
kados |
thd: ok :-) |
17:32 |
|
kados |
thd: that's a record editor problem |
17:33 |
|
kados |
thd: if a correct record were imported it would display correctly |
17:33 |
|
thd |
kados: oh yes you have not fixed the authority record editor yet |
17:34 |
|
thd |
kados: I understood that searching on a 4XX, 5XX, etc would let me find the authority for 1XX |
17:35 |
|
kados |
it does |
17:35 |
|
thd |
kados: do you not see the added value of 4 more lines? |
17:35 |
|
kados |
four more lines? |
17:35 |
|
kados |
which lines? |
17:35 |
|
thd |
Lewis, Jack,1898-1963 |
17:35 |
|
thd |
see also: Lewis, C. S. (Clive Staples), 1898-1963. |
17:35 |
|
thd |
Hamilton, Clive, |
17:35 |
|
thd |
see also: Lewis, C. S. (Clive Staples), 1898-1963. |
17:36 |
|
thd |
kados: maybe they should be see not see also |
17:36 |
|
kados |
I don't understand |
17:36 |
|
kados |
a search for Lewis gives me: |
17:36 |
|
kados |
Lewis, C. S.1898-1963 (Clive Staples), |
17:36 |
|
kados |
see: Lewis, Jack,1898-1963 |
17:36 |
|
kados |
see: Hamilton, Clive, |
17:37 |
|
kados |
why would you want Lewis Jack and Hamilton Clive listed separately from the main authority? |
17:37 |
|
kados |
especially now that they are highlighted in red if you searched for them |
17:37 |
|
thd |
kados: that much conveys to the user that if you search for Lewis, Jack you will find something different |
17:37 |
|
kados |
but you wont! |
17:38 |
|
thd |
kados: the extra lines qualify that |
17:38 |
|
kados |
in fact, they are all part of the same authority record |
17:38 |
|
thd |
kados: of course so make that explicit |
17:38 |
|
thd |
to the user |
17:38 |
|
thd |
the extra lines do that |
17:38 |
|
kados |
wow ... I really don't understand |
17:38 |
|
kados |
Lewis, C. S.1898-1963 (Clive Staples), |
17:38 |
|
kados |
see: Lewis, Jack,1898-1963 |
17:38 |
|
thd |
:0 |
17:38 |
|
kados |
see: Hamilton, Clive, |
17:38 |
|
kados |
that's what I have now |
17:38 |
|
thd |
yes |
17:39 |
|
thd |
kados: that looks like an instruction to the user to me |
17:39 |
|
kados |
you want those 'see' entries listed separately _again_? |
17:39 |
|
kados |
thd: but that's just the stupidity of MARC |
17:39 |
|
thd |
signifying go and search for Lewis Jack to find something |
17:40 |
|
kados |
thd: it's not my fault they use 'see' and 'see also' |
17:40 |
|
thd |
kados: which is why user displays have to be more informative |
17:40 |
|
thd |
kados: or less informative as I had wrongly suggested originally |
17:41 |
|
kados |
so in marc authorities |
17:41 |
|
kados |
you've got one main authorized heading in the 1XX |
17:41 |
|
kados |
then you've got alternative authorized headings in the 4XX |
17:41 |
|
kados |
then you've not unauthorized headings in 5XX |
17:41 |
|
kados |
s/not/got/ |
17:42 |
|
thd |
kados: right underneath there is the qualification that searching otherwise will find where you are already |
17:42 |
|
kados |
what you want is for a separate entry for all of the headings |
17:42 |
|
thd |
kados: the see is actually a see from |
17:43 |
|
kados |
that links to the main authorized heading |
17:44 |
|
thd |
kados the see in the authority is supposed to be understood as a see from in the authorised authority |
17:44 |
|
thd |
kados: So as this was derived from a card catalogue |
17:45 |
|
kados |
I think I understand |
17:45 |
|
kados |
I'll see what I can do |
17:45 |
|
thd |
kados: there would have been other cards matching the additional lines |
17:46 |
|
thd |
kados: the main card would not have had the see from as I recall |
17:47 |
|
thd |
kados: Card catalogues are completely gone but you can still see this in the massive printed volumes of LCSH |
17:47 |
|
thd |
kados: I have 2 copies of those massive volumes |
17:48 |
|
thd |
kados: unfortunately they take up too much space for me to keep them at hand :) |
17:52 |
|
kados |
it's quite hard in fact |
17:53 |
|
kados |
because as the object comes out there is know way to know what the last subfield iw |
17:53 |
|
kados |
is for a given tag |
17:55 |
|
kados |
I may need to go back a level and take a look at how this object is created |
17:57 |
|
kados |
I know how to do it |
17:57 |
|
kados |
I'll just hand the different types to the template |
17:57 |
|
kados |
in a loop |
18:29 |
|
kados |
thd: man, you're not kidding isbd was done backwards! |
18:29 |
|
kados |
thd: i can't even begin to figure out how to fix it |
18:29 |
|
thd |
kados: I had fixed what you had originally |
18:30 |
|
kados |
thd: er? |
18:30 |
|
kados |
thd: where? |
18:30 |
|
thd |
<heading> |
18:30 |
|
thd |
<auth_heading><b>[ 100a ] [ 100b ] [ 100c ] [ 100q ] [ 100d ] [ 100e ]</b></auth_heading> |
18:30 |
|
thd |
<see>[ 400a ] [ 400b ] [ 400c ] [ 400q ] [ 400d ] [ 400e ]</see> |
18:30 |
|
thd |
<see_also>[ 500a ] [ 500b ] [ 500c ] [ 500q ] [ 500d ] [ 500e ]</see_also> |
18:30 |
|
thd |
</heading> |
18:30 |
|
kados |
thd: I had to revert back to cvs code |
18:30 |
|
kados |
thd: because what i had was too convoluted |
18:31 |
|
thd |
kados: the <b> belongs in the template really |
18:31 |
|
kados |
thd: here's the problem with isbd |
18:31 |
|
thd |
kados: I have a simpler solution |
18:31 |
|
kados |
if you put [ 100a ] [ 100b ] [ 100c ] |
18:31 |
|
kados |
and in your data you have two of each of those (repeatable) |
18:31 |
|
kados |
they will come out like this : |
18:32 |
|
kados |
[ 100a ] [ 100a ] [ 100a ] [ 100b ] [ 100b ] [ 100b ] [ 100c ] [ 100c ] [ 100c ] |
18:32 |
|
thd |
kados: but I do not know the template module that Koha uses yet |
18:32 |
|
kados |
instead of |
18:32 |
|
kados |
[ 100a ] [ 100b ] [ 100c ] [ 100a ] [ 100b ] [ 100c ] [ 100a ] [ 100b ] [ 100c ] |
18:32 |
|
kados |
thd: HTML::Template |
18:33 |
|
thd |
kados: I mean that I have not learnt the usage for the module yet |
18:33 |
|
kados |
ahh |
18:33 |
|
kados |
I'm going back a level to look at how the fields are coming out from the db |
18:34 |
|
thd |
kados: I have used the CGI module for the same purpose in the past |
18:34 |
|
kados |
aak! |
18:34 |
|
kados |
my @fields = $record->fields(); |
18:34 |
|
kados |
wtf |
18:35 |
|
kados |
that's an insane way to deal with MARc data |
18:35 |
|
thd |
kados: yes repeated fields work improperly unless they happen to be repeated just next to one another in the original record |
18:36 |
|
thd |
kados: It is a simple way if all the records that you looked at led you to believe that orderliness matched alphabetic order |
18:37 |
|
thd |
kados: Which is what paul had presumed from the data he had seen |
18:38 |
|
thd |
kados: yet he seemed to have even been using examples from libraries that were not following the UNIMARC standard correctly already. |
18:39 |
|
thd |
kados: Getting it correct requires looking hard for the most difficult records. |
18:39 |
|
thd |
kados: If you can do the problematic ones then you can do any ones |
18:42 |
|
thd |
kados in my example remove the spaces between ] and [ to get .. |
18:43 |
|
thd |
<auth_heading><b>[ 100a ][ 100b ][ 100c ][ 100q ][ 100d ][ 100e ]</b></auth_heading> |
18:43 |
|
thd |
<see>[ 400a ][ 400b ][ 400c ][ 400q ][ 400d ][ 400e ]</see> |
18:43 |
|
thd |
<see_also>[ 500a ][ 500b ][ 500c ][ 500q ][ 500d ][ 500e ]</see_also> |
18:44 |
|
thd |
kados: although spaces at that point make no difference |
18:45 |
|
thd |
kados: spaces need to be inside the brackets to function |
18:54 |
|
kados |
spaces don't do anything that I can tell |
18:54 |
|
kados |
the major problem here |
18:55 |
|
kados |
is that there is no acknoledgement that this is a hierarchy |
18:55 |
|
kados |
with subfields being 'inside' of tags |
18:56 |
|
thd |
kados: spaces work inside curly braces for the ISBD preference |
18:56 |
|
kados |
curly braces? |
18:57 |
|
thd |
{ 100a } |
18:58 |
|
thd |
multiple spaces are reduced to one by browser rendering so that would be no problem |
18:59 |
|
kados |
i don't think ISBD is meant to be user configuratble |
18:59 |
|
thd |
kados: what lack of acknowledgement are you referencing. Do you mean the user display? |
19:00 |
|
kados |
it seems from the spec like it's just meant to be pre-defined |
19:00 |
|
kados |
thd: yes from the user display |
19:01 |
|
thd |
kados the user display can use indentation with an HTML dictionary list |
19:01 |
|
kados |
I have no idea what you mean by that |
19:01 |
|
thd |
kados: dictionary usually render hierarchically but that can be enforced in CSS |
19:02 |
|
thd |
kados <dl> |
19:04 |
|
thd |
kados: <dd> will give you a drop indent |
19:13 |
|
kados |
there is no way we can represent things in the right order using the current code |
19:14 |
|
thd |
kados: I supplied you with ISBD code that forces things to the order that is usually correct |
19:14 |
|
thd |
when I substituted your example XML |
19:15 |
|
thd |
kados: The correct was is the routine from SearchMarc.pm |
19:15 |
|
thd |
kados: the one you looked at last night |
19:16 |
|
thd |
s/was/way/ |
19:20 |
|
thd |
kados: paul had created getMARCsubjects in SearchMarc.pm for this very problem. |
19:20 |
|
thd |
kados: I understand that code well and can adapt it for any field |
19:22 |
|
thd |
kados: It is really very simple after staring at it for long enough :) |
19:24 |
|
thd |
kados: It needs to be generalised with a variable for what type of field it needs to return so it knows how to apply spaces and/or '---' between subfields. |
19:26 |
|
thd |
Where the '--' does not apply to name fields but only to topic fields. |
19:34 |
|
kados |
thd: check the Lewis entry now |
19:34 |
|
kados |
thd: see if it's what you want |
19:35 |
|
kados |
thd: it should work properly if the data is correct |
19:35 |
|
kados |
thd: of course, it's not the programmers reponsibility to fix improper cataloging |
19:35 |
|
thd |
kados: you can force it to appear more correctly |
19:36 |
|
kados |
(unless it's caused by improper MARc edit tools :-)) |
19:36 |
|
kados |
thd: that is a version 4 goal :-) |
19:36 |
|
kados |
thd: I would be happy currently to just get it working with correct data |
19:36 |
|
kados |
thd: how does the Lewis entry look to you? |
19:37 |
|
thd |
kados: if you are using the existing Koha ISBD backwards system then you have forced it to be incorrect even if the record were correct |
19:37 |
|
kados |
thd: I'm not |
19:37 |
|
kados |
thd: I rewrote the way that $summary is populated |
19:37 |
|
thd |
kados: However, you can easily fix that within the broken ISBD system |
19:38 |
|
kados |
the current ISBD system must die |
19:38 |
|
kados |
it can't represent a hierarchy |
19:38 |
|
thd |
kados: using code like what is in getMARCsubjects ? |
19:38 |
|
kados |
so in my mind it's never going to work properly |
19:38 |
|
kados |
I'll have to reread that code |
19:38 |
|
kados |
but if I recall there is much cardcoded in it |
19:39 |
|
kados |
IMO this is a better approach: |
19:39 |
|
kados |
foreach my $field ($record->field('1..')) { |
19:39 |
|
kados |
$heading.= $field->as_string(); |
19:39 |
|
kados |
} |
19:39 |
|
kados |
my $summary.="<b>".$heading."</b><br>"; |
19:39 |
|
kados |
foreach my $field ($record->field('4..')) { |
19:39 |
|
kados |
$summary.= $field->as_string()."<br>"; |
19:39 |
|
thd |
kados: That is why you need to pass a couple of variables to generalise it |
19:39 |
|
kados |
$summary.= " <i>see:</i> ".$heading."<br>"; |
19:39 |
|
kados |
} |
19:41 |
|
thd |
kados: that works although it does not match the LC example exactly yet. |
19:41 |
|
thd |
kados: I can fix it though |
19:41 |
|
kados |
thd: only because the data is incorrect :-) |
19:42 |
|
thd |
kados: I mean indentation boldness and the two see from lines just under the heading. |
19:43 |
|
thd |
kados: but what you have is not confusing and looks beautiful |
19:43 |
|
kados |
thd: it matches this perfectly I think: |
19:43 |
|
kados |
http://www.loc.gov/marc/uma/pt12.html |
19:44 |
|
thd |
sorry you have boldness, and partial indentation |
19:44 |
|
kados |
so do they :-) |
19:45 |
|
kados |
boldness for the first heading |
19:45 |
|
thd |
kados: you have the last 4 lines but you dropped the 2nd and 3rd line |
19:45 |
|
thd |
kados: and if you look closely everything after the heading is indented relative to the heading |
19:46 |
|
kados |
Lewis, C. S. 1898-1963 (Clive Staples), |
19:46 |
|
kados |
Lewis, Jack, 1898-1963 |
19:46 |
|
kados |
see: Lewis, C. S. 1898-1963 (Clive Staples), |
19:46 |
|
kados |
Hamilton, Clive, |
19:46 |
|
kados |
see: Lewis, C. S. 1898-1963 (Clive Staples), |
19:46 |
|
kados |
what is the difference?: |
19:46 |
|
kados |
Woolf, Virginia, 1882-1941 |
19:46 |
|
kados |
Stephen, Virginia, 1882-1941 |
19:46 |
|
kados |
See Woolf, Virginia, 1882-1941 |
19:46 |
|
kados |
Woolf, Virginia Stephen, 1882-1941 |
19:46 |
|
kados |
See Woolf, Virginia, 1882-1941 |
19:47 |
|
thd |
compare ... |
19:47 |
|
thd |
Lewis, C. S.(Clive Staples), 1898-1963. |
19:47 |
|
thd |
see: Lewis, Jack,1898-1963 |
19:47 |
|
thd |
see: Hamilton, Clive, |
19:47 |
|
thd |
Lewis, Jack,1898-1963 |
19:47 |
|
thd |
see also: Lewis, C. S. (Clive Staples), 1898-1963. |
19:47 |
|
thd |
Hamilton, Clive, |
19:47 |
|
thd |
see also: Lewis, C. S. (Clive Staples), 1898-1963. |
19:47 |
|
thd |
kados: i have confused see and see also so ignore that |
19:48 |
|
kados |
ok |
19:48 |
|
thd |
kados: look at the indentation |
19:48 |
|
kados |
but actually you can't |
19:48 |
|
kados |
we must be looking at different pages |
19:48 |
|
thd |
kados can't what? |
19:48 |
|
kados |
see also means it's authoritative |
19:48 |
|
kados |
see means it's not |
19:49 |
|
kados |
so you can't ignore that because I think it should affect the display |
19:49 |
|
thd |
that was my mistake |
19:49 |
|
thd |
kados: I just had not corrected that when I posted that again |
19:49 |
|
thd |
assume I had posted that bit correctly |
19:50 |
|
thd |
kados: just look at the relative indentation |
19:50 |
|
thd |
Lewis, C. S.(Clive Staples), 1898-1963. |
19:50 |
|
thd |
see: Lewis, Jack,1898-1963 |
19:50 |
|
thd |
see: Hamilton, Clive, |
19:50 |
|
thd |
Lewis, Jack,1898-1963 |
19:50 |
|
thd |
see: Lewis, C. S. (Clive Staples), 1898-1963. |
19:50 |
|
thd |
Hamilton, Clive, |
19:50 |
|
thd |
see: Lewis, C. S. (Clive Staples), 1898-1963. |
19:51 |
|
kados |
ok |
19:51 |
|
thd |
kados: now that it is fixed focus on how everything is indented relative to the heading |
19:51 |
|
thd |
kados: also they have lines 2 and 3 |
19:52 |
|
kados |
there shouldn't be 'see' options under the main heading |
19:52 |
|
thd |
kados: I do not understand why they have the see from listing in their example but they do |
19:53 |
|
thd |
in lines 2 and 3 |
19:54 |
|
thd |
kados: we were referencing different pages just now |
19:55 |
|
thd |
kados: I had modelled your first Twain example from earlier |
19:55 |
|
kados |
right, I see that now |
19:55 |
|
kados |
I'm changing it ... just a sec |
19:56 |
|
thd |
kados: I do not know what context is different except that I suspect the earlier example was for a computer display |
19:59 |
|
thd |
kados; well they are both obviously for computer displays but the second one looks more like a sequential browse in a large alphabetic list |
20:03 |
|
thd |
kados: I have never actually read the Understanding MARC Authority Records. It is not as old as Understanding MARC Bibliographic which first helped me to understand MARC well. |
20:04 |
|
kados |
thd: in the Lewis example |
20:04 |
|
kados |
thd: there are no alternative authorized headings |
20:04 |
|
kados |
thd: only unauthorized ones |
20:04 |
|
kados |
thd: (on liblime's opac) |
20:05 |
|
kados |
unauthorized headings reference authorized headings |
20:05 |
|
kados |
authorized headings reference other authorized headings |
20:06 |
|
kados |
but authorized headings never reference unauthorized headings |
20:06 |
|
thd |
kados: so that is the difference or the degree of indentation? |
20:06 |
|
kados |
yep |
20:06 |
|
kados |
we need an example with multiple authorized headings to test my code |
20:07 |
|
thd |
kados: no they have both |
20:07 |
|
thd |
kados: the Twain example has both 500 and 400 |
20:07 |
|
kados |
thd: but that's not on LibLime's opac is it? |
20:08 |
|
thd |
kados: yet the 400 is still indented underneath th heading |
20:08 |
|
kados |
it's indented |
20:09 |
|
kados |
right |
20:09 |
|
kados |
but there is no 'see' entry for it |
20:09 |
|
thd |
kados: exactly |
20:10 |
|
thd |
Lewis, C. S.(Clive Staples), 1898-1963. |
20:10 |
|
thd |
Lewis, Jack,1898-1963 |
20:10 |
|
thd |
see: Lewis, C. S. (Clive Staples), 1898-1963. |
20:10 |
|
thd |
Hamilton, Clive, |
20:10 |
|
thd |
see: Lewis, C. S. (Clive Staples), 1898-1963. |
20:11 |
|
thd |
kados: I think if you outdent the 4XX then that is for browsing a large alphabetical list |
20:12 |
|
thd |
kados: This indentation I just posted seems more appropriate. |
20:13 |
|
kados |
thd: bingo |
20:13 |
|
kados |
thd: look now |
20:13 |
|
thd |
kados: the IFLA standards for OPAC displays have been published for a few months but I have not checked to see if it has hit the web yet |
20:14 |
|
kados |
we still need to test cases where there are 'see also' entries |
20:15 |
|
thd |
kados: looks good, now move the hyperlink from the number of bib records to the heading |
20:15 |
|
kados |
hehe ... trickier than it seems :-) |
20:15 |
|
kados |
lets test the seealso case first |
20:15 |
|
thd |
kados: ok |
20:16 |
|
thd |
kados: we know that we can create Twain |
20:17 |
|
kados |
adding it now |
20:18 |
|
kados |
hehe ... 500 error :-) |
20:20 |
|
thd |
kados: really, I have no 500 error |
20:20 |
|
thd |
kados: which intranet subdomain is this? |
20:29 |
|
thd |
IFLA Guidelines for Online Public Access Catalogue (OPAC) Displays. |
20:29 |
|
thd |
Final Report May 2005 |
20:29 |
|
thd |
M?nchen: Saur, 2005, 61 p. |
20:29 |
|
thd |
ISBN 3-598-24276-X |
20:29 |
|
thd |
(IFLA Series on Bibliographic Control; vol. 27). |
20:29 |
|
thd |
Price: EUR 34 (IFLA Members EUR 26,80) |
20:31 |
|
thd |
kados: it does not seem to be on the web yet although some inadequate early draft is there from before politics and time wore down the draft author. |
20:40 |
|
kados |
thd: check the opac for 'Twain' now |
20:40 |
|
kados |
we may have achieved perfection :-) |
20:40 |
|
thd |
kados: i just checked the intranet and it is off just a little with spacing :) |
20:41 |
|
kados |
heh |
20:41 |
|
kados |
check again |
20:42 |
|
thd |
the OPAC is fine |
20:42 |
|
thd |
the intranet is the same :) |
20:43 |
|
thd |
I mean same fine :) |
20:43 |
|
kados |
great |
20:44 |
|
kados |
so what's next? :-) |
20:45 |
|
thd |
kados: a dictionary list with the right CSS might look just slightly better typographically than break tags |
20:45 |
|
thd |
however once everything else is perfect that could be fiddled with |
20:46 |
|
kados |
yep |
20:46 |
|
thd |
kados: what about linking the heading instead of the hit count? |
20:46 |
|
kados |
I'll try |
20:48 |
|
thd |
kados: I know that everything throughout Koha mostly tries to use the anchor link content identical to the anchor display content. |
20:53 |
|
kados |
woot ... working |
20:57 |
|
kados |
thd: you sure the heading shouldn't take you to the MARC? |
20:57 |
|
thd |
wow no not in the usual displays that I have seen |
20:58 |
|
thd |
kados: and for the MARC in the OPAC that should be on a rightmost column |
20:59 |
|
thd |
kados: the patrons want to find the material catalogued not usually the MARC displays |
20:59 |
|
kados |
what should be on the right-hand column? |
21:00 |
|
thd |
kados: in the OPAC at least the link to the MARC record for the authority should be a last column, not a first column |
21:01 |
|
kados |
gotcha |
21:04 |
|
kados |
ok ... |
21:04 |
|
kados |
subject headings don't really work very well |
21:04 |
|
kados |
i suspect that's because the bulk import didn't do everything |
21:04 |
|
thd |
kados: Authorized Heading(#4074) could use better display text such as MARC for whatever is in the 1XX |
21:05 |
|
kados |
give me an example |
21:06 |
|
thd |
kados: MARC for Twain, Mark, 1835-1910 but I am sure the description could improve with some consideration and examination of other systems. |
21:07 |
|
thd |
kados: and I hope that delete does nothing in the OPAC :) |
21:08 |
|
kados |
heh ... aactually it might actually delete :-) |
21:08 |
|
thd |
delete should not be in the OPAC :) |
21:08 |
|
kados |
I'll need to get rid of that :-) |
21:09 |
|
thd |
kados but you left the column in heading row |
21:10 |
|
kados |
yea i intend to put the type in there |
21:10 |
|
thd |
beautiful |
21:10 |
|
kados |
personal name, corporate name, etc. |
21:11 |
|
thd |
The OPAC should still have nicer text instead of Authorized Heading(#4074) |
21:11 |
|
kados |
like what? |
21:13 |
|
thd |
MARC for Twain, Mark, 1835-1910 or something better after more thought and example examination from other systems |
21:13 |
|
thd |
certainly patrons do not care what the record number is |
21:15 |
|
kados |
how's that? |
21:15 |
|
thd |
kados: much better |
21:15 |
|
thd |
kados: that is beautiful |
21:18 |
|
kados |
how do we tell what type of heading it is most efficiently? |
21:18 |
|
thd |
kados: we have to overcome the problem for building records whee it did not find the records |
21:19 |
|
kados |
there is much to do in building a given record yet |
21:19 |
|
kados |
but I'm happy we're getting there :-) |
21:19 |
|
thd |
kados: my suggestion was to use only 'a' as the key |
21:20 |
|
kados |
hmmm ... I still don't fully understand what paul's hash is used for |
21:20 |
|
thd |
kados: yes, I am merely tossing out a guess without real inspection of the code or asking paul or hdl |
21:21 |
|
kados |
I suspect we will need to rewrite it |
21:21 |
|
kados |
the question is |
21:21 |
|
kados |
how do we map from a record to an auth record? |
21:22 |
|
thd |
kados: bib records are mapped to auth records with $9 in each of the controlled fields |
21:23 |
|
thd |
kados: However, you knew that so what had you meant by your question |
21:23 |
|
thd |
? |
21:23 |
|
kados |
thats' not what I meant |
21:23 |
|
kados |
I mean, how do we construct the auth record values from the bib recor dvalues? |
21:24 |
|
thd |
kados: you can only construct 1XX in the authority records which is why that is the poor person's system |
21:25 |
|
kados |
even if the record has values in 6XX and 7XX? |
21:25 |
|
thd |
kados: the 1XX is in the authority record |
21:25 |
|
thd |
kados: so starting from 650 .. |
21:26 |
|
thd |
in a biblio you get 150 in an authority record. |
21:28 |
|
thd |
kados: You cannot fill 4XX, 5XX in the authority records by building from bibliographic records. |
21:28 |
|
thd |
kados: although you could try to extract the form of author names used on the material itself from the statement of responsibility |
21:30 |
|
thd |
245 $c |
21:31 |
|
thd |
kados: but that would help you only a little. Authorities only do what they should when you import the NACO authorities. |
21:32 |
|
thd |
kados: existing systems that use them well are rare to none |
21:33 |
|
thd |
kados: most systems simply verify cataloguing against the authorised form after the cataloguing data has been entered. |
21:34 |
|
kados |
we can do better than that :-) |
21:35 |
|
thd |
kados: LC uses a system that checks existing uses and provides a drop down list after the cataloguer has already typed everything |
21:35 |
|
thd |
well actually it is more like autocomplete |
21:37 |
|
thd |
kados: but it does not help the cataloguer search against 4XX 5XX when typing |
21:37 |
|
thd |
kados: Koha has that system beat already. |
21:40 |
|
thd |
kados: or at least Koha would have that system beat if real authority records were in Koha |
21:42 |
|
thd |
kados: I had a half reasonable understanding of how bulkmarcimport.pl worked a few months ago. |
21:42 |
|
thd |
kados: we need to get build_authorities.pl working before we can marry the two. |
21:43 |
|
kados |
in the display |
21:46 |
|
thd |
yaay |
21:47 |
|
kados |
anything to put off writing import scripts :-) |
21:47 |
|
thd |
kados we need to fix Results for Search: 1009 = 3509 |
21:47 |
|
thd |
No results found. |
21:47 |
|
kados |
ahh ... |
21:47 |
|
kados |
which search does that happen on? |
21:48 |
|
thd |
kados:Frontier and pioneer life Fiction |
21:48 |
|
thd |
kados: There are multiple Frontier and pioneer life Fiction when searching frontier |
21:48 |
|
kados |
yep |
21:49 |
|
kados |
poor algorythm for matching |
21:49 |
|
kados |
well actually ... notice that they have subdivisions included |
21:49 |
|
thd |
kados: where does the matching algorithm live? |
21:49 |
|
kados |
build_authorities.pl |
21:55 |
|
kados |
results for search fixed |
21:56 |
|
kados |
:-) |
21:57 |
|
thd |
kados : so what lines do the matching |
21:57 |
|
thd |
? |
22:00 |
|
kados |
dunno I haven't really looked at it |
22:01 |
|
thd |
kados: what happened to the various authority types from last night? |
22:03 |
|
thd |
kados: I may see the problem for not finding the biblio records |
22:04 |
|
thd |
kados: the hash is storing codes to identify the authority types |
22:04 |
|
thd |
kados: These are in all capitals in French |
22:05 |
|
thd |
kados: Those codes need to match the authority type. |
22:05 |
|
thd |
maybe :) |
22:07 |
|
thd |
I think that requires searching the UNIMARC framework code to find where they are used |
22:11 |
|
kados |
thd: i deleted the other auth types |
22:11 |
|
kados |
thd: because there should only be four search points |
22:11 |
|
kados |
thd: I have to step out for a bit -- get some dinner |
22:12 |
|
kados |
thd: when I get back I'll start working on an import script |
22:12 |
|
kados |
thd: (the problem is that we dont' have any good auth records) |
22:12 |
|
kados |
thd: (if you know of some we could use or want to download a bunch from LOC that might be helpful) |
22:12 |
|
thd |
kados; and explain four search points instead of a few more |
22:12 |
|
kados |
anyway ... I'll be back in a bit |
22:12 |
|
kados |
thd: i will |
22:14 |
|
thd |
kados: I have 17k authorities from LC |
22:15 |
|
thd |
courtesy of pines |
22:38 |
|
kados |
thd: back |
22:38 |
|
kados |
I have those too |
22:39 |
|
kados |
I also have the PINES data to go with them -- all 5 million records :-) |
22:39 |
|
kados |
thd: have you looked at them yet? |
22:40 |
|
kados |
ooh ... they're not bad |
22:40 |
|
kados |
looks like lots of serials |
22:42 |
|
kados |
LOC says you can download their MARC records for use in a library system |
22:42 |
|
kados |
thd: I wonder if we can batch download them slowly over the course of many days to arrive a a complete set of authority records for a client :-) |
22:44 |
|
thd |
kados: LC will log your IP address and block you :) |
22:44 |
|
kados |
thd: no prob ... I've got about 400 IP addresses :-) |
22:45 |
|
thd |
kados: you could use LWP to write a script |
22:45 |
|
thd |
kados: I have done that but not for LC |
22:45 |
|
thd |
kados: LC is a little tricky because of session initialisation |
22:46 |
|
thd |
kados: I have seen that some people have overcome that issue |
22:47 |
|
thd |
kados: I actually have some python script that I had used |
22:48 |
|
thd |
kados: I had asked someone at CDS about doing that sort of thing manually, knowing that I could script t |
22:48 |
|
thd |
kados: The answer I was given was that there was a limitation on the number of records in a given period |
22:49 |
|
thd |
kados: The only way that could really work though is by IP address. |
22:50 |
|
thd |
kados: apart from contract access to some of their content |
22:51 |
|
thd |
kados: yet it would still be incomplete because ... |
22:52 |
|
thd |
there is no "Search access to form, genre, and topical subject subdivisions" |
22:59 |
|
thd |
kados: there is a very large group of records that they still do not distribute through CDS even for money |
23:01 |
|
thd |
kados: look at the beginning dates for the retrospective files from CDS |
23:01 |
|
thd |
http://www.loc.gov/cds/mds.html#ba |
23:05 |
|
thd |
kados: The older MARC records from retrospective conversion of pre-MARC printed cards have issues like racist subject headings that keep them out of CDS distribution until the updating is complete. |
23:08 |
|
thd |
kados: ok the information needed to make such a script work is partly in the method UNIMARC uses for building authorities using a standard set of codes for authority types. |
23:08 |
|
thd |
kados: why only 4 authority types? You are missing some. |
23:09 |
|
kados |
do we want more than 4 search points? |
23:09 |
|
kados |
I've never seen an authorities search with all 7 |
23:09 |
|
thd |
kados: you can and should group them but there are more authority types in the standard |
23:10 |
|
kados |
more than 7? |
23:10 |
|
thd |
kados: More than 4 |
23:10 |
|
kados |
position 9 in 008 only has 7 |
23:10 |
|
kados |
and those 7 can be grouped easily into 4 |
23:10 |
|
kados |
they will still retain their types |
23:10 |
|
kados |
because they all use different tags |
23:10 |
|
thd |
kados: that is different usage of type that what I meant |
23:11 |
|
kados |
what did you mean? |
23:11 |
|
kados |
if we have more than four authority frameworks in Koha there will be more than 4 search points |
23:11 |
|
kados |
which we don't want |
23:11 |
|
thd |
kados: I was referring to authority frameworks linked to a 1XX $a in an authority record. |
23:12 |
|
thd |
kados: you can build a search to search more than one. |
23:13 |
|
thd |
kados: you can group the inde4xes together |
23:13 |
|
kados |
what is the advantage to having so many frameworks in Koha? |
23:14 |
|
kados |
instead of grouping the frameworks? |
23:14 |
|
thd |
kados: It is not an advantage it is the existing design. |
23:15 |
|
thd |
kados: Grouping would be better but there is no code for that yet. |
23:15 |
|
kados |
that would be easier than changing the search I think |
23:16 |
|
thd |
kados: There is already code for changing the search. |
23:16 |
|
kados |
? |
23:16 |
|
kados |
where? |
23:16 |
|
thd |
kados: The link function in the biblio frameworks. |
23:17 |
|
kados |
I have yet to see that work |
23:17 |
|
kados |
in fact I don't know what it does |
23:17 |
|
thd |
kados: I tried to ask paul what it did precisely and although he was unclear in his memory he seemed to agree that my suggested likely use was correct. |
23:18 |
|
kados |
also, that does not solve the problem that the search types are directly linked to the frameworks |
23:18 |
|
kados |
when you go to do a search you have to select a type |
23:19 |
|
thd |
kados: just as the see also column extends the string search the link column extends the value restriction search. however that is not the same as an authorities search. |
23:21 |
|
kados |
what is a 'value restriction search'? |
23:21 |
|
thd |
kados: The same mechanism must be extendable to the authority frameworks, however, if a column is added to the bibliographic frameworks. |
23:22 |
|
thd |
kados: value restricted is what the '...' search does in the OPAC now. |
23:22 |
|
kados |
heh ... as if that does anything :-) |
23:22 |
|
kados |
it's just like doing a search before you do a search |
23:22 |
|
thd |
kados: It searches only the value chosen in the result |
23:22 |
|
kados |
that's actually not true :-) |
23:22 |
|
thd |
kados :0 |
23:23 |
|
kados |
that may be the way it _should_ work |
23:23 |
|
kados |
but it certainly doesn't work that way |
23:23 |
|
thd |
kados: only if you use the wrong query terms |
23:23 |
|
kados |
if you can find a search where it works let me know |
23:24 |
|
kados |
from what I've seen all it does is a normal search |
23:25 |
|
thd |
kados: if you search for hot air as value restricted and choose hot air it is not designed well enough to give you only hot air and not hot air baboons. |
23:26 |
|
thd |
kados: however, if you search for hot air as value restricted and choose hot air balloons it will not find merely hot air. |
23:27 |
|
thd |
s/baboons/balloons/ |
23:27 |
|
thd |
kados: do you see that distinction? |
23:28 |
|
kados |
in theory |
23:28 |
|
thd |
kados: the search should be an exact field search except for problems with MARC in SQL. |
23:28 |
|
kados |
but I've yet to see it working in Kokha |
23:29 |
|
thd |
kados: That is because you always choose the hot air option when you are done and not the hot air balloons option |
23:30 |
|
kados |
like i said ... if you can find an example ... I'd be very excited :-) |
23:31 |
|
thd |
in which case the template should be fixed |
23:32 |
|
kados |
looking at paul's current code |
23:33 |
|
kados |
he seems to have intended that the authorities frameworks |
23:33 |
|
kados |
have a one-to-one corolation to leader position 9 |
23:34 |
|
kados |
which from what I can tell is different than the headings |
23:36 |
|
kados |
there are 7 possible leader values for position 9 |
23:36 |
|
kados |
however, there are 8 possible types of headings |
23:37 |
|
thd |
kados I will check the UNIMARC use of the leader there which is different |
23:38 |
|
thd |
kados: The link search works fine except for some template issue fro the right column JavaScript |
23:39 |
|
thd |
s/fro/for/ |
23:39 |
|
kados |
can you show me an example? |
23:40 |
|
thd |
kados: It is labelled authority search but it is not really since it works fine with no authorities built |
23:40 |
|
thd |
kados: search for United States as a subject |
23:41 |
|
thd |
kados: then choose any single result you get that result only |
23:41 |
|
thd |
kados: initiate the search by clicking on '...' of course |
23:42 |
|
kados |
how are the results any different than just typing in the values? |
23:42 |
|
kados |
(also, bad example because there are only results with 1 record) |
23:43 |
|
thd |
kados: the selection list has biblio counts but not biblios. |
23:43 |
|
kados |
search on 'forest' |
23:43 |
|
kados |
and select 'forest animals' |
23:44 |
|
kados |
there should only be 4 reusults right? |
23:44 |
|
kados |
but there aren't :-) |
23:46 |
|
thd |
kados: I see I have six instead of 4 although it works for the part labelled authorities or seems to well enough |
23:46 |
|
kados |
try it with the authorities values too |
23:47 |
|
kados |
pick 'rain forest ecology' |
23:47 |
|
kados |
not one result but three |
23:47 |
|
thd |
kados: it may be in part that the linking is not correct |
23:48 |
|
kados |
the problem is that the only thing the pop up dictionary search does is fill text values int he normal search box |
23:49 |
|
thd |
kados: you have to use the values on the left column |
23:49 |
|
kados |
? |
23:49 |
|
thd |
for the authorities search |
23:49 |
|
kados |
I was picking 'select and close' |
23:51 |
|
thd |
kados search forest and then choose the first authorised value Rain forest ecology -- Juvenile literature |
23:51 |
|
thd |
kados: the JavaScript links on the right are not correct |
23:52 |
|
thd |
kados: They can be fixed though |
23:52 |
|
kados |
sure, that one works ... but it also works if you just type it in the text box |
23:53 |
|
thd |
kados: but you did not have a list of matching subjects and only matching subjects from the textbox |
23:53 |
|
thd |
kados: The textbox search returns a list of biblios. |
23:54 |
|
thd |
kados: you would need to open each biblio to see the subjects |
23:55 |
|
thd |
kados: the '...' search gives you a different results display that you can use to refine your search |
00:00 |
|
thd |
kados: it does not seem to search tracings and references in the authority but that would only need the proper support of a framework column for that |
00:01 |
|
thd |
kados: It is not a true authorities search |
00:03 |
|
thd |
s/framework/biblio framework/ |
00:09 |
|
thd |
kados: leader position 000/09 is undefined in UNIMARC for both bibliographic and authorities. |
00:09 |
|
thd |
kados: were you looking at the do nothing code in bulkauthimport.pl? |
00:09 |
|
kados |
why does paul use it in bulkauthimport.pl? |
00:10 |
|
kados |
why do you say it is do nothing? |
00:10 |
|
kados |
it looks like it might work |
00:10 |
|
kados |
all it does is call AUTHaddauthority |
00:10 |
|
thd |
kados: That code was a couple hours start that was abandoned before he had anything right |
00:11 |
|
thd |
kados: you cannot learn much that is correct from that code. |
00:11 |
|
kados |
gotcha |
00:12 |
|
thd |
kados: the code to study is build_authorities.pl and bulkmarcimport.pl |
00:13 |
|
thd |
kados: If you understand how build_authorities.pl works then you can add authority supporting code to a copy of bulkmarcimport.pl to create a working bulkauthimport.pl. |
00:14 |
|
kados |
both scripts use the same subroutine |
00:14 |
|
kados |
AUTHaddauthority |
00:14 |
|
thd |
kados: both which scripts? |
00:15 |
|
kados |
build_authorities.pl and bulkauthimport.pl |
00:26 |
|
thd |
kados: paul's vague intention with bulkauthimport.pl is obvious and that can be seen from the code. |
00:28 |
|
thd |
kados: first you must test for whether you have an authority record or a bibliographic record. |
00:28 |
|
thd |
kados: that can be determined from the leader. |
00:29 |
|
kados |
I'm not sure that's the way to go about it |
00:29 |
|
kados |
I think we already know which are auth records |
00:29 |
|
thd |
kados: paul imagined that the leader also contained a clue about authority type but it does not. |
00:30 |
|
thd |
kados: authority type is determined from the 1XX used. |
00:30 |
|
kados |
right |
00:31 |
|
thd |
kados: after that point his intention of labelling the type more explicitly in a single field may be useful. |
00:31 |
|
thd |
s/field/local use field/ |
00:32 |
|
thd |
kados: beyond that bulkauthimport,pl has no utility for creating a working model. |
00:41 |
|
kados |
so how do we break things down into our framework codes? |
00:41 |
|
kados |
NAME, SUBJECT, NAME / TITLE HEADING, UNIFORM TITLE |
00:44 |
|
kados |
X00 Personal names |
00:44 |
|
kados |
X10 Corporate names |
00:44 |
|
kados |
X11 Meeting names |
00:44 |
|
kados |
X30 Uniform titles |
00:44 |
|
kados |
X48 Chronological terms |
00:44 |
|
kados |
X50 Topical terms |
00:44 |
|
kados |
X51 Geographic names |
00:44 |
|
kados |
X55 Genre/form terms |
00:44 |
|
kados |
do those map? |
00:46 |
|
thd |
kados: looks good to me |
00:46 |
|
kados |
terms are subjects? |
00:47 |
|
thd |
yes |
00:47 |
|
kados |
how do we handle NAME/TITLE HEADINGS? |
00:48 |
|
thd |
kados: those are in uniform titles |
00:48 |
|
kados |
er? |
00:49 |
|
kados |
what is the difference between NAME/TITLE HEADINGS |
00:49 |
|
kados |
and UNIFORM TITLES? |
00:49 |
|
thd |
kados: Shakespeare/Hamlet could be a uniform title |
00:50 |
|
thd |
kados: then it would also serve as a name/title heading |
00:51 |
|
thd |
kados: LibLime Newsletter could also be a uniform tile |
00:54 |
|
thd |
kados: When it is transformed into the LibLime Journal of Information Science it may change 130 but then so would the older bibliographic entry for the record where 245 has LibLime newsletter |
00:54 |
|
thd |
kados: then LibLime Newsletter would become a 530 |
00:57 |
|
thd |
kados: uniform title is also used for series such as Education through Art |
00:58 |
|
thd |
so every volume of the Education through Art series has the same uniform title. |
01:06 |
|
thd |
the series uniform title would be an 830 in the bibliographic record not 130 which would be for the individual volume if there were a uniform title for the individual volume. |
01:12 |
|
kados |
what is the difference between NAME/TITLE HEADINGS and UNIFORM TITLES? :-) |
01:13 |
|
kados |
are all TITLES and NAMES also in NAME/TITLE headings? |
01:13 |
|
kados |
or only some of them? |
01:13 |
|
kados |
or none of them? |
01:15 |
|
kados |
under what circumstances on import do I create a NAME/TITLE heading instead of a NAME or a TITLE heading or should I always create all three? |
01:15 |
|
kados |
thd: you still there? |
01:15 |
|
thd |
yes |
01:17 |
|
thd |
kados: the biblio will already have a name / title unless you are creating original records. |
01:17 |
|
kados |
I thought we were talking about auth records ... |
01:18 |
|
thd |
kados: the biblio will have the fields it has unless you are asking about how to catalogue a particular work |
01:19 |
|
thd |
kados: I was talking about matching authority record content to biblio content by adding a $9 to a match in the biblio. |
01:20 |
|
kados |
I don't understand why there exist name headings, title headings and name/title headings |
01:20 |
|
kados |
why would you want a name/title heading instead of separate title and name headings? |
01:20 |
|
thd |
kados: name/title headings are possible uniform title records. |
01:21 |
|
thd |
kados: if the uniform title authority is in name /title form like Shakespeare/hamlet then it its a name title heading. |
01:22 |
|
kados |
I don't think we can currently handle name/titles |
01:22 |
|
kados |
we can only deal with them independently |
01:22 |
|
kados |
if I'm not mistaken |
01:22 |
|
thd |
kados: why not? |
01:22 |
|
kados |
for several reasons |
01:23 |
|
kados |
one, we can only map one thesaurus value to a given subfield |
01:23 |
|
kados |
you can't map both NAME and NAME/TITLE too 100a |
01:24 |
|
kados |
and you can't map both TITLE and NAME/TITLE to 245a |
01:24 |
|
thd |
kados: The authority has the contents of the 130 match that or try to match to 130 in the biblo and any place else that might be relevant in case I overlook something. |
01:25 |
|
thd |
kados: 245 is not controlled. |
01:25 |
|
kados |
why not? |
01:25 |
|
kados |
shouldn't a good system have full authority control where relevant? |
01:25 |
|
thd |
kados: 245 has what is printed on the title page just as it appears. |
01:26 |
|
thd |
kados: a good system would be full of 130s in bibliographic records which are rare in the real world. |
01:27 |
|
thd |
kados: You wrote a fine book World Improvement by kados |
01:27 |
|
thd |
and that is how it is printed on the title page. |
01:28 |
|
thd |
kados: that book will have 245 $aWorld improvement$cby kados. |
01:30 |
|
thd |
kados: the main author will be controlled 100 $aFerraro, joshua Mxxx$d19XX- |
01:30 |
|
thd |
kados: some clever librarian wants to catalogue the French edition |
01:31 |
|
thd |
kadso: the clever librarian creates a uniform title in 130 $aWorld improvement |
01:33 |
|
thd |
kados: the French will have 245 $aImprovement monde or whatever that would be in French$cby( i should know the French for that) kados. |
01:35 |
|
thd |
kados: the clever librarian could have made 130 $aFerraro, Joshua Mxxx / World improvement or however that would be done |
01:35 |
|
kados |
but I thought a uniform title was only used when a title was not associated with a specific author, like the bible |
01:36 |
|
thd |
then you would have a name/title authority as a uniform title |
01:36 |
|
kados |
_as a uniform title_? |
01:36 |
|
kados |
they are different things |
01:37 |
|
kados |
a name/title authority can't _be_ a uniform title |
01:37 |
|
kados |
can it? |
01:37 |
|
thd |
kados: Uniform titles are for distinguishing the work or the expression across different editions |
01:37 |
|
kados |
is there a difference between a uniform title and a uniform title heading? |
01:37 |
|
thd |
kados: they are the same |
01:38 |
|
thd |
kados: name/tiltle is a special kind of Uniform tilte |
01:39 |
|
kados |
so if we're importing |
01:39 |
|
thd |
kados: 130 $aShakespeare/Hamlet would be different form 130 $aFerraro/Hamlet |
01:39 |
|
kados |
is it safe to say that we can check to see if there is an author listed along with a title |
01:39 |
|
kados |
and if there is, it is a NAME/TITLE |
01:40 |
|
kados |
thd: I think the above example would be written: |
01:40 |
|
kados |
100 $a Shakespheare, |
01:40 |
|
thd |
kados: you check the value of 130 in the authority record against 130 and 830 in the biblio |
01:40 |
|
kados |
$c hamlet |
01:41 |
|
thd |
kados: yes they are not common and I had not checked |
01:42 |
|
thd |
kados: uniform tile covers more than just 130 and 830 in the biblio also but I have not checked all the places |
01:43 |
|
kados |
thd: for 'Bible' the LOC authorities only has 25 entries in NAME/TITLE |
01:43 |
|
kados |
thd: none of them can be clicked on |
01:43 |
|
kados |
there are also 25 subjct headings for Bible |
01:44 |
|
kados |
same with title |
01:44 |
|
kados |
same with NAME |
01:44 |
|
thd |
kados: those are not the authority record if they cannot be clicked |
01:44 |
|
kados |
that seems like too much of a coincidence |
01:45 |
|
thd |
kados: names can also be subjects |
01:45 |
|
kados |
i koha's current scheme, if you do a 'NAME search you will not get 'TITLE entries back |
01:45 |
|
thd |
s/subjects/used as subjects/ |
01:45 |
|
kados |
same with a Subject Search |
01:46 |
|
kados |
but it seems that with LOC no matter what search you do you get the same auth files back |
01:46 |
|
thd |
kados: it is difficult to find the authorised forms because searches are left anchored |
01:46 |
|
kados |
only it picks different parts of them out for display |
01:47 |
|
thd |
kados: 600 is a subject based on a personal name |
01:47 |
|
thd |
610 corporate name subject, etc. |
01:49 |
|
thd |
kados: Bible could be in a 610 perhaps as well as a 650 it is too fundamental too know |
01:50 |
|
thd |
kados: the links that you cannot click on in authorities.loc.gov can be clicked in catalog.loc.gov |
01:50 |
|
kados |
thd: is this voyager? |
01:50 |
|
kados |
thd: that stephen thinks is so great? |
01:50 |
|
thd |
catalog.loc.gov also does not force left anchoring |
01:51 |
|
thd |
catalog is voyager but authorities could be an in house or contract job. |
01:53 |
|
thd |
kados: voyager like other OPACs is configurable or customisable. catalog.loc.gov looked much the same before they ever outsourced it. |
01:54 |
|
thd |
kados: before 2000 LC ran much of their own software. Their catalog was mostly open source but it did not do Unicode. |
01:55 |
|
kados |
it was open source? |
01:55 |
|
thd |
kados: yes I will find the link |
01:59 |
|
thd |
"the ISearch-CGI public domain software that is available from CNIDR. It should be noted that many search and retrieval capabilities that are available in the Z39.50 protocol are not implemented in this gateway. The Initialization, Search, and Retrieval facilities have been implemented." |
02:01 |
|
thd |
http://www.cnidr.org/ is probably outdated but if you google for Isearch you can find the German company that maintained a very expensive commercial version which fixed the Unicode and other problems |
02:03 |
|
thd |
CNIDR was an agency set up by the library of congress to create this for them. They also were involved with the creation of WAIS if you remember that. |
02:04 |
|
kados |
interesting |
02:05 |
|
thd |
kados: I was going to use Isearch long ago until I discovered why LC abandoned it. |
02:05 |
|
thd |
kados: It was designed for MARC records. |
02:05 |
|
kados |
heh |
02:08 |
|
thd |
kados: If Zebra did not exist Isearch would be work looking at but I have no C background. |
02:09 |
|
thd |
kados: Zebra does much more than ISearch ever imagined. |
02:10 |
|
thd |
kados: Also there were special LC modifications to ISearch so that it did what they wanted. Those modifications were not part of the public domain distribution. |
02:12 |
|
thd |
kados: prior to that most of their systems at LC were in house systems except cataloguing which is an MSDOS program made by someone whom I have spoken with who has an office in New York. |
02:14 |
|
thd |
s/that/year 2000/ |
02:16 |
|
thd |
you can still see Isearch doing some of what it had done at http://www.loc.gov/z3950/ |
02:17 |
|
thd |
kados: you woke up too early this afternoon :) |
02:20 |
|
thd |
kados: ISearch had a companion component ISite that was the backend and not part of the gateway where ISearch connects to other backends. |
02:33 |
|
thd |
good night kados |
04:23 |
|
thd |
I fixed author searching of authorities in the OPAC |
04:24 |
|
thd |
I had started to do that a few hours ago and then distracted myself |
04:25 |
|
thd |
kados: yay it works |
04:25 |
|
thd |
kados: search authors '...' for jack lewis |
04:46 |
|
thd |
kados: this was merely a bibliographic framework issue |