Re: [Archivesspace_Users_Group] Changes to PDF export in 2.8?
Lora, Mark, Thank you both! Moving the variable did fix the issue, and now I feel a bit sheepish for focusing on the './ead' segment of the error report, not the 'fn:substring' part. I may make more of the refinements Mark suggested later on, but it's working for now, which is the important part. Thanks for the help tracking that down. Best, Chris On Tue, Aug 18, 2020 at 6:12 PM Custer, Mark wrote: > Chris, Lora: > > Okay, so I just did a bit more digging (but not enough yet), and I'd say > that there must either be a bug in the gem or in the way that it's invoked > (I'm leaning toward the latter, but I haven't looked at the ASpace code > yet). Whatever the issue is, it's not what I speculated the first time > around. > > Chris, like you, I have no problems when running this stylesheet with any > version of saxon outside of ArchiveSpace, and most everything looks fine > with how you have things set up. I say "most everything looks fine" only > because that $repo variable could select multiple values if you had, say, > a "num" element hand-encoded in the primary finding aid title, and if you > did, you'd get an error when trying to run the substring function anyway, > since that function will always require a single string and never multiple > items in a sequence. I'd probably change that same Xpath expression to > look for the call number in the archdesc/did/unitid[1] area instead, just > to play it safe. Also because I think it's strange that ASpace serializes > the unitid to the finding aid title, but that might just be me . > > The issue here, I think, is that you cannot set a global variable in the > XSLT stylesheets in ASpace 2.8. Luckily the default ones don't do that > (although I'm surprised, since I do that all the time ), but you should > definitely have the option to do that, as you did before. Actually, it > looks like the EAC-to-HTML one does declare at least one global variable, > but that transformation is not used anywhere in ASpace I don't think, so no > worries. > > But in the meantime, you can get things working again as Lora just > mentioned, by moving your repo variable inside of the "publicationstmt" > template instead. That's the important part right now; good find, Lora! > > Mark > > > > > > -- > *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org < > archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of > Lora Woodford > *Sent:* Tuesday, August 18, 2020 5:07 PM > *To:* Archivesspace Users Group < > archivesspace_users_group@lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] Changes to PDF export in 2.8? > > > And, as soon as I sent this, I found where that repo variable is being set > up at line 126 of your xsl. If you move that down into the publicationstmt > template starting on ln 358 you should be golden. > > > > Lora > > > > *From: * on > behalf of Lora Woodford > *Reply-To: *Archivesspace Users Group < > archivesspace_users_group@lyralists.lyrasis.org> > *Date: *Tuesday, August 18, 2020 at 4:39 PM > *To: *Archivesspace Users Group < > archivesspace_users_group@lyralists.lyrasis.org> > *Subject: *Re: [Archivesspace_Users_Group] Changes to PDF export in 2.8? > > > > Hi Chris, > > I took a quick look at this, and I do think Mark’s instinct is correct. > It seems an existing (custom to you folks) function in your xsl isn’t > working with the recent updates/transition to saxon-rb. > > My XSL is pretty rusty these days, but the following lines (ln 364-371) in > your as-ead-pdf.xsl are the culprits: > > > > > > > Irish Music Archives > > > > > > > > > > > > > > The error “The context item for axis step ./ead is absent. Found while > atomizing the first argument of fn:substring()” points to the fact that the > transformation no longer knows how to handle the $repo provided as the > first argument in that substring function. For what it’s worth, removing > this customization from your stylesheet (only this customization) results > in being able to successfully export/print pdfs over here. > > I’ll keep poking, but wanted to give you this partial update sooner rather > than later. > > > > Lora > > > > *From: * on > behalf of Chris Mayo > *Reply-To: *Archivesspace Users Group < > archivesspace_users_group@lyralists.lyrasis.org> > *Date: *Monday, August 17, 2020 at 3:04 PM > *To: *Archivesspace Users Group < > archivesspace_users_group@lyralists.lyrasis.org> > *Subject: *Re: [Archivesspace_Users_Group] Changes to PDF export in 2.8?
[Archivesspace_Users_Group] Changes to PDF export in 2.8?
Hi all, We keep a modified in-house version of the ead-to-pdf stylesheet so that we can put out Finding Aids with our own branding and a few other changes. When we recently installed 2.8 on our test server, we discovered that the export to PDF job was failing with the following error info: "The context item for axis step ./ead is absent. Found while atomizing the first argument of fn:subst" Our production server is currently running on 2.6, and we had previously updated the test server to 2.7 without that upgrade breaking our stylesheet, so the issue appears to have been introduced between 2.7 and 2.8. As far as I can tell, the base code for the stylesheet didn't change between those versions, and while the error message looks like an Xpath problem, the EAD structure doesn't appear to have changed either. Has anyone else encountered problems with modified finding aid stylesheets in 2.8, or have any thoughts on what could be causing this error? Chris Chris Mayo Digital Production Librarian Boston College chris.m...@bc.edu pronouns: they/them/theirs ___ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
Re: [Archivesspace_Users_Group] help with API route for archival object notes
Hi Karen,
To be a little more specific, I'm getting the sense (since I've struggled
with needing to update some notes but not others as well) that what you're
asking is how to create the path to a specific note when you don't know in
advance which note it's going to be.
If you want to only modify notes that have html tags in them, you'll need
to give it the path to ['notes'] part of the structure, and then run a
for-loop, since that part is a list. You can ask it to look at each note in
the list of notes and only make changes if it comes across one of the bad
tags you're looking for. In python this would look something like
for note in json['notes']
if 'bad tag' in note:
modify the note
I'm afraid that I am enough of a scripter to only use Python to interact
with the API, if you're using Postman or anything like that I'm not
entirely sure how you'd accomplish something like this, and maybe somebody
else can advise.
The thing that was hardest for me about learning how to interact with JSON
was coming to realize that as far as the scripting language is concerned,
anything inside square brackets [ ] is a list, and anything inside curly
braces { } is a dictionary, and they can be interacted with as those data
types.
Hope that helps, and sorry if I misread what your problem was!
Chris
On Tue, Jun 30, 2020 at 7:35 PM James Bullen wrote:
>
> Hi Karen,
>
> The general rule is that anything you can GET from a uri can be modified
> and POSTed back to update it.
>
> So, GET the JSON for the archival_object as you are doing. Then modify the
> JSON (in this case the notes bit of it) to look how you want. Then POST it
> back to the same uri.
>
> Notes are nested subrecords (as are dates and others). These don’t have a
> life of their own, they are really just repeating parts of the top level
> record that they are contained within.
>
> Hope that helps..
>
>
> Cheers,
> James
>
>
> On Jul 1, 2020, at 8:22 AM, Karen Miller
> wrote:
>
> Good morning, ArchivesSpace users.
>
> I am a cataloger (*not* a developer) using the API to update
> ArchivesSpace. So far I’ve figured out how to add LCCNs to the authority_Id
> of Agent records and do a couple more updates that, in retrospect, were
> pretty simple.
>
> The next task I’d like to tackle, however, just seems like maybe it can’t
> be done. We’ve got a lot of notes with html tags in them and I would like
> to update those to valid tags. I can get the JSON for the notes in any
> particular archival object, but I don’t know how to specify the route to
> the note to change it. The JSON looks like this:
>
> 'notes': [{'content': ['This is a note with a bad tag'],
> 'jsonmodel_type': 'note_singlepart',
> 'persistent_id': '75ba0ec57e374b8b154551a69b4c311f',
> 'publish': True,
> 'type': 'abstract'},
>{'jsonmodel_type': 'note_multipart',
> 'persistent_id': '66afa07b3214260078123236bbe1ff27',
> 'publish': True,
> 'subnotes': [{'content': 'This is a dippy note.',
> 'jsonmodel_type': 'note_text',
> 'publish': True}],
> 'type': 'scopecontent'}],
>
> I got this using the route ‘repositories/10/archival_objects/489763’, but
> I don’t know how to specify the note that I want in the JSON. For the agent
> authority_id I used the route ‘‘/agents/people/ and specified
> the field like this:
>
> ['names'][0]['authority_id']
>
> I’m hoping this is an easy question for somebody with more experience with
> the API and (especially) with JSON than I. I’m a little afraid the answer
> is that it can’t be done. Any advice will be appreciated!
>
> Karen
>
> *Karen D. Miller*
> Monographic Cataloger/Metadata Specialist
> Northwestern University Libraries
> Northwestern University
> 1970 Campus Drive
> Evanston, IL 60208
> www.library.northwestern.edu
> k-mill...@northwestern.edu
> 874.467.3462
>
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
--
Chris Mayo
Digital Production Librarian
Boston College
chris.m...@bc.edu
pronouns: they/them/theirs
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
Re: [Archivesspace_Users_Group] PDF Export Logo Issue
Hi Bailey, My institution doesn't use the PUI, so I can't really speculate about why there's a difference between the staff and public interfaces. That being said, the appearance of the PDFs are controlled by the as-ead-pdf.xsl stylesheet, and I've noticed in the past that it's really easy for the logos to break for a number of reasons: - if the logo file gets renamed or goes missing during a software update - if you're modifying the stylesheet for other reasons and accidentally comment out, delete, or modify the part that calls for the logo file I don't know if either of those is the case in your application, but I'd start with looking at the stylesheet and logo files and making sure they're all cross-referencing properly. Best, Chris On Thu, Jun 4, 2020 at 11:37 AM Hoffner, Bailey E. wrote: > Morning All, > > > > We have an odd issue where our branding image does not show up on the PDF > that can be exported from the public interface, but it does show up on the > PDF that can be exported from the staff interface. The ArchivesSpace logo > no longer shows up, but neither does the branding image. > > > > Any suggestions? Has anyone had an issue like this before? > > > > Thanks! > > > > -Bailey > > > > Bailey Hoffner, MLIS > > Metadata and Collections Management Archivist > > University of Oklahoma Libraries > > 405-325-1566 > > > ___ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group@lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -- Chris Mayo Digital Production Librarian Boston College chris.m...@bc.edu pronouns: they/them/theirs ___ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
Re: [Archivesspace_Users_Group] Component unique identifiers
Hi Adrienne, We ran into a similar issue at Boston College when we migrated from to ASpace from Toolkit. Our practice had been to combine the collection ID with an auto-generated refID to create component unique identifiers, but the auto-generated refIDs in Aspace were much too long for our needs. What we eventually wound up doing is using the database primary key for a given archival object as the unique part of its component unique ID, so that any given for an archival object we're planning to digitize gets a CUI with the format of 'mmsID_N" where the numerical portion is pulled from the 'archival_object_N' at the end of the archival object's URL. The really handy part of this is that it lets us parse our CUIs to make API calls. It's also robust to rearrangement, if you are only moving the archival object around within the collection hierarchy - the database key remains the same. It doesn't survive reprocessing, however, if you are deleting/rebuilding/combining archival objects, so we always make sure to begin the process of digitization after a collection has been processed or reprocessed. It makes the CUIs somewhat semantically meaningful - but only if you know what you are looking at. We're still not sure how we feel about that, but it's what works for us for now. Hope that helps! Best, Chris On Mon, Nov 5, 2018 at 11:00 AM Pruitt, Adrienne wrote: > Hello, all, > > We’re hoping to move away from semantically meaningful component unique > identifiers, but need some way to be able to easily auto-generate a unique > identifier that could be used for file-naming purposes in digitization > projects. Working with legacy data, we have seen that there can be value in > being able to easily associate a binary file floating around on a server > somewhere with a relatively easily parsed identifier that links it to its > related metadata. However, semantically meaningful identifiers based on > collection structure are a rather brittle system prone to breaking when > collections are rearranged or reprocessed and easy to mis-enter when > working with so many digits. We’re interested to hear how others are > handling their identifiers (particularly in regards to digitization > workflows.) > > Thank you! > > *Adrienne Pruitt *| Collections Management Archivist > Digital Collections and Archives > Tufts University > adrienne.pru...@tufts.edu |617-627-0957 > ___ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group@lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -- Chris Mayo Digital Production Librarian Thomas P. O'Neill, Jr. Library Boston College chris.m...@bc.edu ___ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
[Archivesspace_Users_Group] Size limitation in 'FiIe Size (bytes)' field
Hi folks, I wanted to reach out to the list with what seems to be a database limitation we've run up against lately, and see if it's affecting anyone else. At BC, we use Aspace to generate structural metadata for our digitized collections, so we're storing information about individual digital files as Digital Archival Object Components. We decided recently (for various reasons) to start storing more of the technical metadata for each file, like checksums, filesize, format, etc. in the file version area of the DAO component. We've also recently undertaken a grant project to digitize some old reel-to-reel audio recordings, which means that we're characterizing large AV files for the first time, and we started getting an error when building some of the components stating: "Data truncation: Out of range value for column 'file_size_bytes'". It took a while to figure out what was going on, but as best as we can determine, the database is using a 32-bit integer to store this field, which means that the largest number that can be stored in the field is ~2.15 billion. Since the label of the field specifically notes that this measurement should be in bytes, it means that the field can only be used to describe files that are about 2.2Gb or smaller, and many of our audio files are above this limit. Has anyone else run into this problem, or have any ideas of how it can be dealt with? We'd prefer to keep describing size in bytes due to the granularity and specificity that allows. I'm using the API to build our DAOs, so currently I've just added a sanity check in my script to leave that field for files that are too large, but we'd like to be able to get that data in someday. Thanks, Chris -- Chris Mayo Digital Production Librarian Thomas P. O'Neill, Jr. Library Boston College chris.m...@bc.edu ___ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
