[Evergreen-reports] [Sales] Publication year average

[Tiffany Little]

For what it's worth, although there are definitely places in the reporter
that could make output more useful straight out of the gate, in this case
I'd advocate for just cleaning up the data in Excel. At bare minimum, just
doing a Find/Replace on copyright dates, brackets, etc could clean that
right up so you could do an easy average formula to get what you need.

Tiffany Little, PINES Bibliographic Projects Manager

------------------------------

Georgia Public Library Service

2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341

(404) 235-7161 | tlittle at georgialibraries.org

Join our email list <http://georgialibraries.org/> for stories of Georgia
libraries making an impact in our communities.


On Fri, Feb 16, 2024 at 2:29 PM Terran McCanna via Evergreen-reports <
evergreen-reports at list.evergreen-ils.org> wrote:

> If you create a Wish List bug in Launchpad, I'll add heat to it :)
>
> On Fri, Feb 16, 2024 at 2:23 PM Blake Graham-Henderson via
> Evergreen-reports <evergreen-reports at list.evergreen-ils.org> wrote:
>
>> All,
>>
>> Thanks for your considerate responses. What Mike said is the conclusion
>> I had come to, and I was wondering if anyone else needs the publication
>> year to be an actual number so that the reporter can do things like
>> average,min,max,etc. From the sounds of it, no one is currently using
>> the Evergreen reporter to produce such a thing (I don't see how you
>> could). I suppose no one is using an external program to make it happen
>> (to meet collection reporting needs from the higher-ups)?
>>
>> I agree with Mike, in that the best place to get the publication year
>> (right now) is the Simple Record Extracts, because it hunts it down from
>> several places in the bib record. Walking it backwards:
>>
>> reporter.materialized_simple_record -> reporter.old_super_simple_record
>> -> metabib.wide_display_entry -> metabib.compressed_display_entry ->
>> metabib.flat_display_entry -> metabib.display_entry
>>
>> Which is a trigger-created-table based upon the index definition found
>> in config.metabib_field
>>
>> one of those views is hardcoded to expect "pubdate" to exist in the
>> metabib_field definitions. Which exists with stock Evergreen
>> definitions. Which is:
>>
>>
>> "//mods33:mods/mods33:originInfo//mods33:dateIssued[@encoding="marc"]|//mods33:mods/mods33:originInfo//mods33:dateIssued[1]"
>>
>> Decoding that is fun. Suffice it to say: the pubyear can come from
>> several places in the record, and I like that better than only looking
>> in one place.
>>
>> So, in conclusion, if a patch were written, I think it would be smart to
>> piggy back on this logic. It might be fairly straightforward to get the
>> first occurrence from the JSON string and cast it to an integer
>> (stripping out non-numeric characters first). That's where my thoughts
>> are right now. I don't think we're going to be writing the patch anytime
>> soon, just thinking through it with everyone.
>>
>> If everyone agrees that this is something that Evergreen should have,
>> and we agree on the method, I might champion the bug and patch for
>> future meetings and releases!
>>
>> -Blake-
>> Conducting Magic
>> Will consume any data format
>> MOBIUS
>>
>> _______________________________________________
>> Evergreen-reports mailing list
>> Evergreen-reports at list.evergreen-ils.org
>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-reports
>>
> _______________________________________________
> Evergreen-reports mailing list
> Evergreen-reports at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-reports
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-reports/attachments/20240219/50ed58a4/attachment.htm>