I hope this series on search has been helpful to users and professionals alike. Let’s close it with a look at taxonomies in SharePoint.
Let’s look at this data flow in another way. We have incoming information; going to dump into a repository. We need to add metadata to that repository. We want to add taxonomy terms. The taxonomy terms all need to be controlled or suggested. So, there’s a back end to do that. Once we have the data in that repository, it could be exported to a SQL or a relational database, transactional system, for e-commerce. It might be put into a repository so that the full displays can be done. It might be loaded into a search system and you also might have a presentation layer for display.
If you can, it is nice to save data to the search and the repositories all at the same time, so that when you save a record in one place, it saves automatically to all of the other places. That would mean that you would have a lot of immediate availability of the information to everybody. You can kind of group this sort of stuff that I just showed you that is all over the map into your source data, cleaning and enhancing the data, and making it searchable. You want to be able to get your data, load it and clean it up, and then export it to the several repositories with different requirements.
If you are doing that in SharePoint, it’s very similar. You have your client data; you have your own taxonomy; you run it through a battery of stuff to clean it up; dump it into the repository. You still need search software, separate. SharePoint actually comes with a small search system, but if you have a lot of documents, you will need to have something more robust for search – make it faster, faster query speed, faster results processing, etc. And, if you add the taxonomy back in at the front end, you can browse and increase the accuracy of the search results.
We’ve covered how search works and how to measure accuracy in search, and we’ve discussed some of the theoretical bases. We also discussed the taxonomy effect.
I really strongly recommend that you do the data first, if you can. Many of you have been able to before, but now all of you can. But, assess what you have. What does it need? How would you like to access it? What features do you like? Give lots of examples if you can find them. Look at the data before you create the specifications, because a DTD built without data isn’t going to work for your data. You’ll have to go back through a whole new big processing round. If you choose the system that will support your data first, then you are really in good shape. It is amazing to me that people don’t do that.
Marjorie M.K. Hlava
President, Access Innovations