On 02/04/2013 15:40, Nick Poole wrote:
> 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'.
The idea of separating content from presentation goes back much further
than that, to the late 1960s [1]. There is a direct line from that
early work through to XML/CSS (etc.) today. (I'm not sure I would hold
up the current web as a shining example of this separation being put
into practice.)
In a museum context, back in 1977 your "expert cataloguer" would
actually have had a pretty clear idea of the long-term value of their
recording work, assuming that it was an MDA card they were recording
onto. [The date you choose suggests that this is what you have in mind
- please correct me if I'm wrong.] The cards, and the syntax rules for
the data they contained, were designed specifically to allow the
original manual record to be transformed directly into a structured and
useful computer-based information resource without any further
curatorial intervention. They would certainly include keyworded
information from the start. So maybe it was more 'Create once, retrieve
everywhere', and maybe it involved data entry staff and punched paper
tape, but the same principle was already at work.
> 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.
I would be very sad if 'proper' Linked Data turns out not to be useful:
this is surely the best quality information that will be at our
disposal, and therefore the most machine-processible. The challenge is
surely how to make our existing museum information resources as 'proper'
as they can be, with the least effort.
The other end of your spectrum ('highly curated thematic experiences')
is an interesting area, since it may be that it requires a rather
different approach. Personally, I don't think it is helpful to see
everything as "data", and in particular I would hesitate to force
textual resources into the RDF framework. So for descriptive resources,
the question of whether the CRM is appropriate doesn't even apply.
Instead, we should be asking what XML application (TEI, Docbook, ...) is
best-suited to encoding such resources. (I'm delighted that most word
processor files are now encoded as XML, but that doesn't help us much if
we want to separate presentation from content.)
The criteria should be that the information resources we want to work
with (a) have a persistent unique identity, (b) are reliably accessible
through the web and (c) are machine-processible.
> 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!
I think that a good way to implement the COPE idea is to embed the
ability to generate and publish integratable data into individual
systems. If you rely on an integration service to get the data up to
scratch (as for example Europeana are doing), you are already adding a
second layer (and cost centre) to the model. If the data can be
harvested and used as it stands, that enables its use in multiple
channels. This puts the onus on individual systems to support
adequately complex recording and 'URLification' of existing data; recent
developments (e.g. of 'web termlist' support in several systems) suggest
that this is an achievable expectation.
> 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.
Excellent. Looking forward to it ...
Richard
[1] http://www.sgmlsource.com/history/roots.htm
> 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/
> ****************************************************************
--
*Richard Light*
****************************************************************
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/
****************************************************************
|