Dear Mia,
Many thanks for this (and also to the people who have been in touch offlist and via other channels asking broadly the same thing).
The article conflates a number of concepts into one, and it might be useful to unpack them a bit.
First and foremost, there is the core idea of 'Create Once, Publish Everywhere' (COPE) which, at heart is about the workflow of creating and managing content and the systems and data structures which support it.
The idea, which goes right back to the early days of web standards is to separate out the content layer from the presentation layer, so that content can (in theory at least) be reflowed into many different presentation formats. This achieves, to my mind, Mike Ellis's maxim of 'no single use data'.
In so doing, again theoretically, the distinction between 'internal' applications and 'external' ones becomes arbitrary. If the modelling and contextualisation of the data in terms of entities and relations is sufficient and if vocabularies are available as services rather than term lists, then it ought to be possible to derive your internal usage and your external usage from the same body of information.
It may well be true that the degree of automation drops off the more thematically-specific the application, to the extent that some hand-cranking/intervention is always going to be necessary, but even if we can't exclude *all* interventive processes, it is still a win if we can reduce them and facilitate their management as far as possible.
So it might be that the fringe cases at both ends - 'proper' linked open data at one end and highly curated thematic experiences at the other - are irreconcilable, and not amenable to automation, but that still leaves a lot of applications in the middle which can be built programmatically from well-structured and richly-described data.
It is not, though, that COPE necessitates the use of CIDOC CRM (and god knows, I've had my share of headaches with the CRM!), but that it necessitates the self-adoption by museums of a data model which doesn’t force us to restrict the natural complexity of our data and its many relations. Most of the candidate models - such as LIDO - require us to compromise richness in the name of interoperability. It ought, though, to be possible for the sector to adopt a rich data model of its own (in which case, why would you not use CRM, when so much effort has gone into it already and when it connects neatly to SPECTRUM Units of Information) and then to derive from this richness the transformations necessary to fulfil the needs of LIDO, the Europeana Data Model and many others.
So COPE doesn't require CRM, but it does require a rich museum-led data model which fully reflects the diversity of collections, and CRM is a good place to start.
Having got there, you are still left with the question of how people are actually going to *do* it in their organisation with their collection. This is a really complex question, and there isn't a single answer. ResearchSpace is a well-funded initiative that is producing some tools which enable people to collaborate semantically to enrich their data. Equally, tools like the CIIM from Knowledge Integration do an excellent job of unifying multiple datasets into a commonly-expressable structure. The idea wasn't to present ResearchSpace as the *only* approach to deploying a COPE strategy based on CRM, but it is an interesting example of one possible approach!
Judging by the offlist response, it seems there is an awful lot of interest in a full-on, hardcore discussion about the challenges and opportunities of museum informatics, data interchange and semantics. I'd welcome comments on the above, and will also share dates and potential venue (looks like somewhere in the North East would be popular, judging by current responses) asap.
With thanks,
Nick
Nick Poole
Chief Executive Officer
Collections Trust
Insurance for Museums Conference 2013
25 April 2013 • British Library Conference Centre
2-3 July 2013, The Kia Oval
www.openculture2013.org.uk
Linked
Join CT's Collections Management Group
Visit Collections Trust online
www.collectionstrust.org.uk
www.collectionslink.org.uk
www.culturegrid.org.uk
Company Registration No: 1300565 Registered Charity No: 273984
Registered Office: Collections Trust, WC 209, Natural History Museum, Cromwell Road, London, SW7 5BD
-----Original Message-----
From: Museums Computer Group [mailto:[log in to unmask]] On Behalf Of Mia
Sent: 02 April 2013 14:43
To: [log in to unmask]
Subject: Re: New blog on Collections Link - Create Once, Publish Everywhere & ResearchSpace
On 2 April 2013 09:55, Nick Poole <[log in to unmask]> wrote:
> I thought you might be interested in a new post that went up on
> Collections Link this morning looking at the 'Create Once, Publish
> Everywhere' (COPE) model for museum information and the work Dominic
> Oldman and his team are doing at the British Museum on the
> ResearchSpace project. All comments very welcome!
>
> http://www.collectionslink.org.uk/discover/sustaining-digital/1766-cop
> e
>
Nick, thanks for sharing this. I have lots of questions, but to make sure I'm reading the article as you intended, I wondered if you could expand on the types of data or information you're thinking of? And is COPE a solution for museums looking to make as much internal use as possible of their existing collections data (clearly a good thing), or is it also a solution for publishing content to shared external platforms?
Thinking aloud, in my experience, re-using tombstone data (e.g. the basic who, what, where, when) internally is unproblematic, and re-using contextualising information such as extended descriptions and interpretation is usually fine. While re-publishing content written for past exhibitions, catalogues etc to make the most of the knowledge created around objects has always seemed like an effective use of existing content, thematically-focused content can be less useful when read out of the context in which it was created, so some 'repurposing by hand' is required to create content that makes sense to the general reader.
When it comes to shared platforms, it's relatively straightforward to map to a shared data structure (your 'title' is my 'name' field, etc) though some detail is lost each time that's done, but finding a structure that works for objects across the range of museum collections is tricky, as every partnership project that's ended up with a lowest common denominator schema shows. The same goes for term lists/vocabularies - my Bronze Age might cover a different date range to yours, or your materials list might be much more detailed than mine. I suppose I'm wondering how this solves the tension between highly specific collections records tailored to and by the history and objects in each museum vs the desire to link collections across the sector as a whole that's complicated the move towards linked open cultural data over the past decade or so?
Or are we COPEing internally and doing the work of transforming to shared schemas for partnerships, cross-sector aggregations and open cultural data as necessary? This might at least save external developers having to deal with CIDOC, which tends to baffle even experienced GLAM developers; so my final question is how intimately is the idea of creating once and publishing everywhere is tied to CIDOC?
I hope it's clear that these questions are meant constructively, and apologies for any incoherence (I'm sneaking time from other writing to post).
Trevor, both links worked for me, perhaps the URL was shortened or broken by the Jiscmail software?
Cheers, Mia
****************************************************************
website: http://museumscomputergroup.org.uk/
Twitter: http://www.twitter.com/ukmcg
Facebook: http://www.facebook.com/museumscomputergroup
[un]subscribe: http://museumscomputergroup.org.uk/email-list/
****************************************************************
****************************************************************
website: http://museumscomputergroup.org.uk/
Twitter: http://www.twitter.com/ukmcg
Facebook: http://www.facebook.com/museumscomputergroup
[un]subscribe: http://museumscomputergroup.org.uk/email-list/
****************************************************************
|
