Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save authority record with a 155 field

2018-11-07 Thread Linda Jansova

Hi,

a little update - Nate Trail from the LC has promised to fix it:

https://listserv.loc.gov/cgi-bin/wa?A2=MODS;692400d8.1811

:-)

Linda

On 11/7/18 11:11 AM, Linda Jansova wrote:

Dear all,

We have updated the XSLT (with swapped lines 1084 and 1085 as Josh 
suggested) using the following command: 
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/955.data.MADS21-xsl.sql. 
Then we performed all steps that the upgrade from 2.12.6 to 3.1.4 
requires. Everything (including the reingest) has been completed 
successfully :-).


On Monday November 5th, I sent a message to MODS (MADS) mailing list 
regarding the troublesome lines in the XSLT file:


https://listserv.loc.gov/cgi-bin/wa?A2=MODS;fd3eba0f.1811

There is no response yet but I do hope that someone from the LC will 
eventually respond.


Linda

On 11/1/18 7:29 AM, Linda Jansova wrote:

Thank you, Josh!

We shall try and go through the reingest of all records and if no 
other XSLT-related issues appear, I can get in touch with MADS folks 
through their listserv and report the error.


Linda

On 10/31/18 4:59 PM, Josh Stompro wrote:
Hello Mike, I've created a bug for this issue to get it in the 
queue.  LP#1800871


Josh Stompro - LARL IT Director


-Original Message-
From: Open-ils-general 
 On Behalf Of 
Mike Rylander

Sent: Wednesday, October 31, 2018 10:09 AM
To: Evergreen Development Discussion List 

Cc: Evergreen Discussion Group 

Subject: Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save authority 
record with a 155 field


Hi Linda and Josh,

Great work figuring that out! We should definitely report this 
upstream to the MODS/MADS folks, but we maintain a local copy of the 
XSLT (altered to work without external file or network access for xml
includes) and can fix it locally.  I don't have time right now to 
jump on it, but both the file on the filesystem and the version in 
the config.xml_transform table in the db should be corrected.


Thanks!
--
Mike Rylander
  | Executive Director
  | Equinox Open Library Initiative
  | phone:  1-877-OPEN-ILS (673-6457)
  | email:  mi...@equinoxinitiative.org
  | web:  http://equinoxinitiative.org

On Wed, Oct 31, 2018 at 10:58 AM Josh Stompro 
 wrote:

Linda, I wonder if this is a bug in the MARCslim2MADS.xslt?  The error
message is



runtime error: file ./MARC21slim2MADS.xsl line 1404 element attribute

xsl:attribute: Cannot add attributes to an element if children have 
been already added to the element.




I agree that it looks like the problem is when the xslt is 
processing the 755 and trying to set the authority source.




I think the bug may be that when processing the 755 tag on line 
1081, the genre template is called before the setAuthority 
template.  The Genre template adds child elements, then the 
setAuthority tries to set attributes, which is where the error pops 
up.




If I swap lines 1084 and 1085 then the error goes away and both the 
genre(155) and related genre(755) show up in the transformed xml.




I think the way to report this to the MADS project is via the MODS
listserv, as listed on http://www.loc.gov/standards/mads/



I don’t have enough experience with these technologies to be all 
that confident that this is the issue though.  I would be happy to 
report this to the MODS listserv if it seems to make sense to 
someone that is more familiar with mods/mads/xml/authorities.




Josh Stompro - LARL IT Director



From: Linda Jansova 
Sent: Wednesday, October 31, 2018 7:16 AM
To: Evergreen Discussion Group
; Josh Stompro
; Evergreen Development Discussion List

Subject: Re: [OPEN-ILS-GENERAL] Cannot save authority record with a
155 field



Dear Josh,

Thank you for letting me know about the right XSL file!

After some more investigations I have come to a conclusion that it 
is not actually a 155 field which causes the problem but a 755 
field. If it has any value in second indicator, xsltproc fails to 
process it. When the indicator does not have any value (or, to be 
more precise, there is just a space), it is okay.


So far, it seems that we will have to get rid either of the values 
of indicators in 755s, or of the following part of the XSL file:


 test="(700 = 
ancestor-or-self::marc:datafield/@tag and 
ancestor-or-self::marc:datafield/@tag = 755 ) and @ind2='7'">

 
 
 
 

Hopefully it will work for us and let us proceed in the upgrade :-)!

Linda

On 10/30/18 9:38 PM, Josh Stompro wrote:

Hello Linda, I think the Authority ingest uses the 
MARC21slim2MADS.xsl transform file to convert the authority data 
into MADS format.  Could you try manually processing your problem 
authority record using the MADS file instead of the MODS and see 
what you get.




The MADS xsl does look like it references tag 155.



Josh Stompro - LARL IT Director



From: Open-ils-general
 On Behalf Of
Linda Jansova
Sent: Friday, October 26, 2018 5:29 AM
To: Evergreen Discussion 

Re: [OPEN-ILS-GENERAL] [External] Re: Towards more consistent terminology in the web client

2018-11-07 Thread Sarah Childs
I'm working on Indiana docs for 3.2, and I have a few questions comments on
where we landed on the terminology. Overall it seems a lot more consistent.
The copies/items issue seems like it was fully stamped out. Hooray!

I notice we have Holdings for the Add Holdings button and the Holdings
Editor, but on the menus where we have all the options of Call Numbers and
Items, shouldn't those also be Holdings? I think people will quickly come
to understand that Holdings means Call Numbers and Items.  It seems weird
to have Holdings in just a couple of places.

But my biggest beef is the Transfer Call Numbers to Previously Marked
Destination menu option. Now that most of the rest of the Actions have
three options: Items, Call Numbers, & Both, Transfer Call Numbers sounds
like it means transfer Call Number ONLY, when in fact it is Both.


On Fri, Aug 17, 2018 at 9:51 AM Patrick, Irene 
wrote:

> One’s view on this probably depends greatly on background.  I strongly
> disagree that using volume as terminology is Stockholm syndrome.  We’ve
> been on Evergreen for over a year now, but prior to that we were on Voyager
> for 15 years.  Voyager had a roughly similar structure.  In Voyager, the
> structure was bib record, MFHD or volume record, and item record.  The bib
> record was obviously the MARC record, the MFHD/volume record stored the
> location and call number, and all the items that shared the same location
> and call number were attached to that volume record.  Using volume as the
> term for the intermediate layer makes perfect sense to me.  I prefer it to
> using “call number” because call number to me is an attribute of something
> else, not an entity of its own to which items can be attached.
>
>
>
> Evergreen’s structure is obviously not exactly the same, and since we are
> now part of a consortium which was set up long before we came on board, I
> don’t have full understanding of how the underlying structure was set up.
> Even so, “call number record” just doesn’t feel right to me.
>
>
>
> Before Voyager, we were on Dynix, which only had bibs and items, so it
> wasn’t even an issue there.
>
>
>
>
>
> *Irene Patrick*
>
> Library & Information Management Systems Librarian
>
> NC Dept. of Natural and Cultural Resources
>
> 919.807.7413  |  irene.patr...@ncdcr.gov
>
>
>
>
>
> 109 E. Jones St.  | 4640 Mail Service Center
>
> Raleigh, North Carolina 27699-4600
>
> Facebook   Twitter
>   YouTube
>   Website
> 
>
>
>
> *Email correspondence to and from this address is subject to the North
> Carolina Public Records Law and may be disclosed to third parties.*
>
>
>
>
>
>
>
> *From:* Open-ils-general [mailto:
> open-ils-general-boun...@list.georgialibraries.org] *On Behalf Of *Daniel
> Wells
> *Sent:* Thursday, August 16, 2018 7:10 PM
> *To:* Evergreen Discussion Group <
> open-ils-general@list.georgialibraries.org>
> *Subject:* [External] Re: [OPEN-ILS-GENERAL] Towards more consistent
> terminology in the web client
>
>
>
> *CAUTION:* External email. Do not click links or open attachments unless
> verified. Send all suspicious email as an attachment to Report Spam.
> 
>
>
>
> Hello all,
>
>
>
> Very happy to see the term "Holding" getting some traction.  I would also
> agree that changing the record-level "Add Copies" button to "Add Holdings"
> makes a lot of sense!
>
>
>
> Furthermore, after 9 days of suspense, I have finally found time to unveil
> the one term I feel has been misused in Evergreen since the beginning:
> volume!  Hopefully there are some like-minded folks to whom this is no
> surprise.  To others, I offer the following somewhat long explanation, and
> also to help the busy and impatient, here is the summary conclusion.
> "Volume" is a word for a physical thing (i.e. something with "volume"), and
> we already have two established words for that (item/copy), so it is of no
> obvious use to us.  Volume, be gone!
>
>
>
> You may be thinking that's just, like, my opinion, so to that I offer the
> following quote from the American Library Association Fact Sheet:
>
>
>
> "The ARL *academic library* study takes its definition of volume from the 
> National
> Information Standards Organization  (NISO): A
> single physical unit of any printed, typewritten, handwritten,
> mimeographed, or processed work, distinguished from other units by a
> separate binding, encasement, portfolio, or other clear distinction, which
> has been *cataloged, classified, and made ready for use*, and which is
> typically the unit used to charge circulation transactions."
>
>
>
> With this single quote, we've got the ALA, the ARL (Association of
> Research Libraries), and NISO all agreeing on usage of the term "volume"
> to be the physical "things" in our library collections.  That's some pretty
> good authority, I think.  And when the ALA Fact Sheet then tells us the
> 

Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save authority record with a 155 field

2018-11-07 Thread Linda Jansova

Dear all,

We have updated the XSLT (with swapped lines 1084 and 1085 as Josh 
suggested) using the following command: 
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/955.data.MADS21-xsl.sql. 
Then we performed all steps that the upgrade from 2.12.6 to 3.1.4 
requires. Everything (including the reingest) has been completed 
successfully :-).


On Monday November 5th, I sent a message to MODS (MADS) mailing list 
regarding the troublesome lines in the XSLT file:


https://listserv.loc.gov/cgi-bin/wa?A2=MODS;fd3eba0f.1811

There is no response yet but I do hope that someone from the LC will 
eventually respond.


Linda

On 11/1/18 7:29 AM, Linda Jansova wrote:

Thank you, Josh!

We shall try and go through the reingest of all records and if no 
other XSLT-related issues appear, I can get in touch with MADS folks 
through their listserv and report the error.


Linda

On 10/31/18 4:59 PM, Josh Stompro wrote:
Hello Mike, I've created a bug for this issue to get it in the 
queue.  LP#1800871


Josh Stompro - LARL IT Director


-Original Message-
From: Open-ils-general 
 On Behalf Of 
Mike Rylander

Sent: Wednesday, October 31, 2018 10:09 AM
To: Evergreen Development Discussion List 

Cc: Evergreen Discussion Group 

Subject: Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save authority 
record with a 155 field


Hi Linda and Josh,

Great work figuring that out! We should definitely report this 
upstream to the MODS/MADS folks, but we maintain a local copy of the 
XSLT (altered to work without external file or network access for xml
includes) and can fix it locally.  I don't have time right now to 
jump on it, but both the file on the filesystem and the version in 
the config.xml_transform table in the db should be corrected.


Thanks!
--
Mike Rylander
  | Executive Director
  | Equinox Open Library Initiative
  | phone:  1-877-OPEN-ILS (673-6457)
  | email:  mi...@equinoxinitiative.org
  | web:  http://equinoxinitiative.org

On Wed, Oct 31, 2018 at 10:58 AM Josh Stompro 
 wrote:

Linda, I wonder if this is a bug in the MARCslim2MADS.xslt?  The error
message is



runtime error: file ./MARC21slim2MADS.xsl line 1404 element attribute

xsl:attribute: Cannot add attributes to an element if children have 
been already added to the element.




I agree that it looks like the problem is when the xslt is 
processing the 755 and trying to set the authority source.




I think the bug may be that when processing the 755 tag on line 
1081, the genre template is called before the setAuthority 
template.  The Genre template adds child elements, then the 
setAuthority tries to set attributes, which is where the error pops up.




If I swap lines 1084 and 1085 then the error goes away and both the 
genre(155) and related genre(755) show up in the transformed xml.




I think the way to report this to the MADS project is via the MODS
listserv, as listed on http://www.loc.gov/standards/mads/



I don’t have enough experience with these technologies to be all 
that confident that this is the issue though.  I would be happy to 
report this to the MODS listserv if it seems to make sense to 
someone that is more familiar with mods/mads/xml/authorities.




Josh Stompro - LARL IT Director



From: Linda Jansova 
Sent: Wednesday, October 31, 2018 7:16 AM
To: Evergreen Discussion Group
; Josh Stompro
; Evergreen Development Discussion List

Subject: Re: [OPEN-ILS-GENERAL] Cannot save authority record with a
155 field



Dear Josh,

Thank you for letting me know about the right XSL file!

After some more investigations I have come to a conclusion that it 
is not actually a 155 field which causes the problem but a 755 
field. If it has any value in second indicator, xsltproc fails to 
process it. When the indicator does not have any value (or, to be 
more precise, there is just a space), it is okay.


So far, it seems that we will have to get rid either of the values 
of indicators in 755s, or of the following part of the XSL file:


 test="(700 = 
ancestor-or-self::marc:datafield/@tag and 
ancestor-or-self::marc:datafield/@tag = 755 ) and @ind2='7'">

 
 
 
 

Hopefully it will work for us and let us proceed in the upgrade :-)!

Linda

On 10/30/18 9:38 PM, Josh Stompro wrote:

Hello Linda, I think the Authority ingest uses the 
MARC21slim2MADS.xsl transform file to convert the authority data 
into MADS format.  Could you try manually processing your problem 
authority record using the MADS file instead of the MODS and see 
what you get.




The MADS xsl does look like it references tag 155.



Josh Stompro - LARL IT Director



From: Open-ils-general
 On Behalf Of
Linda Jansova
Sent: Friday, October 26, 2018 5:29 AM
To: Evergreen Discussion Group
; Evergreen Development
Discussion List 
Subject: [OPEN-ILS-GENERAL] Cannot save authority record with a 155
field



Hi,

back in August we started investigating why we couldn't