October 2008

Alastair at UHI comments on my most recent Metadata Interchange document revision. His post highlights a couple of places where I can see I need to clarify what I’m proposing in a future revision. I recently purchased a copy of the OmniGraffle diagramming tool, and Alistair’s post is a good example of why… sometimes a simple diagram really can be clearer than large amounts of plain text. Misunderstandings aside, I think we agree on most things.

One area where I’ve felt for some time we all need to express things more clearly is with regard to that thing we call “trust”. I usually break this down first into “technical” trust (which allows you to know you’re talking to the entity you think you are) and “behavioural” trust (which gives you expectations about the behaviour of a known entity). This isn’t the whole story by all means, but does allow us to see that trust isn’t a singular property; it’s more like a stack or chain of elements that we can build up into something we can actually use.

Any federation can choose to act as a trust broker at many levels; for example, one federation may have strictly enforceable rules controlling member behaviour while another may leave behavioural trust to bilateral arrangements between members (such as the commercial contracts that are usually present in content licensing situations). The UK federation is towards the latter end of the scale: as all federations do, it acts as a broker of technical trust, but mere presence of an entity within the UK federation’s metadata has never carried any behavioural guarantees.

What this means is that if you’re used to operating in something like the UK federation, your stance is already to treat everyone as a potential ray-gun-toting Martian unless you have some specific reason to view them otherwise. Adding more Martians from other federations therefore doesn’t change anything; the important thing that an inter-federation agreement adds is the assurance that the originating federation has registration procedures strong enough to prevent a Martian from masquerading as someone you have a real relationship with, and conversely provides technical trust strong enough to support you in picking the entities you do want to do business with out of the sea of entities you don’t care about.

Many thanks to everyone who commented on the previous edition of Some Notes on Metadata Interchange. I’m in New Orleans for the Internet2 Fall Member Meeting this week, and as I expect to be discussing this area with a number of the other people attending I think this seems like a good time to publish a revision. This edition goes into more detail in some areas, as well as improving sections which needed clarification.

• snomi-v3.pdf is a clean copy of the document for new readers
• snomi-v3-diff.pdf includes change indications for people who have read the previous edition

I continue to welcome comments and discussion. The next edition might be a couple of weeks away, but will likely go into more detail on what I think an aggregation appliance might need to include.

I own two Uninterruptable Power Supply units. Each has a button on the front with which you can perform a self-test; I do this once a month to make sure that they are “still good”.

On unit A, you tap the button and it does a self-test. If you press and hold the button then the unit turns off, taking the attached hardware with it.

Unit B (from a different vendor) requires you to hold the button in to perform the self-test. Tapping the button… no, why don’t you guess what that does?

Sneakiest attempt at vendor lock-in I think I’ve ever come across.