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