 |
 |
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 >> >