IdeaScale : We should embrace inconsistency

We should embrace inconsistency

Wed, 02 Jul 2008 00:00:00 PDT

-5

We cannot achieve consistency, so if it is important then we are doomed to failure. Why can't we achieve consistency?

There are (say) 200 universities in the UK, and perhaps 20,000 worldwide, then there are subject repositories, project repositories, library and archive repositories and commercial repositories (which may be free or charged for or a mixture).

There are data repositories, image repositories, paper repositories etc.

All these repositories are set up for particular reasons and will want to achieve different things. What the BBC wants people to do with their's is very different to say NICE or the University of Wigan. They will, inevitably, have different collection policies, different ideas on appropriate metadata standards, different methods of accessing them (an image repository or data repository will require different affordances to a text repository).

To expect any form of consistency - of language, of policy, of metadata, of standards even of legal scope will simply not work.

Indeed, I would suggest that to achieve consistency we would require working in a closed community, and even then it would probably not work.

The alternative is to embrace inconsistency and work with that.

Comments (3)Category/Tags : Consistency (11) consistency repository Mark as duplicate

Comment by ianibbo

Mon, 07 Jul 2008 00:00:00 PDT

Don't quite know what this means in practice - If we are suggesting that we should let a thousand flowers blossom (As it were) and not try to adopt any standards (Policy,Metadata,Protocol,Service Discovery,Terminology) then I'd probably vote down here. If the suggestion is that we shouldn't be mandating individual standards but instead creating an environment where new services can be created and interact then I may vote up.

The point about "What the BBC wants to do is different to NICE" is well made, but third parties using those repositories might want to do exactly the same to both repositories... why should we make such third parties learn two different things? At the end of the day, it's all about that minumum level of consistency required to maintain some cohesion amongst repositories and repository services. I'm not sure a polar view of structured/unstructured consistent/inconsistent dimensions helps getting that right?

Comment by tom

Mon, 07 Jul 2008 00:00:00 PDT

My point was really that we are not in a position to mandate, that many people will not follow any standards that are set, and if we set minimum requirements then we may exclude from what we are doing useful datasets that either dont know or dont care about what we are doing.

If that analysis is correct - and I believe that it is - then what we have to do is develop tools that are capapble of working with the inconsistent data and presenting it to the user as helpfully as possible. That is what I meant by embracing inconsistency.

I did some work on the RDN/LTSN Learning Object Metadata Application Profile (RLLOMAP) once upon a time, and people were not using it in the same way, or completing all the "mandatory" fields, so the question was what to do. I argued that we should make use of whatever information was available - essentially treat all fields as optional, and try to help the user. Yes, they may miss stuff because it was poorly catalogued, but they would definitely miss it if we rejected it because manadatory fields had not been completed.

Embrace inconsistency and develop methods to make the inconsistent as useful as possible to the end user.

Hope that helps.

Comment by jak

Wed, 20 Aug 2008 00:00:00 PDT

I prefer to think of embracing consistency at an extremely scaled back level, namely, who, what, when, and where, while permitting a great deal of inconsistency beyond that.