Re: [VuFind-Tech] Multiple Record Formats: Possible Driver Interface

[Alan R. <ala...@mn...>]

On Tue, 2009-08-25 at 12:50 -0500, Till Kinstler wrote:
> Alan Rykhus schrieb:
> 
> > I say this because I think creating displays from MARC tags is the wrong
> > approach.
> 
> Discuss that with librarians :-) I think you implicitly just voted for a 
> simplification of library data. I like that, but as long as we have data 
> fields for "other not involved persons" in cataloging rules (we really 
> have such a field in our consortium) I see little hope. And 
> complexity/richness of data tends to increase with all that "linked 
> data"/"semantic web" hype.

As I said, for the most part I've done this. What the librarians don't
know, won't hurt them. I've got 6 types of subjects, 7 types of titles,
3 types of notes, 2 type of urls. In our normal web opac, that is how
they are split into displays, so the 'librarian' does not know the
difference. If you make it do what they want, they don't need to know
how. I've never claimed to be a librarian, I'm a computer programmer who
tries to make librarians happy.

> > I've taken most of this out of my implementation and display
> > the solr fields directly. 
> 
> There will be a "generic"/"default" record driver that does exactly 
> that: Build a display using stored Solr fields. It will have fixed 
> labels (as "author", "title" or so), though, as far as I understand. But 
> you may easily change those be extending that class and applying 
> suitable labels. The part that parses the Solr index data may stay 
> untouched...
> But there will be cases the Solr index doesn't offer all data or enough 
> precision. For example one may put the "other not involved persons" 
> mentioned above into the Solr person (or "author") index fields. 
> Together with authors, photographers, butchers, gauchos and other human 
> beings, so they are searchable. But one wouldn't want to display them as 
> authors to librarians... :-)
> 

> > I think this is a much simpler approach and a lot easier to maintain. If
> > we get away from displays of the raw records and display what is in the
> > individual indexes in Solr we only need to worry about parsing the
> > records and assigning them to a Solr index.
> 
> I think that will add complexity to the index schema in the future...
> 
> Till
> 

I've already added fields to the schema for my use just to fulfill what
you say makes it more complicated. I say it makes it simpler, I add a
field or use an existing field for my purpose for this type of record.
As I stated, when I change the configuration for that field I ONLY have
to configure my parser. I do not have to change my parser AND my
display. It displays correctly automatically.

If I add a new field because of some new record format, I only need that
field if I add those type of records. When I upgrade I would still leave
that field in my schema. So what, I don't populate it, it takes no
space, it is never populated by the solr-convert.xsl into the XML
structure because it is not in the record. So I do not have to worry
about the display, Smarty takes care of it.

A lot of the examples already used are very generic. A note in a bib
record, could be cooking instructions from the butcher. You store it in
a Solr note index field  and modify the tag on the display using your
Smarty template.

al
-- 
Alan Rykhus
PALS, A Program of the Minnesota State Colleges and Universities 
(507)389-1975
ala...@mn...