Partner attribution tag

[srabun]

Linda has this on her to-do as well, but with hydra in play, feel free to look into this if time allows:

Some of our partners want an additional tag to be visible somewhere on the webpage when users are viewing their content in the viewer that says something like: "Digitized in partnership with: X organization"

similar to the "Image provided by: University of Oregon Libraries; Eugene, OR" that is present on the top left side of the viewer.

[lsat12357]

ok, how about something like this: generate list of page ids for the pages in question insert records into the core_pagenote table, something like the following: id, label, text, type, pageid "Oregon Historical Society", "ohs", "partner", 18495 modify browse.py (in oregon/views) so that the page pulls the partner notes out of the database modify the page template (in oregon/templates) so that if the partner note exists, it will display with appropriate text

[kestlund]

Rather than modify the data in the database, is there a way to print an existing metadata field, as well?

So under, "Image provided by: University of Oregon Libraries; Eugene, OR," print out "Source Repository: [x]" where x is "Original Source Repository". (See page 17 for metadata field in spec: http://www.loc.gov/ndnp/guidelines/archive/NDNP_201113TechNotes.pdf)

[duncanbarth]

I'd like to see an implementation that avoids adding fields to the database, if at all possible.

A database schema change has implications for unrelated parts of the app (at a minimum, the ingest process would have to be modified to populate the records), but also gets pretty ugly the next time we sync up with the chronam codebase.

From Karen's comment, I'm hoping the information is already loaded there.

[kestlund]

The original source repository gets translated to this xml field in the [lccn].xml file: <mods:physicalLocation authority="marcorg" displayLabel="University of Oregon Libraries; Eugene, OR">oru</mods:physicalLocation>

There could possibly be a constraint on the system for only orgs with Marc codes. If that is the case, then that is definitely something that states would be interested in removing, in order to use the software more broadly. Here are links to the marc codes: http://www.loc.gov/marc/organizations/org-search.php or http://id.loc.gov/vocabulary/organizations.html

@srabun , can we try modifying a sample batch and loading on dev to see if it works?

[jechols]

I think we'll need to put some time on this before we do any quick hacks. It might be super easy if we already have the necessary data, but if we are looking at schema changes, it could turn into a huge issue....

[jechols]

Okay, I think we misread @lsat12357 's suggestion - that might be the right approach. I somehow thought she wanted to add fields and I have no idea how or why I thought that.

@duncanbarth is still correct about the ingest process, though - we'd need to modify how we ingest stuff in order to populate this field moving forward. There may still be other options worth investigation, I'm still hoping somehow the data is already there... (though this doesn't seem to be the case in a cursory look at the db)

[lsat12357]

sorry, i should have provided more context for my solution. I assumed that there would be a simple solution, something akin to what Karen suggested. However, the batch_loader code only grabs stuff like issue number, volume number etc for building the issue object; the awardee information is not read from the xml, but by parsing the batch name, which for us always has oru in it. The batch loader DOES however grab all mods:notes, and there are notes tables for both issues and pages. Once the data is in either the pages or issues notes table, it is simple to retrieve it and display it on the page; the only code modified is in the oregon folder.

[kestlund]

I'm hoping no schema changes, but we'll see. Let's see what happens with Sheila's test batch.

On Thu, Oct 30, 2014 at 10:10 AM, Jeremy Echols notifications@github.com wrote:

I think we'll need to put some time on this before we do any quick hacks. It might be super easy if we already have the necessary data, but if we are looking at schema changes, it could turn into a huge issue....

— Reply to this email directly or view it on GitHub https://github.com/uoregon-libraries/oregonnews/issues/4#issuecomment-61129947 .

[srabun]

Ok, I tried a few things.

1) tried adding a mods:note with type="SourceRepositoryInstitution" (which we made up) to the IssueModsBib section of an issue xml file, but it did not validate because "issue mods contains non-required element":

2) tried adding a mods:note with type="SourceRepositoryInstitution" to a pageModsBib section, and it failed to validate, because "page mods must have 3 or 4 children". Here is what I added:

3) As an experiment, I changed the mods:physicalLocation field to the Grand Ronde Tribes (typically it's Univ. of Oregon Libraries), and since the Original Source Repository Code field is only mandatory if available, I replaced that part with a string, see here: And this validated! However, reading everyone's notes above I know this is not really a solution because we would still have to figure out how to get this metadata field to print.

Good news is, now we know that for this field, it doesn't matter if the organization has a marc org code or not...

[srabun]

FYI I also experimented with adding a mods:note to the reel xml, but that didn't work either...

So adding a mods:note is not doable it seems. It is possible to edit the existing note for type="agencyResponsibleForReproduction" in the pageModsBib for an issue xml like so: However, this would not be accurate since we are the agency responsible, plus, how would we get it to print? plus, if we could get it to print, it is present in all batches so it would print for every single page even though the majority of the pages would say "University of Oregon Libraries..."

Does this make sense? Basically, at this point, I just need to know what I need to edit in the test batch that would make the most sense and be the best place to start, since adding a mods:note is not an option...any thoughts?

[kestlund]

When you say mods note is not an option, do you mean that the DVV balks at validation?

On Fri, Oct 31, 2014 at 12:32 PM, srabun notifications@github.com wrote:

FYI I also experimented with adding a mods:note to the reel xml, but that didn't work either...

So adding a mods:note is not doable it seems. It is possible to edit the existing note for type="agencyResponsibleForReproduction" in the pageModsBib for an issue xml like so: [image: screen shot 2014-10-31 at 12 28 42 pm] https://cloud.githubusercontent.com/assets/8322525/4867354/3edcb5a4-6134-11e4-9c7f-fcda2879155c.png However, this would not be accurate since we are the agency responsible, plus, how would we get it to print? plus, if we could get it to print, it is present in all batches so it would print for every single page even though the majority of the pages would say "University of Oregon Libraries..."

Does this make sense? Basically, at this point, I just need to know what I need to edit in the test batch that would make the most sense and be the best place to start, since adding a mods:note is not an option...any thoughts?

— Reply to this email directly or view it on GitHub https://github.com/uoregon-libraries/oregonnews/issues/4#issuecomment-61317307 .

[srabun]

Correct, when I add a mods:note to an issue xml and then try to validate with the DVV, validation fails

[kestlund]

@lsat12357 @jechols , would we have to significantly modify the core to have the batch loader ingest <mods:physicalLocation">?

Still would probably have marc code error though, huh?

[jechols]

This needs a bigger discussion, I think - I can't really comment on the work involved with what I know (and don't know) right now

[kestlund]

What are your questions for the bigger discussion?

On Fri, Oct 31, 2014 at 2:14 PM, Jeremy Echols notifications@github.com wrote:

This needs a bigger discussion, I think - I can't really comment on the work involved with what I know (and don't know) right now

— Reply to this email directly or view it on GitHub https://github.com/uoregon-libraries/oregonnews/issues/4#issuecomment-61332707 .

[jechols]

I have spent literally no time on this other than reading the ticket briefly and skimming responses. I don't know anything about what we have, data-wise. I don't know the ramifications of changing code or data. I didn't even know the data wasn't already in the XML and/or database somewhere.

It's very likely @lsat12357 can handle this if she has the time - she knows way more about this situation than I do. But if it's something for me to tackle, it needs to be prioritized and discussed. It's really not time-efficient for me to try and discuss this all in github comments.

[srabun]

Ok, I copied a small test batch to the server "batch_oru_attribtag" containing the following data in both the issue xmls and reel xml:

<mods:physicalLocation authority="marcorg" displayLabel=“The Confederated Tribes of the Grand Ronde; Grand Ronde, OR”>The Confederated Tribes of the Grand Ronde/mods:physicalLocation

@lsat12357 we can play with this batch to see if we can get this field to print or what. We'll see how it goes and if we can't figure it out we'll schedule a meeting with @jechols to prioritize and discuss further.

Thanks! :)

[srabun]

The test batch for altering/pulling from batch name and added table fields is now on the server and ready to go: "batch_confederatedtribesofgrandronde_test". The actual batch name in the batch xml is "batch_confederatedtribesofthegrandronde_test" and the tag should appear as "The Confederated Tribes of the Grand Ronde; Grand Ronde, OR"

[srabun]

I think we have mastered this now. Can we close this ticket? Or would there be a better way to do this in the future (would require a major overhaul...)

[jechols]

I think we can close this. Doing it right is already under discussion in #27.