Comments on: Fun with WebService::Solr, Part III of III http://infomotions.com/blog/2009/01/fun-with-webservicesolr-part-iii-of-iii/ Thoughts in libraries and librarianship Thu, 03 Sep 2009 14:26:26 -0400 http://wordpress.org/?v=2.8.5 hourly 1 By: Brian Cassidy http://infomotions.com/blog/2009/01/fun-with-webservicesolr-part-iii-of-iii/comment-page-1/#comment-851 Brian Cassidy Sat, 24 Jan 2009 04:07:31 +0000 http://infomotions.com/blog/?p=134#comment-851 To be fair, Ed Summers wrote the SRU modules -- I've just helped maintain them. To be fair, Ed Summers wrote the SRU modules — I’ve just helped maintain them.

]]> By: Ian Ibbotson http://infomotions.com/blog/2009/01/fun-with-webservicesolr-part-iii-of-iii/comment-page-1/#comment-848 Ian Ibbotson Fri, 23 Jan 2009 23:05:10 +0000 http://infomotions.com/blog/?p=134#comment-848 Heya Jonathan.. Don't suppose you could enumerate some of your arguments as to why there should be -mime- types for mods/marcxml etc? There has always been a bit of an elephant in the room with the issue of identifying schemas, from the "XML" and element set name wranglings of Z3950 to the advanced SRU "It's just a URI (Lets hope naming the problem happens to solve it too)" If the answer to these problems is "Just give everything a mime type" then thats cool (We certainly need some registry) but what should the mime type for mods actually look like? Heya Jonathan.. Don’t suppose you could enumerate some of your arguments as to why there should be -mime- types for mods/marcxml etc?

There has always been a bit of an elephant in the room with the issue of identifying schemas, from the “XML” and element set name wranglings of Z3950 to the advanced SRU “It’s just a URI (Lets hope naming the problem happens to solve it too)”

If the answer to these problems is “Just give everything a mime type” then thats cool (We certainly need some registry) but what should the mime type for mods actually look like?

]]> By: Jonathan Rochkind http://infomotions.com/blog/2009/01/fun-with-webservicesolr-part-iii-of-iii/comment-page-1/#comment-845 Jonathan Rochkind Fri, 23 Jan 2009 15:42:59 +0000 http://infomotions.com/blog/?p=134#comment-845 I've been spending some time with the OpenSearch spec lately in anticipation of using it in a particular future project I have in mind. I've been quite impressed with it. I think the idea of merging SRU into OpenSearch is a good one. It's not really true to say that "OpenSearch returns an RSS-like data stream" -- rather an OpenSearch description can specify exactly what format is returned using a MIME type, and can even specify different URLs for retrieving different formats. So I think it's rather compatible with SRU here. There's no reason an OpenSearch description can't declare results returned in MARC-XML or anything else. (I hope MARCXML, MODS, etc, have declared mime types? If not they need to asap for a billion reasons!) Also, while an OpenSearch description document doesn't declare any particular syntax for it's query, there's no reason an OpenSearch query _couldn't_ be in CQL. It would seem useful to me to extend OpenSearch to allow a description document to specify that CQL is supported, and specify what search indexes the server provides, or any other CQL-related metadata. One of the most useful parts of OpenSearch is how it allows easy extensibility using custom namespaces. I am actually not that familiar with SRU, and haven't read that OASIS document yet, but I hope they take the approach of trying to fit SRU into the existing OpenSearch standard, rather than creating a new 'umbrella' standard on top of it. I think the OpenSearch standard would be quite suited to this. I perused the OpenSearch listserv recently, and I didn't see any mention of OASIS or SRU. I hope the OASIS folks are actually talking to the OpenSearch folks about this, rather than just doing things in their own silo. The OpenSearch folks seem to me to be quite on top of things, and interested in making sure OpenSearch supports new use cases in the 'right' way. I’ve been spending some time with the OpenSearch spec lately in anticipation of using it in a particular future project I have in mind.

I’ve been quite impressed with it. I think the idea of merging SRU into OpenSearch is a good one.

It’s not really true to say that “OpenSearch returns an RSS-like data stream” — rather an OpenSearch description can specify exactly what format is returned using a MIME type, and can even specify different URLs for retrieving different formats. So I think it’s rather compatible with SRU here. There’s no reason an OpenSearch description can’t declare results returned in MARC-XML or anything else. (I hope MARCXML, MODS, etc, have declared mime types? If not they need to asap for a billion reasons!)

Also, while an OpenSearch description document doesn’t declare any particular syntax for it’s query, there’s no reason an OpenSearch query _couldn’t_ be in CQL.

It would seem useful to me to extend OpenSearch to allow a description document to specify that CQL is supported, and specify what search indexes the server provides, or any other CQL-related metadata.

One of the most useful parts of OpenSearch is how it allows easy extensibility using custom namespaces. I am actually not that familiar with SRU, and haven’t read that OASIS document yet, but I hope they take the approach of trying to fit SRU into the existing OpenSearch standard, rather than creating a new ‘umbrella’ standard on top of it. I think the OpenSearch standard would be quite suited to this.

I perused the OpenSearch listserv recently, and I didn’t see any mention of OASIS or SRU. I hope the OASIS folks are actually talking to the OpenSearch folks about this, rather than just doing things in their own silo. The OpenSearch folks seem to me to be quite on top of things, and interested in making sure OpenSearch supports new use cases in the ‘right’ way.

]]>