It’s not so easy to do a public video demo of our new Pika 4.0 case management system design changes, because of confidentiality issues, but we will post select screenshots reasonably soon so you can get a visual idea of changes we have made to that application.

Other posts of possible interest...

• Metadata Schmetadata, Relevance and Reality
• Selecting GSA targets – Part Two: The Practical Realities
• Coda re 2010 TIG Knowledge Management session
• TIG final evaluation report for The Findability Project

This TIG project was funded for an 18-month period from January 2008 through June 2009. Much of the report will ring familiar to those who have followed the project here, since much of what has already been posted mirrors what would be required in a TIG evaluation report. Essentially, this public project site enabled us to give others in the legal services community an ongoing, if lagging, report of progress on the project, while at the same time considerably easing the process of writing up the evaluation report at the end of the project since we had already written most it as we went along.

We’re winding things down here, but we will continue to post here at least through the next TIG conference in early 2010. Among other things, we will be detailing how in finalized form we are integrating our project’s GSA test frontend functionality into a more expansive shared organization portal, part of our current deployment of a heavily customized version of Pika 4.0. We have finished the LSNC redesign of Pika 4.0 as well as a new LSNC shared portal “front door” (built on WordPress), both of which are scheduled to be in place and in use by LSNC staff the day after the Labor Day break.

Stay tuned, people!

Other posts of possible interest...

• Revised: What the LSNC Shared Portal now looks like
• Metadata Schmetadata, Relevance and Reality
• Selecting GSA targets – Part Three: Quantification, Revision and Finalization
• Rough-cut evaluation of our GSA test-bed installations

Other posts of possible interest...

• Pika and the Google Search Appliance make nice
• Revised: What the LSNC Shared Portal now looks like
• Metadata Schmetadata, Relevance and Reality
• Selecting GSA targets – Part Three: Quantification, Revision and Finalization

A few days ago my earlier post about metadata, with the conclusion that “we don’t need metadata,” caught the attention of Daniel Tunkelang. It just so happens that Daniel is the chief scientist at Endeca, a prominent enterprise information company. You know, like, he knows what he’s talking about.

Long story short, Daniel commented on my post here and then, after I responded, mirrored our discussion in Does Metadata Matter, a new thread at The Noisy Channel, his blog that hosts vigorous discussions of search design and other enterprise information issues way above my pay grade. Daniel and others there critically but constructively took me to task because of the empirically unsupported general conclusion that metadata is not needed, and the specific failure to make clear the anecdotal basis for our conclusion about metadata on this project. As you can see from the discussion at Daniel’s blog, they killed me on the empirical point. In response, I better explained there than I did in my original post why our conclusion about not needing metadata on this project makes sense.

The discussion there ended on Christopher’s grace note, something that the TIG program and others within the legal services community will appreciate:

I also want to applaud your project which I should have done before, the mission your team has set is very admirable. It’s gratifying to see technology being put to use to help people who may not otherwise be able to have access to the same advances we do.

If you’re interested in enterprise search, you should consider paying The Noisy Channel a visit.

Other posts of possible interest...

• Metadata Schmetadata, Relevance and Reality
• Revised: What the LSNC Shared Portal now looks like
• TIG final evaluation report for The Findability Project
• Selecting GSA targets – Part Three: Quantification, Revision and Finalization

• Metadata matters.
• Metadata adds worth to data.
• Documents are data.
• Keywords are the essential data in documents.
• Keywords in context create knowledge.
• Documents have worth because they contain knowledge.
• Enterprise search finds keywords.
• Findable keywords yield documents.
• Findable keywords in context yield documents with knowledge.
• Knowledge in documents has worth.
• Metadata is not essential for enterprise search.
• We don’t need metadata.

What’s our point? Before answering that question, we invite understanding of the context: This project is about implementation of enterprise search within a large but not humongous non-profit organization. We’re talking about 170 paid employees, with easily an equal number of volunteers of one kind or another. So let’s say for purposes of context that we have 350+ real people using our networked infrastructure. We have two — count ‘em, two — IT guys. We’re not talking Fortune 500 here. We’re not even talking Fortune 500,000. That’s our world.

Working on this project, we have evaluated what we need from metadata as part of enterprise search implementation. Our conclusion? We don’t need metadata.

Or better said, we don’t need to add metadata for a Google Search Appliance (GSA) to accomplish what we want to accomplish with enterprise search. We could use metadata more — and there are several very impressive features in a GSA that can exploit external metadata and metadata biasing of search results — assuming the organization has the resources to organize and manage metadata. But as a practical matter, do we have the resources to go down that path and, ultimately, do we need it? No.

In fact, as part of this project, we have put a metadata model in place, a simple “labeling” or tagging system. It exploits our Sharepoint server installation with a practical (if kludgy) way to add metadata to files saved to a shared document repository. For example, when saving a file in a directory in our structural taxonomy, as the user navigates — say, to the Income Maintenance folder…

…a dialog box pops up with a prompt to add one or more optional “LSNC labels” to the file, associating the file with additional folders or categories in our taxonomy:

In the above example, an Excel spreadsheet with unemployment data is being saved to the “Unemployment Insurance” folder, a subfolder under the “Income Maintenance” top-level directory, but is also marked or tagged as “Data-Statistics-GIS” and “Employment.” Even then, this kludge only works with Microsoft applications, which is to say Sharepoint doesn’t work as cooperatively with other applications we rely on, like WordPerfect, Adobe Acrobat and others.

Regardless, is the addition of metadata to documents a good thing? Obviously, yes. Metadata matters. (Taxonomy matters, too… yet to what purpose?) Do you need to add metadata to documents for effective enterprise search, and specifically with a Google Search Appliance? Not really, not for what we are doing. Why not? Because improvements in search algorithms are such that metadata is not needed to help the search.

The poster child for these gains in enterprise search algorithms is, not surprisingly, Google whose GSA has matured considerably. Google is a verb. Microsoft (or Sharepoint) are not. A principal reason for that is Google years ago broke out early from the search-engine pack and raised the bar in terms of quality of search results. Google became what the average person now expects from search. That is why it is a verb. It is what most people do. They Google. Another reason is that Google simplifies search.

In the context of our project, at the scale and with the resources available to even a fairly large non-profit, what is practical or impractical in using metadata? And even if used, does it affect the quality of enterprise search results enough to warrant those additional costs in time and money?

So far, we don’t see it.

Other posts of possible interest...

• Revised: What the LSNC Shared Portal now looks like
• Selecting GSA targets – Part Two: The Practical Realities
• The Findability Project Taxonomy – Part Three: The Anecdotes
• The Findability Project Taxonomy – Part One: The Theory

The infusion of new, future content into the simplified structural taxonomy we created is a separate challenge we will be posting about later. Dealing with our existing files is more immediate, more concrete. Groking those files has been one of the more interesting, at times hilarious parts of this project.

For those legal services programs interested in how the existing files from our eight local offices break out, here are the percentages for the seven most common “document” types:

• 67% – WordPerfect (WPD)
• 18% – Word (DOC)
• 9% – Portable Document Format (PDF)
• 3% – Excel (XLS)
• 1% – Text (TXT)
• 0.9% – Rich Text Format (RTF)
• 0.6% – PowerPoint (PPT)

(Discretion prohibits us from detailing the other file flotsam discovered on local office servers. That said, allow us to observe that some within our organization have extraordinarily good taste in photos taken by National Geographic, and not such good taste in music.)

We are totally on track for targeting most of our planned GSA targets: The existing office archive files listed above have long been targeted (although we still have a lot of work left to fit them into our structural taxonomy); over the last several months we have worked very hard to refresh and update (and remove, as warranted) the targeted content at LSNC’s various public websites; and we are very pleased with the quality of the GSA results we are getting out of Google Sites.

This is all good news. In addition, we are putting in place a few more content channels: Targeting the content in our organization’s seven private Google discussion groups, and a program-wide canvass for select hard-copy training resource materials for digital conversion and addition to the shared repository. It’s all good.

We have had one major disappointment: We discovered that there are significant, unanticipated technical challenges unique to the Pika CMS that thus far have prevented effective use of the GSA to target Pika content. The problem is not the GSA itself or configuring the GSA to target Pika. The GSA by design performs wholly benign, non-destructive crawls as it indexes targeted records. We did a huge amount of target testing and SERP evaluation, and we were very pleased — actually, thrilled is a better word — with the results we were getting from Pika. The unanticipated problem is that the current version of Pika is not well optimized for use as an enterprise search target. There are code anomalies in Pika that, among other things, cause it to auto-generate new case intakes and case records when it is crawled by the GSA.

After an assessment by Pika Software, it is now apparent it will take something in the neighborhood of 200 hours of work to make Pika more receptive, shall we say, to an external crawl by the GSA. (Ouch!) So for now, we have to put that part of the project to the side. File under: Lessons Learned.

Other posts of possible interest...

• Selecting GSA targets – Part Two: The Practical Realities
• Revised: What the LSNC Shared Portal now looks like
• TIG final evaluation report for The Findability Project
• Metadata Schmetadata, Relevance and Reality