Hi Stephen, Mike,
It's a really interesting point about the flow of modifications back into source. In the Europeana Inside project, one aim was to evaluate the challenge of round-tripping data back into the source dataset. In practical terms, we barely managed to establish a basecamp, much less scale the mountain of issues.
Round-tripping would seem to have value in a couple of senses. Most specifically, if a museum has time only to create tombstone data about an object, which is then significantly enriched (whether through human intervention such as a crowd transcription project or automatically such as the enrichments that Europeana adds as part of its ingestion process) then that is higher quality data which the museum hasn't had to pay to make.
The biggest challenge seems to be the 'trustability' of the returning enrichments. If you say to a museum professional "here's the 120k records you uploaded to our platform, 30k of which have been enriched. Do you want to accept them back into your core Collections Management System?" they understandably get a bit nervous..
Presumably in a 'pure' COPE setup you wouldn't just separate the management layer and the presentation layer, but also the data layer, so that you effectively have a core set of re-purposable data surfaced through a management interface for collections management use and any number of interaction interfaces for other uses. I am not sure we're ready to go there as a community, but if you put the internal user on an equal footing as the external user, then it becomes less about exporting from back-office to front, and more about configuring a set of services to interrogate an underlying repository which doesn't change too frequently.
All best,
Nick
Nick Poole
Chief Executive
Collections Trust
Tel: 020 7942 6080
[log in to unmask]
LinkedIn
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
> On 21 Nov 2014, at 07:47, "Stephen McConnachie" <[log in to unmask]> wrote:
>
> Hi Mike,
>
>> "From a theoretical 'we don't like duplicated data' point of view, you totally have a point. But from a reality point of view where the metadata in these records doesn't actually change that much - and where the ingestion takes a few minutes every, what, week? - the upsides are fairly tangible I think."
>
>
> This seems to be a model that's quite common in the big organisations (nationals etc) using Adlib: take the collection records into Drupal (maybe Wordpress too now there's a nifty tool!) via Adlib API, based on a scheduled query against modification date / time a eg a daily overnight import - cache the records in Drupal using a schema or organising principle which lets the web team deliver data to any spots in the web front end / VOD platform / social media.
>
> I agree the source data changes so little (statistically) that the overhead is low, and the benefits high for the web developers. For me the key principle is the data is Created Once in one master system, Adlib, and modified only in Adlib, not in Drupal. Synching changes in two directions seems like a bad idea.
>
> However, all that said, the philosophy of caching in a CMS I think will eventually erode the idea of COPE: already I can see pressure points where curators / editors want to tweak the descriptive metadata in Drupal instead of Adlib. As system manager I resist that, but once it's in Drupal, it's out of my jurisdiction, so....
>
> Sent from my iPad
>
>> On 20 Nov 2014, at 12:23, Mike Ellis <[log in to unmask]> wrote:
>>
>> Probably an off-list discussion, preferably over a pint :-)
>>
>> But: personally I think that not having collections data which is _actually_ part of your CMS content can be part of the "oh, that's the collection, over there" problem. And that - see earlier rants about how dull lists of *stuff* can be - doesn't do museum objects any justice.
>>
>> Part of the point of ingesting the metadata into the CMS itself is that you can then actually do _rich_ stuff with that content, not just search.
>>
>> So as examples, you may be..
>>
>> - writing a web page and want to feature a related object in the sidebar
>>
>> - developing an online exhibition or game where you want to add related objects into the flow of the narrative. An example is here: http://americanmuseum.org/about-the-museum/exhibitions/gangsters/ - if you scroll down you can see rows of object records, all of which are selected by simply selecting them from a list: the object name, description and title are all pulled in automatically (hey, COPE!)
>>
>> - writing a rich, engaging newsletter for use with MailChimp (more here if you're interested: http://www.thirty8.co.uk/2014/06/using-wordpress-to-build-mailchimp-newsletters/) where you pull in image and description assets for use elsewhere (moar COPE!)
>>
>> - developing game-based approaches such as quizzes, mystery objects or mobile tours, etc. This is where our focus is at the moment; we're building tools where the museum web editor can quickly put together these kinds of experiences really easily within a reusable framework.
>>
>> From a theoretical "we don't like duplicated data" point of view, you totally have a point. But from a reality point of view where the metadata in these records doesn't actually change that much - and where the ingestion takes a few minutes every, what, week? - the upsides are fairly tangible I think.
>>
>> cheers!
>>
>> Mike
>>
>>
>>
>>
>> _____________________________
>>
>>
>> *Mike Ellis *
>>
>> Thirty8 Digital: a small but perfectly formed digital agency:http://thirty8.co.uk <http://thirty8.co.uk/>
>>
>> * My book: http://heritageweb.co.uk <http://heritageweb.co.uk/> *
>>
>>
>>
>> James Grimster wrote:
>>> Mike, All
>>>
>>> I might be biased, but 'middleware' aggregation into a common interchange layer, be it via ECK to Dark Aggregator / and or CultureGrid , and then use a common API approach, seems absolutely the best way forward to
>>> achieve plugging collections search into Content Management Systems like WordPress; make WP *think* the object metadata is a post, and then have all the WP functions wrap natively around it.
>>> Rather than store the object metadata in the Content Management System itself.
>>> IMHO
>>>
>>> cheers
>>>
>>> --
>>> James
>>>
>>>
>>>
>>>> On 20 Nov 2014, at 10:51, Mike Ellis wrote:
>>>>
>>>> "Dark Aggregator"
>>>>
>>>>
>>>>
>>>>
>>>> cool.
>>>
>>> ****************************************************************
>>> 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/
>> ****************************************************************
>
> ****************************************************************
> 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/
****************************************************************
|