 |
 |
Yes, the draft version of SRU 2.0 does include support for facets. The functionality is based on the SOLR documentation of facets with perhaps some slight simplification. None of the editors of the standard are active facet users, so comments on that feature in our draft would be appreciated. (I'm afraid I'm responsible for that work. Personally, I found the SOLR functionality massively over-engineered and hope someone will recommend simplification.) All the current draft documentation is available at http://www.loc.gov/standards/sru/oasis/. Ralph > -----Original Message----- > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of > Karen Coombs > Sent: Wednesday, March 02, 2011 12:45 PM > To: [log in to unmask] > Subject: Re: [CODE4LIB] dealing with Summon > > I believe that there has been discussion of adding facets to SRU > responses in the past. It may even be part of the standard now I'm not > sure. > > Facets in an SRU and/or Atom response would certainly be of interest > to OCLC. Another area where it might be nice to consider collaborating > is on a format for these records that is non-library developer > friendly but rich enough to provide the appropriate metadata. If > you've used WorldCat Search API you'll know that as a developer your > caught between the complexity of MARC and the simplicity (but lack of > richness) of Dublin Core/Atom/RSS. > > Is there a middle ground metadata format that developers would prefer > to see output? > > Karen > > On Tue, Mar 1, 2011 at 1:36 PM, Andrew Nagy <[log in to unmask]> wrote: > > Hi Godmar - to help answer some of your questions about the fields - I can > > help address those directly. Though it would be interesting to hear > > experiences from others who are working from APIs to search systems such > as > > Summon or others. > > > > In regards to the publication date - the Summon API has the "raw date" > > (which comes directly from the content provider), but we also provide a > > field with a microformat containing the parsed and cleaned date that Summon > > has generated. We advise for you to use our parsed and cleaned date rather > > than the raw date. The URL and URI fields are similar, the URL is the link > > that we have generated - the URI is what is provided by the content > > provider. In your case, you appear to be referring to OPAC records, so the > > URI is the ToC that came from the 856$u field in your MARC records. The > URL > > is a link to the record in the OPAC. > > > > If you need more assistance around the fields that are available via Summon, > > I'd be happy to take this conversation off-list. > > > > I think an interesting conversation for the Code4Lib community would be > > around a standardized approach for an API that meets both the needs of the > > library developer and the product vendor. I recall a brief chat I had with > > Annette about this same topic at a NISO conference in Boston a while back. > > For example, we have SRU/W, but that does not provide support for all of the > > features that a search engine would need (ie. facets, spelling corrections, > > recommendations, etc.). Maybe a new standard is needed - or maybe > extending > > an existing one would solve this need? I'm all ears if you have any ideas. > > > > Andrew > > > > > > On Tue, Mar 1, 2011 at 2:14 PM, Godmar Back <[log in to unmask]> wrote: > > > >> Hi - > >> > >> this is a comment/question about a particular discovery system > >> (Summon), but perhaps of more general interest. It's not intended as > >> flamebait or criticism of the vendor or people associated with it. > >> > >> When integrating Summon into LibX (which works quite nicely btw, > >> gratuitous screenshot is attached to this email) I found myself amazed > >> by the multitude of possible fields and combinations returned in the > >> resulting records. For instance, some records contains fields 'url' > >> (lower case), and/or 'URL' (upper case), and/or 'URI' (upper case). > >> Which one to display, and how? For instance, some records contain an > >> OPAC URL in the 'url' field, and a ToC link in the URI field. Why? > >> > >> Similarly, the date associated with a record can come in a variety of > >> formats. Some are single-field (20080901), some are abbreviated > >> (200811), some are separated into year, month, date, etc. Some > >> records have a mixture of those. > >> > >> My question is how do other adopters of Summon, or of emerging > >> discovery systems that provide direct access to their records in > >> general, deal with the roughness of the records being returned? Are > >> there best practices in how to extract information from them, and in > >> how to prioritize relevant and weed out irrelevant or redundant > >> information? > >> > >> - Godmar > >> > >