« DC-2006 Eprints Special Session slides | Main | On openness »

October 06, 2006

Big crashing sounds - I can hear you

Sunrise It's been a good DC conference this year and I thought I'd better write at least one blog entry while I'm here in Mexico.

The week started badly, with a missed connection in Mexico City thanks to a technical fault with our plane in Paris leading to an unexpected night in the capital and the need to Skype into the first day of the DC Usage Board meeting. I was travelling with Pete Johnston, who was attending the UB meeting as a guest in order to hear our somewhat negative deliberations on the proposed Collection Description Application Profile. The Skype connection worked just about OK – though network problems and a nasty echo at our end made for a less than ideal situation.  (The title of this post is based on Tom Baker's first words to us when we managed to get connected - which Windows subsequently decided to use as the title of our Skype 'chat' window).

But things got better from then on – in a hotel complex that was both conducive to getting some work done (though a more reliable wireless network would have been a bonus) but also somewhat scary in the way it (literally) locked out the real Mexico.

Personal highlights for me included the DC Architecture working group meeting and the ePrints Special Session – both of which, it seemed to me, gave a significant endorsement of the DCMI Abstract Model, and the direction in which it is going. Tom Baker has now finalised a joint roadmap for the UB and the Architecture WG which should see new DCMI Recommendations for the Abstract Model, the Namespace Policy and the XML and RDF encoding guidelines by Easter 2007, following comment periods some time after Christmas. Several plenary papers also made positive reference to the abstract model – so I really think we're on to something with it.

At the Advisory Board meeting on Monday, I questioned DCMI's current standardisation activities on the grounds that they no longer give the right message about Dublin Core. I must admit that I felt awkward in raising this issue since I'm well aware that people have put significant effort into the standards activity within DCMI – but getting DC's unique selling proposition right is key to our success in the future and any standardisation activity is part of that.

In short, it seems to me that DC isn't about 15 metadata elements – or even the slowly evolving list of 40 or 50 metadata terms that we have now approved. Rather, DCMI is the framework provided by the Abstract Model – a framework that supports a wide variety of metadata descriptions, using properties selected from anywhere that is convenient, and encompassing description sets that comprise descriptions of whatever set of entities is important to the task at hand. Rather oddly, we are now in a position where a DC description is a DC description even if it doesn't use a single DC metadata term!

If we keep presenting DC as a flat list of elements that can only be used to describe single entity resources then it’s not surprising that people, like the librarians at LANL, will see it as not being expressive enough for their needs and will turn elsewhere. There is no real excuse for people reaching this kind of conclusion, other than DCMI's inability to promote the real strengths it has to offer.

Don't get me wrong, ten years ago reaching consensus about 15 (or 13 as it originally was) metadata elements deemed to be important for resource discovery on the Web was an inspired move – and paved the way for everything that has happened since.  But we no longer live in the world of ten years ago. In a resource discovery world typified by full-text indexing, hypertext link analysis and powerful user-behaviour monitoring, 15 elements are both too simple to support the richer functionality required in some contexts, and too complex for the general purpose case.

The Usage Board decided some time ago that the original 15 DC properties will be replicated in the DCTERMS namespace. For me, this is much more than a technical convenience. It is a clear way of stating that these are simply 15 metadata terms, just like any others. There is nothing special about them.

The most important thing about DCMI is the framework provided by the Abstract Model – that is what we should promote as the key brand of Dublin Core. And if we feel the need to turn to ISO or IETF to make DC into a standard, then it is the Abstract Model that we should focus on, not 15 somewhat fuzzy metadata properties on a ten year old conference tee-shirt.

Image: Sunrise over Manzanillo, taken from my hotel balcony. [October 2006]

TrackBack

TrackBack URL for this entry:
https://www.typepad.com/services/trackback/6a00d8345203ba69e200e5508625e38834

Listed below are links to weblogs that reference Big crashing sounds - I can hear you:

» DC went beyond just a 15-element-set for quite a long time from Keven's Blog 数图研究
I totally agree with Andy Powells above assertion (as the title). Andy expressed it during DCAB meeting and afterwards in his blog post. Andy says: In short, it seems to me that DC isnt about 15 metadata elements – or even the slowly ev... [Read More]

Comments

The right message to who? Who needs to understand the abstract model? What is the message to the repository manager wanting to chose from several acronyms?

It's a good question, and I'm not sure that I have an answer. Having said that, I'm not sure that anyone benefits by only knowing that DC is 15 metadata elements - which is all that the current standards documents tell them I think.

Sure, most people don't need to understand the details of the abstract model, but they do need to understand the value that the model gives them. I think this applies across the board, from developers that are making implementation choices thru to those responsible for making strategic decisions.

As an aside, as I type this I'm listening to Michael Crandall's keynote at DC-2006. He is arguing that the key value of DC lies in the combination of the abstract model with the core set of metadata terms - and I think that he is right. What I was trying to argue against was any notion that we should only promote the metadata terms, in the absence of any reference to the model within which they now fit.

From the practical point of view, I am afraid that DC will never clear up the impression within people's mind that it based up by (starting from) 15 elements. It's almost a slogan to win people in defeating MARC etc. old-fationed schema. Remember old days we put aside the encoding and modeling things just because DCMI not ready to take care of them. Of course I think DCMI is in the right way now. Sometimes more is not always better. 15 elements set is still valid and will be valid for quite a long time cause there exist quite a lot of national and international standards. I think we may still encourage plain people to include plain DC elements description in their web pages and applations. Can we just layer our work and deliverables (recommendations) by different tiers such as element, schema, and model layers (and as far as I know, we already got two different model layer: the FRBR/OAIS… layer and the DCAM layer).

Forgive my English, I changed a little bit in my expression (as following. Please help me to delete the former one.
From the practical point of view, I am afraid that DC will never clear up the impression within people's mind that it based up by (starting from) 15 elements. It's almost a slogan to win people in defeating MARC etc. old-fationed schema in some e-field battlefields. Remember old days we put aside the encoding and modeling things just because DCMI not ready to take care of them. Of course I think DCMI is in the right direction now. Sometimes more is not always better. 15 elements set is still valid and will be valid for quite a long time cause there exist quite a lot of national and international standards. I think we may still encourage plain people to include plain DC elements description in their web pages and applations. Can we just layer our work and deliverables (recommendations) by different tiers such as element, schema, and model (and as far as I know, we already got two different model layer: the FRBR/OAIS… ontology layer and the DCAM really abstract layer).

The comments to this entry are closed.

About

Search

Loading
eFoundations is powered by TypePad