From: Tuan N. <tu...@yo...> - 2011-10-13 14:36:30
|
I am not sure if it is any more intuitive either. But, it would be the expected behavior. On 2011-10-13, at 10:03 AM, Demian Katz wrote: > I see what you are saying, but I'm not sure that the multi-select OR situation is much better if you have two separate fields. I don't think the behavior would be very intuitive if, say, a user selected "Music Recording OR Monograph" in "content type" and "CD" in "media type." > > - Demian > >> -----Original Message----- >> From: Tuan Nguyen [mailto:tu...@yo...] >> Sent: Thursday, October 13, 2011 9:55 AM >> To: Demian Katz >> Cc: Eoghan Ó Carragáin; Osullivan L.; vuf...@li... >> Subject: Re: [VuFind-Tech] idle thoughts on solrmarc 2.3 and getFormats >> >> Assuming you're talking about making the Format facet multi-selectable >> (by OR'ing values), then "Music Recording" or "CD" would not be >> desirable because you would get all other kinds of contents - "Sound >> Recording" for example, on CDs when you only are interested in Music >> CDs. >> >> I agree that improving getFormats is also a good thing because of >> backward compatibility and that can go together with the new concepts >> without any problem. >> >> >> >> On 2011-10-13, at 9:41 AM, Demian Katz wrote: >> >>> I agree that there are two different concepts at work here, and it >> makes the most logical sense to keep them separated... but at the same >> time, from a usability perspective, it might be better to stuff both >> types of values into a single "Format" facet -- it would still function >> properly (user could select "Music Recording" or "CD") but it would >> take up less space in the UI. It might grate on the nerves of someone >> who knows how it "should" work (I am such a person, I admit), but to >> the naïve user I don't know that it would make any significant >> difference. In any case, I don't really have a fixed opinion on this >> yet -- just providing the other point of view. >>> >>> Another factor to consider: we have very rich data in MARC records >> with which to create these facets, but putting all this detail into the >> index creates additional work when indexing non-MARC records. >>> >>> At this point, I still think it's worth improving getFormat so that >> it looks at the output of the new methods and narrows that down to the >> current fixed list of format values (for consistency with earlier >> releases... though we may find that there are some new values that >> should be added and supported in translation). I hesitate to index the >> content and media types by default, since I think that will grow the >> index in support of something that is more detail-oriented than the >> average library will want (though I suppose we should try it in order >> to really see the impact). However, there's certainly no harm in >> adding a couple of fields to the schema and adding indexing rules >> commented-out in marc_local.properties so it's easy to utilize them if >> you actually want them. >>> >>> - Demian >>> >>>> -----Original Message----- >>>> From: Tuan Nguyen [mailto:tu...@yo...] >>>> Sent: Thursday, October 13, 2011 9:20 AM >>>> To: Demian Katz >>>> Cc: Eoghan Ó Carragáin; Osullivan L.; vufind- >> te...@li... >>>> Subject: Re: [VuFind-Tech] idle thoughts on solrmarc 2.3 and >> getFormats >>>> >>>> I'd be travelling to Vancouver on the 18th so I'll miss the >> developer >>>> call, but I'd like to share my thoughts for you to consider. >>>> >>>> I too thought about mapping/merging content types and media types >> into >>>> formats, but then I realized we'd be recreating the original problem >> in >>>> a new way. >>>> >>>> Having separate filters for content types and media types allows for >>>> finer level of details. You could, for example, want to get all >> "Music >>>> Recording on CD", so you narrow down to content type of "Music >>>> Recording" and then further narrow to CD media type. Also, some >> times >>>> you just want all CD and don't care what type of content is on the >> CD >>>> so you just narrow to media type of CD. >>>> >>>> >>>> On 2011-10-13, at 8:46 AM, Demian Katz wrote: >>>> >>>>> My original thought had been to rewrite the existing getFormat >>>> function to call David Walker's methods and map/filter them down to >> the >>>> current set of values that it outputs - this would eliminate some >> ugly >>>> code and allow support for multi-format items (not currently handled >> by >>>> the default implementation). I do see the benefit of offering two >>>> separate additional filters, though I also hesitate to engage in >>>> schema-creep if it's not strictly necessary. I'll put this on the >>>> agenda for next week's developers call, and perhaps we can come to a >>>> conclusion then (though further email discussion is welcome in the >>>> meantime). >>>>> >>>>> - Demian >>>>> >>>>> From: Eoghan Ó Carragáin [mailto:eog...@gm...] >>>>> Sent: Thursday, October 13, 2011 6:34 AM >>>>> To: Osullivan L. >>>>> Cc: vuf...@li... >>>>> Subject: Re: [VuFind-Tech] idle thoughts on solrmarc 2.3 and >>>> getFormats >>>>> >>>>> Hi, >>>>> I think this makes sense too. We can make use of the improved >>>> granularity without breaking urls people may have saved which >> contained >>>> a format filter. >>>>> >>>>> Eoghan >>>>> >>>>> On 13 October 2011 10:56, Osullivan L. <L.O...@sw...> >>>> wrote: >>>>> Hi Folks, >>>>> >>>>> I think Tuan's suggestion makes a lot of sense given the >> distinction >>>> is >>>>> now being made for us. I know we don't want to unnecessarily >> overload >>>>> the schema but the ability to identify something as a monograph or >>>>> otherwise would be extremely useful as the "nature" of each type >>>>> determines different behaviour for how it handled by most ILS which >>>> can >>>>> impact on the resource discovery level. Take holds for example, Bib >>>>> Level holds are possible for Monographs but not for serials and >>>>> journals. >>>>> >>>>> Thanks, >>>>> >>>>> Luke >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Tuan Nguyen [mailto:tu...@yo...] >>>>> Sent: 13 October 2011 10:47 >>>>> To: vuf...@li... Tech >>>>> Subject: [VuFind-Tech] idle thoughts on solrmarc 2.3 and getFormats >>>>> >>>>> With solrmarc 2.3 inclusion of David Walker's new methods for >> getting >>>>> Content Types and Media Types, what do you all think about adding 2 >>>> more >>>>> fields to the schema.xml: content_type and media_type (and >> respective >>>>> facets)? This allows for the old format field to behave like it did >>>>> before for backward compatibility while taking advantage of the >>>> improved >>>>> methods. I'm guessing some of you are thinking about doing this >> (may >>>> be >>>>> already did) locally already, so I think it would make sense if it >> is >>>>> part of the general schema. >>>>> ------------------------------------------------------------------- >> -- >>>> --- >>>>> ------ >>>>> All the data continuously generated in your IT infrastructure >>>> contains a >>>>> definitive record of customers, application performance, security >>>>> threats, fraudulent activity and more. Splunk takes this data and >>>> makes >>>>> sense of it. Business sense. IT sense. Common sense. >>>>> http://p.sf.net/sfu/splunk-d2d-oct >>>>> _______________________________________________ >>>>> Vufind-tech mailing list >>>>> Vuf...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/vufind-tech >>>>> >>>>> ------------------------------------------------------------------- >> -- >>>> --------- >>>>> All the data continuously generated in your IT infrastructure >>>> contains a >>>>> definitive record of customers, application performance, security >>>>> threats, fraudulent activity and more. Splunk takes this data and >>>> makes >>>>> sense of it. Business sense. IT sense. Common sense. >>>>> http://p.sf.net/sfu/splunk-d2d-oct >>>>> _______________________________________________ >>>>> Vufind-tech mailing list >>>>> Vuf...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/vufind-tech >>>>> >>>>> ------------------------------------------------------------------- >> -- >>>> --------- >>>>> All the data continuously generated in your IT infrastructure >>>> contains a >>>>> definitive record of customers, application performance, security >>>>> threats, fraudulent activity and more. Splunk takes this data and >>>> makes >>>>> sense of it. Business sense. IT sense. Common sense. >>>>> http://p.sf.net/sfu/splunk-d2d- >>>> oct_______________________________________________ >>>>> Vufind-tech mailing list >>>>> Vuf...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/vufind-tech >>> > |