Category: Taxonomy

Join us at Taxonomy Bootcamp this week to hear all about Blockchain

Posted by Leigh Hanton in Blockchain, Company, Information Architecture, Information Governance, Metadata, Ontology, Taxonomy

The skies may be grey and an umbrella the accessory you simply can’t live without – just means you have all the more reason to come to Taxonomy Bootcamp this week in Olympia, London!

Metataxis directors, Marc Stephenson and Noeleen Schenk will be presenting on ‘Blockchain: Emperor’s new clothes or essential knowledge organisation technology?’

Metataxis has participated in and supported Taxonomy Bootcamp over the years. It’s rewarding to see its scope and relevance increase as the benefits and necessity of managing, protecting, describing and discovering information and data are recognised.

So many possibilities and potential to explore at Olympia this Tuesday and Wednesday. If you would like to catch up with Metataxis staff during Taxonomy Bootcamp, please contact us here.

To follow good news with more good news – Metataxis are delighted to announce that our application for the Digital Outcomes and Specialist 4 has been successful!

This framework makes it quicker and simpler for the public sector to find and engage with suppliers across a range of digital services. Being a preferred supplier on the Government’s procurement framework makes it easy for public sector organisations to access the specialist information management and architecture expertise Metataxis are renown for.

If you would like our support for your digital transformation project, please click here to contact us.  

Metadata, taxonomies and retrieval – an ISKO event

Posted by Meg Shallcrass in Information Architecture, Information Management, Knowledge Management, Metadata, Ontology, Taxonomy, Uncategorized

On Friday April 5th I was lucky enough to attend the ISKO event Metadata, taxonomies and retrieval, which was held at City, University of London after the ISKO AGM. After introductions by ISKO chair David Haynes, 4 very different speakers covered a range of topics, all around the theme of metadata, taxonomies and retrieval.

Getaneh Alemu opened with a detailed look at how he and the library team at Solent University have improved discovery across the library catalogue, using his four main principles of quality metadata. Building on his PhD work, Getaneh outlined the four overarching metatdata principles for successful search: metadata enriching, linking, openness and filtering. Using these principles as guides, he has been able to analyse user search patterns and inform more efficient cataloguing practices at Solent.

Next we heard from Cancer Research UK’s Taxonomy Manager, Thomas Alexander. Thomas has led the development of a system-agnostic single taxonomy at Cancer Research UK, creating a common language across the whole organisation. This single taxonomy is shared across their external website, internal SharePoint site, and IT helpdesk services. While this common vocabulary has made finding information easier across the organisation, it required several stages of user testing and validation, and is slightly restricted by SharePoint functionality in some cases. Thomas hopes that having the solid taxonomy established will be a great place to start any future ontology projects he has in mind.

After a refreshment break, Niké Brown presented around taxonomy challenges in digital publishing. Niké has many years’ experience in this field, and even remembers her former company launching their first ever CD-Rom, a format and content challenge that helped launch her particular interest in this topic. We were taken through several examples of different approaches to digital publishing taxonomies, and the challenges faced by each. Several points were raised linking to the previous presentations, around the pros and cons of one large, all-encompassing taxonomy vs. multiple smaller, specialist taxonomies, and the importance of proper metadata enrichment.

The final speaker was Eugene Morozov, who talked about W3C Semantic Web standards and discoverability of regulatory rulebooks. Eugene went over some of the pros and cons of Model-Driven Machine Executable Regulation (MDMER), and the benefits this developing field could have in the future. Building on the 5-star Open Data rating scheme, Eugene provided examples of various regulations and rated them accordingly, including an axis of granularity and an axis of semantic richness to provide a fuller picture.

The audience was then invited to ask questions of the 4 speakers in a panel discussion, addressing the questions Metadata and Taxonomies: best hidden behind the scenes, or fully exposed to users? All speakers had different experiences of both these approaches, and all ultimately agreed it depended on context. There was a consensus around the importance of having enough information for users to be able to narrow down their search, help with ambiguous search terms find related terms etc, without providing an overwhelmingly large full taxonomy. Some interesting points were then raised around AI and machine learning, as well as voice search and how taxonomies will apply and be available for voice search results. All panellists believed the most important thing regardless of the approach adopted is having high quality taxonomies in place.

Overall it was a thoroughly interesting afternoon, with some great speakers and thought-provoking questions. I look forward to the next ISKO event! https://www.iskouk.org/events

SharePoint folders are NOT intrinsically bad

Posted by Marc Stephenson in Information Architecture, Information Governance, Metadata, SharePoint, Taxonomy

The blogosphere is full of SharePoint consultants proclaiming how folders are a terrible thing. Many of the articles are from, I suspect, SharePoint consultants who have just realized that information architecture (specifically metadata in this context) is something useful, and aren’t sufficiently concerned about bringing round change-averse users.

Before I explain why some folders may be a good thing, let’s look at the standard “why folders are bad” list…

  1. Nested folder structures are usually specific to an individual user or team. True, but so can metadata be. This is isn’t an argument against folders, it’s an argument for naming things consistently and governing what they are named. i.e. have a well managed taxonomy. Also, as with metadata, it can sometimes be useful to have a truly local name for something, either because it really is a local thing, or you want to build buy-in from your users by letting them sometimes give things their own names (I am not saying there should be a free for all, just some concessions, sometimes).
  2. Folders tend to make content hidden. Yes they can, again if poorly named (like metadata). But this assumes hiding content is a bad thing, when in fact it can be a good thing. Namely, it’s useful to just show users the things that they care about in that moment, with nothing to distract them. This exact argument is the reason SharePoint views are so useful and powerful.
  3. Folders eat up the fixed portion of the SharePoint URL. Yes. Agreed. But only if you go crazy with folders. See my rule of thumb below.
  4. Moving files from one folder to another changes the URL if you link to it. Yes. Agreed. Especially if you don’t have an information architecture. But luckily there is a way round this – have an information architecture. If you have a good information architecture, content tends not to need to move around much if at all. Of course if you move documents into a different library the URL will break. The real answer to link rot is use document identifiers, that don’t contain their location. SharePoint provides such functionality (more or less).
  5. Maintaining security by folders in SharePoint is an administrative nightmare. Yes. Agreed. But something you often have no choice about, even with a good information architecture. Also, what’s the alternative? Rather than creating a folder to delimit the security, create a new library, or a new site. That’s just as bad (possibly worse) at fragmenting content.
  6. Finding documents is difficult. Yes. Agreed. It can be (see the need for an information architecture, ad nauseum..). But less so if you use folders and metadata. Check out standard SharePoint view functionality on how to do this.  Sometimes the folder structure makes it easier to find what you want. We know that search doesn’t always work, whether you’ve got metadata or not, because you don’t know what you don’t know. Folders allow you to browse, which is frequently very helpful.
  7. File duplication. With folders you can store multiple copies of the same file in different folders. Yes. Agreed. But you can do this without folders also – across libraries and sites. Folders can make it worse, but file duplication across sites is far more common (many teams copy documents to their team site to ensure they can always be found). If this argument is simply extended, why not put all 30 million documents in one mega-library!?
  8. With folders there is only fixed one view. Yes. Agreed. But only if you only use folders: why not use metadata as well and get both the options? Why deliberately remove a useful way of organising and finding content?
  9. Sorting and filtering isn’t possible. Yes. Agreed. But only if you only use folders: why not use metadata as well and get all the options?
  10. Changing folders is harder.  Well, sometimes. But change should be not so common with a good information architecture. Also, changing lots of metadata isn’t always easy either. Cut and paste between folders can be much easier.
  11. You lose context when navigating. Not really. There many ways of showing the folder context in SharePoint. Also, just using metadata can be worse, especially if you use multiple columns and filters simultaneously.
  12. Using nested folders is just like having a file share, why even both with SharePoint? Yes. Agreed. But only if you only use folders: why not use metadata as well and get all the options? Can you spot a trend here…?
  13. You can’t see how many documents are in a folder. Yes. Agreed. But only if you only use folders: why not use metadata as well…
  14. When you allow users to create folders, you are prone to misspellings and so on. Yes. Agreed. That’s why you need active governance, and templates (i.e. an information architecture). Metadata can be much more easily made consistent, but that requires upfront effort and ongoing management. All this is good, but you haven’t improved the situation by disallowing folders, you’ve just moved the problem somewhere else.

And now for the reasons why folders are OK in moderation.

  1. Usability. Users like them, a lot. You will have many other battles to fight with users when you ask them to use SharePoint. It’s very useful to give them something familiar while you simultaneously introduce them to the benefits of metadata, search, views etc.
  2. Grouping. Sometimes users need to have a loose grouping of content. Looser than a document set, and looser than can be easily defined using one or more metadata tags.
  3. Permissions. Folders can be used to group user permissions. See above. Not ideal, but much better than file level permissions.
  4. Default metadata. Folders can be used to auto-populate default metadata. This is one of my favourites. Ask a user to fill in a metadata field and they will baulk. Ask them to add a file into a specific folder (with default metadata) and they won’t blink an eye. Agreed that there are many issues with doing this, but with a stable information architecture it is achievable and results in good metadata with minimal user effort.
  5. Retention and disposal. Folders can be used to hang retention and disposal rules on. Of course content types can also be used for this, but sometimes that doesn’t fit your content so well.
  6. Hiding. Folders can be used to hide content. See above. It’s useful to just show users the things that they care about in that moment, with nothing to distract them.

And to round off, my rules of thumb for SharePoint folder use are:

  1. Many document libraries will not need folders. How many depends on your information architecture, which in turn depends on the content, context and users in your organisation.
  2. One level of folder is acceptable, but you have to convince me. I’d say I’m convinced 50% of the time.
  3. Two levels of folder are acceptable, but you really have to convince me. I’d say only 10% of libraries can justify two folders deep.
  4. Three levels of folder are not acceptable. If you need them, your information architecture is wrong. It needs shifting up a level, so that your one deep folder becomes a library, your two deep folder becomes a level one folder etc. (on some very rare occasions I have felt three levels of folder are permissible, but this is only in cases of very structured content).

To wrap-up, SharePoint folders have their place, and can be used in moderation. But don’t go crazy.

Why SharePoint needs an information architecture

Posted by Marc Stephenson in Information Architecture, Metadata, SharePoint, Taxonomy

Many SharePoint implementations are unsuccessful. They do not deliver business benefit, are too expensive to build, too expensive to manage and are difficult to use by the stakeholders they are seeking to help.

SharePoint is a large, pervasive and complex system and as such is subject to the usual reasons for failure of all similar sized systems; but SharePoint in particular frequently fails because it has no information architecture underpinning the content, users and context of the organisation’s information environment. In most cases this lack of an information architecture is due to the implementation being IT driven. SharePoint in all but the most trivial of implementations is not an out‐of‐the‐box system – despite what many people believe and the Microsoft marketing machine suggests.

An Information Architecture within SharePoint is crucial because there are many design and configuration decisions that need to be taken before the implementation starts. In addition, many of the fundamental information structures within SharePoint are not easily changed once the implementation starts.

Information Architecture Phases

The information architecture activities for implementing SharePoint can be broken down into four phases:

  1. Analysis: Discovery of content and structures that already exist within the organisation
  2. Design: Creating the information architecture itself (see below)
  3. Configuration: Implementing the information architecture as determined by the design
  4. Testing: Validating the information architecture and reworking in light of user feedback

Key Aspects to Consider

The design of a SharePoint information architecture must consider a number of aspects of SharePoint functionality.

  • Site Plan: Information to be stored and accessed within SharePoint must adhere to some overall structure. Whilst SharePoint does not implement a classical “fileplan”, one must be created never the less.
  • Interface Structure (Usability): Once the site plan has been created this must be mapped to appropriate SharePoint interface structures.
  • Content Types: Content Types are one of foundations on which much of SharePoint’s functionality builds. Therefore, getting the Content Types correct is of prime importance to any SharePoint development.
  • Metadata: The metadata schemas to be used within SharePoint must be defined. This metadata is primarily related to the Content Types, but also in other key SharePoint structures.
  • Taxonomies: Any controlled vocabularies required to populate metadata fields or define navigation structures must be defined.
  • Search: Defining the parameters of the search and attendant user experience.
  • Permissions Model: A SharePoint implementation must define the permission model that applies to it – namely who can do what to any given item of content.
  • Workflow and Versioning: Any organizational document workflows that are needed must be defined.
  • Policies and Governance: Whilst SharePoint allows significant codification of the information architecture and its usage, there will always be a need for policies and governance guidelines.

SharePoint lends itself well to having its configuration performed by information architects rather than software developers. The reasons for this are two‐fold: the detailed and comprehensive set of configuration options that are exposed via the administration user interface; and the pervasiveness of these options throughout the many SharePoint information structures.

PDFIcon Download this article.
%d bloggers like this: