FWIW from our point of view we're looking into this side of things as 
part of the plugin build.

The ways we're doing this at present are:

 > any core fields that are brought into the WordPress CMS by the import 
process are overwritten next time the job runs, dependent on fieldname. 
So if you have field "title" in the object record and we go fetch data 
then any "title" fields in the source will be replaced

 > any additional fields that have been added within WP - for example a 
richtext field called "web text" - would be left untouched. So authors 
can add additional stuff on top of the "core" data and this'll be left 
alone, even when the next import runs - provided the unique identifier 
hasn't changed of course.

 > commenting, tagging, etc are all easy to do, and identifiable by post 
ID and thus indirectly by whatever identifier is being used on the 
object metadata - accession number of whatever.

The net result is that any additional content is stored locally and 
(this is in future release) will be available to download as XML, JSON 
or whatever.

What I don't know because I haven't looked into it yet is how or whether 
the CM systems can take a filtered feed of this round-tripped data and 
ingest it themselves. As Mia says though, this seems like a thing that 
needs solving.

Any thoughts on this always good to hear..

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/> *


On 21/11/2014 08:13, Nick Poole wrote:
- show quoted text -Surely that's a matter of simple provenance 
logging/control?  Just as Europeana puts effort into recording the 
source of each aggregation which it ingests (using the ORE proxy 
mechanism), so it claims to log the provenance of any enhancement [1]:

"EDM enables data enrichment from a range of selected authoritative 
sources. For example, a digital object from Provider A may be 
contextually enriched by Europeana by the addition of data from 
authority files held by Provider B, or from a web-based thesaurus 
offered by Publisher C. The provenance of such additional data is also 
provided."

I would certainly get nervous about blindly accepting large-scale 
updates to my core collections data, but would be relatively relaxed 
about putting them into a separate-but-linked database/triple store 
where they could be used or not as I chose.  (Of course, if these 
enhancements are available as Linked Data, there is no need to re-import 
them at all.  Just use them "in place".)

Richard

[1] 
http://pro.europeana.eu/documents/900548/f495317b-4557-4a60-9326-723f4618b44c 



Mia wrote:
> My two p... I think collections records should reflect the state of the
> collections database where possible, as it allows for any corrections made
> to appear on other websites. This also allows for records to disappear when
> needed, for example when a rights issue has been uncovered or there's
> another reason for a record to be taken down while a query is investigated.
>
> The issue of taking in corrections and enhancements contributed by the
> public is something that really needs to be solved soon - surely systems
> that can cope with layers of curatorial and interpretive content could find
> ways to cope with layers of not-yet-verified contributed content? (But this
> is an old question, so obviously it's not that easy, or there hasn't been
> enough demand for it...)
>
> Cheers, Mia
>
> --------------------------------------------
> http://openobjects.org.uk/
> http://twitter.com/mia_out
> Check out my book! http://bit.ly/CrowdsourcingCulturalHeritage
> <http://bit.ly/CrowdsourcingCulturalHeritage>
> I mostly use this address for list mail; my open.ac.uk address is checked
> daily
>
> On 21 November 2014 08:13, Nick Poole<[log in to unmask]>  wrote:
>
>> 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/
>> ****************************************************************
>>
>
> ****************************************************************
>         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/
****************************************************************