Re. rights issues, first thing I thought of when I read Mike's email was a
scenario from the Maritime Museum:
"We need to update the credit line for the Greenwich Hospital collection."
"No problem, we'll just update it in the collections database and that will
feed across to the collections web site."
"We also need to change the paintings that have been imported into the
nmm.ac.uk CMS, and the CMS for {project X}, and this other microsite, and…"
(web team goes quietly mad)
Happened years ago. I still haven't forgotten the pain.
Cheers
Jim
On 21 November 2014 11:29, Mia <[log in to unmask]> 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/
****************************************************************
|