From: Tod O. <to...@uc...> - 2012-03-07 18:14:44
|
We have a minor issue with the default setup for the Solr edition field, and I'm wondering whether I should solve this purely locally, or offer up a patch. The edition field is defined as not multiValued, but our local practice is to index both the 250‡ab (Edition Statement) and the 254‡a (Musical Presentation Statement) as edition information. So locally I'll change the Solr schema.xml and override core.tpl in the templates that we use. But if this seems useful to other sites, I can submit a patch. Let me know. -Tod Tod Olson <to...@uc...> Systems Librarian University of Chicago Library |
From: Demian K. <dem...@vi...> - 2012-03-07 18:43:02
|
If it's not a lot of extra work, it never hurts to share a patch -- that way people who need it can vote in JIRA to determine whether or not it's necessary to change the trunk... and even if we don't end up changing trunk code, it's available for reference. If you do make edition multi-valued, you'll have to watch out for consequences in a few places; the templates for exporting records and building citations may also need to be adjusted, since they're currently assuming a single value. - Demian > -----Original Message----- > From: Tod Olson [mailto:to...@uc...] > Sent: Wednesday, March 07, 2012 1:15 PM > To: vuf...@li... > Subject: [VuFind-Tech] multiple values for edition field? > > We have a minor issue with the default setup for the Solr edition field, and > I'm wondering whether I should solve this purely locally, or offer up a patch. > The edition field is defined as not multiValued, but our local practice is to > index both the 250‡ab (Edition Statement) and the 254‡a (Musical Presentation > Statement) as edition information. > > So locally I'll change the Solr schema.xml and override core.tpl in the > templates that we use. But if this seems useful to other sites, I can submit a > patch. Let me know. > > -Tod > > > Tod Olson <to...@uc...> > Systems Librarian > University of Chicago Library > > > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech |
From: Tod O. <to...@uc...> - 2012-03-08 21:03:38
|
A patch for a multi-valued edition field is now in JIRA: http://vufind.org/jira/browse/VUFIND-525 I think this gives a degree of flexibility without a real penalty for sites that don't need it. The exports and citations did not seem to have a problem, I assume they work off of the full record directly. Thanks, -Tod On Mar 7, 2012, at 12:42 PM, Demian Katz wrote: > If it's not a lot of extra work, it never hurts to share a patch -- that way people who need it can vote in JIRA to determine whether or not it's necessary to change the trunk... and even if we don't end up changing trunk code, it's available for reference. > > If you do make edition multi-valued, you'll have to watch out for consequences in a few places; the templates for exporting records and building citations may also need to be adjusted, since they're currently assuming a single value. > > - Demian > >> -----Original Message----- >> From: Tod Olson [mailto:to...@uc...] >> Sent: Wednesday, March 07, 2012 1:15 PM >> To: vuf...@li... >> Subject: [VuFind-Tech] multiple values for edition field? >> >> We have a minor issue with the default setup for the Solr edition field, and >> I'm wondering whether I should solve this purely locally, or offer up a patch. >> The edition field is defined as not multiValued, but our local practice is to >> index both the 250‡ab (Edition Statement) and the 254‡a (Musical Presentation >> Statement) as edition information. >> >> So locally I'll change the Solr schema.xml and override core.tpl in the >> templates that we use. But if this seems useful to other sites, I can submit a >> patch. Let me know. >> >> -Tod >> >> >> Tod Olson <to...@uc...> >> Systems Librarian >> University of Chicago Library >> >> >> >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Vufind-tech mailing list >> Vuf...@li... >> https://lists.sourceforge.net/lists/listinfo/vufind-tech |
From: Demian K. <dem...@vi...> - 2012-03-08 21:08:39
|
Thanks for sharing this! You're right about the exports -- in VuFind 1.x they are handled directly from the MARC record, so that shouldn't matter (I'm in VuFind 2.0 mode in my head, so I assumed incorrectly that they would break). I still think citations aren't going to work quite right -- there's code in IndexRecord.php that converts the edition string into an array to pass it to the citation builder. If getEdition returns an array already, then a two-dimensional array will get passed down and the edition part of the citation won't be handled correctly. Fortunately, if you care about this, it's very easy to fix. - Demian > -----Original Message----- > From: Tod Olson [mailto:to...@uc...] > Sent: Thursday, March 08, 2012 4:04 PM > To: Demian Katz > Cc: Tod Olson; vuf...@li... > Subject: Re: [VuFind-Tech] multiple values for edition field? > > A patch for a multi-valued edition field is now in JIRA: > > http://vufind.org/jira/browse/VUFIND-525 > > I think this gives a degree of flexibility without a real penalty for sites > that don't need it. > > The exports and citations did not seem to have a problem, I assume they work > off of the full record directly. > > Thanks, > > -Tod > > On Mar 7, 2012, at 12:42 PM, Demian Katz wrote: > > > If it's not a lot of extra work, it never hurts to share a patch -- that way > people who need it can vote in JIRA to determine whether or not it's necessary > to change the trunk... and even if we don't end up changing trunk code, it's > available for reference. > > > > If you do make edition multi-valued, you'll have to watch out for > consequences in a few places; the templates for exporting records and building > citations may also need to be adjusted, since they're currently assuming a > single value. > > > > - Demian > > > >> -----Original Message----- > >> From: Tod Olson [mailto:to...@uc...] > >> Sent: Wednesday, March 07, 2012 1:15 PM > >> To: vuf...@li... > >> Subject: [VuFind-Tech] multiple values for edition field? > >> > >> We have a minor issue with the default setup for the Solr edition field, > and > >> I'm wondering whether I should solve this purely locally, or offer up a > patch. > >> The edition field is defined as not multiValued, but our local practice is > to > >> index both the 250‡ab (Edition Statement) and the 254‡a (Musical > Presentation > >> Statement) as edition information. > >> > >> So locally I'll change the Solr schema.xml and override core.tpl in the > >> templates that we use. But if this seems useful to other sites, I can > submit a > >> patch. Let me know. > >> > >> -Tod > >> > >> > >> Tod Olson <to...@uc...> > >> Systems Librarian > >> University of Chicago Library > >> > >> > >> > >> > >> --------------------------------------------------------------------------- > --- > >> Virtualization & Cloud Management Using Capacity Planning > >> Cloud computing makes use of virtualization - but cloud computing > >> also focuses on allowing computing to be delivered as a service. > >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ > >> _______________________________________________ > >> Vufind-tech mailing list > >> Vuf...@li... > >> https://lists.sourceforge.net/lists/listinfo/vufind-tech |
From: Tod O. <to...@uc...> - 2012-03-08 21:42:14
|
Hmm, I infer then that VF2 does the exports from the Solr fields rather than the full record. That's a bit of a surprise to me, as what I've encountered with exports of different record types (MARC, OAI-DC, EAD) makes me think there are often different criteria for different data sources. But maybe that's an artifact of how the data in our current discovery layer is stored. I'd be interested in a pointer to the reasoning behind that decision. But I digress... Thanks for mentioning that about the citation. Stripping that call to array() in line 176 fixes it, I'll add that to the JIRA. -Tod On Mar 8, 2012, at 3:08 PM, Demian Katz wrote: > Thanks for sharing this! > > You're right about the exports -- in VuFind 1.x they are handled directly from the MARC record, so that shouldn't matter (I'm in VuFind 2.0 mode in my head, so I assumed incorrectly that they would break). > > I still think citations aren't going to work quite right -- there's code in IndexRecord.php that converts the edition string into an array to pass it to the citation builder. If getEdition returns an array already, then a two-dimensional array will get passed down and the edition part of the citation won't be handled correctly. Fortunately, if you care about this, it's very easy to fix. > > - Demian > >> -----Original Message----- >> From: Tod Olson [mailto:to...@uc...] >> Sent: Thursday, March 08, 2012 4:04 PM >> To: Demian Katz >> Cc: Tod Olson; vuf...@li... >> Subject: Re: [VuFind-Tech] multiple values for edition field? >> >> A patch for a multi-valued edition field is now in JIRA: >> >> http://vufind.org/jira/browse/VUFIND-525 >> >> I think this gives a degree of flexibility without a real penalty for sites >> that don't need it. >> >> The exports and citations did not seem to have a problem, I assume they work >> off of the full record directly. >> >> Thanks, >> >> -Tod >> >> On Mar 7, 2012, at 12:42 PM, Demian Katz wrote: >> >>> If it's not a lot of extra work, it never hurts to share a patch -- that way >> people who need it can vote in JIRA to determine whether or not it's necessary >> to change the trunk... and even if we don't end up changing trunk code, it's >> available for reference. >>> >>> If you do make edition multi-valued, you'll have to watch out for >> consequences in a few places; the templates for exporting records and building >> citations may also need to be adjusted, since they're currently assuming a >> single value. >>> >>> - Demian >>> >>>> -----Original Message----- >>>> From: Tod Olson [mailto:to...@uc...] >>>> Sent: Wednesday, March 07, 2012 1:15 PM >>>> To: vuf...@li... >>>> Subject: [VuFind-Tech] multiple values for edition field? >>>> >>>> We have a minor issue with the default setup for the Solr edition field, >> and >>>> I'm wondering whether I should solve this purely locally, or offer up a >> patch. >>>> The edition field is defined as not multiValued, but our local practice is >> to >>>> index both the 250‡ab (Edition Statement) and the 254‡a (Musical >> Presentation >>>> Statement) as edition information. >>>> >>>> So locally I'll change the Solr schema.xml and override core.tpl in the >>>> templates that we use. But if this seems useful to other sites, I can >> submit a >>>> patch. Let me know. >>>> >>>> -Tod >>>> >>>> >>>> Tod Olson <to...@uc...> >>>> Systems Librarian >>>> University of Chicago Library >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------------- >> --- >>>> Virtualization & Cloud Management Using Capacity Planning >>>> Cloud computing makes use of virtualization - but cloud computing >>>> also focuses on allowing computing to be delivered as a service. >>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>> _______________________________________________ >>>> Vufind-tech mailing list >>>> Vuf...@li... >>>> https://lists.sourceforge.net/lists/listinfo/vufind-tech > |
From: Demian K. <dem...@vi...> - 2012-03-09 12:03:25
|
The problem with VuFind 1.x is that you can only export records that originated in MARC format. VuFind 2 fixes this by more closely tying the export logic to the record drivers -- rather than sending a MARC record to the view and constructing the export data, we send a record driver object to the view and query its methods to construct the export data. In the case of MARC records, the net effect is the same -- in cases where the MARC data is more complete than the Solr index, the MARC record driver will pull data from the most appropriate place -- but now export is also supported by just about any other type of record you can throw in, as long as you implement the appropriate record driver methods. (And, of course, you can disable export for particular formats if it's not appropriate to offer the option). In any case, thanks for the update! - Demian ________________________________________ From: Tod Olson [to...@uc...] Sent: Thursday, March 08, 2012 4:42 PM To: Demian Katz Cc: Tod Olson; vuf...@li... Subject: Re: [VuFind-Tech] multiple values for edition field? Hmm, I infer then that VF2 does the exports from the Solr fields rather than the full record. That's a bit of a surprise to me, as what I've encountered with exports of different record types (MARC, OAI-DC, EAD) makes me think there are often different criteria for different data sources. But maybe that's an artifact of how the data in our current discovery layer is stored. I'd be interested in a pointer to the reasoning behind that decision. But I digress... Thanks for mentioning that about the citation. Stripping that call to array() in line 176 fixes it, I'll add that to the JIRA. -Tod On Mar 8, 2012, at 3:08 PM, Demian Katz wrote: > Thanks for sharing this! > > You're right about the exports -- in VuFind 1.x they are handled directly from the MARC record, so that shouldn't matter (I'm in VuFind 2.0 mode in my head, so I assumed incorrectly that they would break). > > I still think citations aren't going to work quite right -- there's code in IndexRecord.php that converts the edition string into an array to pass it to the citation builder. If getEdition returns an array already, then a two-dimensional array will get passed down and the edition part of the citation won't be handled correctly. Fortunately, if you care about this, it's very easy to fix. > > - Demian > >> -----Original Message----- >> From: Tod Olson [mailto:to...@uc...] >> Sent: Thursday, March 08, 2012 4:04 PM >> To: Demian Katz >> Cc: Tod Olson; vuf...@li... >> Subject: Re: [VuFind-Tech] multiple values for edition field? >> >> A patch for a multi-valued edition field is now in JIRA: >> >> http://vufind.org/jira/browse/VUFIND-525 >> >> I think this gives a degree of flexibility without a real penalty for sites >> that don't need it. >> >> The exports and citations did not seem to have a problem, I assume they work >> off of the full record directly. >> >> Thanks, >> >> -Tod >> >> On Mar 7, 2012, at 12:42 PM, Demian Katz wrote: >> >>> If it's not a lot of extra work, it never hurts to share a patch -- that way >> people who need it can vote in JIRA to determine whether or not it's necessary >> to change the trunk... and even if we don't end up changing trunk code, it's >> available for reference. >>> >>> If you do make edition multi-valued, you'll have to watch out for >> consequences in a few places; the templates for exporting records and building >> citations may also need to be adjusted, since they're currently assuming a >> single value. >>> >>> - Demian >>> >>>> -----Original Message----- >>>> From: Tod Olson [mailto:to...@uc...] >>>> Sent: Wednesday, March 07, 2012 1:15 PM >>>> To: vuf...@li... >>>> Subject: [VuFind-Tech] multiple values for edition field? >>>> >>>> We have a minor issue with the default setup for the Solr edition field, >> and >>>> I'm wondering whether I should solve this purely locally, or offer up a >> patch. >>>> The edition field is defined as not multiValued, but our local practice is >> to >>>> index both the 250‡ab (Edition Statement) and the 254‡a (Musical >> Presentation >>>> Statement) as edition information. >>>> >>>> So locally I'll change the Solr schema.xml and override core.tpl in the >>>> templates that we use. But if this seems useful to other sites, I can >> submit a >>>> patch. Let me know. >>>> >>>> -Tod >>>> >>>> >>>> Tod Olson <to...@uc...> >>>> Systems Librarian >>>> University of Chicago Library >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------------- >> --- >>>> Virtualization & Cloud Management Using Capacity Planning >>>> Cloud computing makes use of virtualization - but cloud computing >>>> also focuses on allowing computing to be delivered as a service. >>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>> _______________________________________________ >>>> Vufind-tech mailing list >>>> Vuf...@li... >>>> https://lists.sourceforge.net/lists/listinfo/vufind-tech > |