Well, it’s done. The [handout][1] and [slides][2] as presented are posted here, and I’ll add them to our [portal integration][3] page (yeah, they’re sort of connected) when I return to [Plymouth][4]. The slides don’t stand on their own, but for those that were there, they should be helpful reminders of what was said what links we looked at.
One of the attendees took me to task for recommending MARC XML as the replacement for III’s proprietary schema, saying that it fails to leverage the full value of XML. He had a point, and I really should have been advocating for improvement without prejudicing what the result should be. MARC XML would be a step in the right direction, but it has its limitations. I was glad to see the interest, and my hopes for a solution are a lot higher now than they were before the show.
If nothing else, I’d recommend a schema that follows the generic recommendations for [implementing Dublin Core in XML][5]. Here are the important bits, minus the DC-specifics:
- A simple DC record is made up of one or more properties and their associated values.
- Each property is an attribute of the resource being described.
- Properties may be repeated.
- Each value is a literal string.
- Each literal string value may have an associated language (e.g. en-GB).
Here’s the big one, and it’s where III’s schema fails:
…Encode properties as XML elements and values as the content of those elements. For example:
<dc:title>Dublin Core in XML</dc:title>
To provide the counter example, here’s how the title field is represented in III’s schema:
<VARFLD> <HEADER> <TAG>t</TAG> <NAME>TITLE</NAME> <SEQUENCENUM>0</SEQUENCENUM> </HEADER> <DisplayForm>Kitten’;s first full moon / Kevin Henkes</DisplayForm> <RTL>0</RTL> <MARCINFO> <MARCTAG>245</MARCTAG> <INDICATOR1>1</INDICATOR1> <INDICATOR2>0</INDICATOR2> </MARCINFO> <MARCSUBFLD> <SUBFIELDINDICATOR>a</SUBFIELDINDICATOR> <SUBFIELDDATA>Kitten’;s first full moon /</SUBFIELDDATA> </MARCSUBFLD> <MARCSUBFLD> <SUBFIELDINDICATOR>c</SUBFIELDINDICATOR> <SUBFIELDDATA>Kevin Henkes</SUBFIELDDATA> </MARCSUBFLD> </VARFLD>
There’s a lot of data there, but the structure is just strange.
Then, in one of those “duh” moments, I was reminded that I could purchase another index and ask III to index acq or cat date, thus solving the problem I now face in searching and limiting by those dates. Good point.
I was also reminded that I didn’t mention that the interface is neither [REST][6] nor [SOAP][7]. I did explain that the search URL syntax is different from the WebOPAC URL syntax, even though they _could_ be the same (or, at least, more similar).
XML Server holds a lot of promise, but it needs development attention from III to be truly useful. Then, I’d also like to see III adopt a [Web Services][8] strategy that includes the OPAC, patron data, billing/fines/notices, and everything else.
[1]: homepage-mac-com-xmlhandout.pdf "handout"
[2]: homepage-mac-com-XML.mov "slides"
[3]: http://www.plymouth.edu/library/?portal "portal integration"
[4]: http://www.plymouth.edu/ "Plymouth"
[5]: http://dublincore.org/documents/dc-xml-guidelines/ "implementing Dublin Core in XML"
[6]: http://en.wikipedia.org/wiki/Representational_State_Transfer "REST"
[7]: http://en.wikipedia.org/wiki/SOAP "SOAP"
[8]: http://en.wikipedia.org/wiki/Web_services "Web Services"