On 20/12/2012 09:22, James Grimster wrote:
> thanks Mia
>
> is it possible to get a critical mass around a standards based interchange? a different API for each CollMS is fine all the
> time your audience is connecting to a single source. What happens when you've got multiple CollMSs, or
> multiple data sources like archives and archaeology in the mix?
Hopefully these disparate APIs can start to look sufficiently similar to
each other that searching across them becomes feasible.
I think the Linked Data approach offers one way forward: see Bert's
announcement yesterday to this list that Adlib are planning a data
publication service which includes Linked Data capabilities. The MUA
are also developing a Modes Linked Data Framework ("MLDF"), which will
allow any Modes user to publish collections information as Linked Data.
If other system vendors follow suit, it would become possible to access
any object's data via its unique, persistent URL.
That deals with the publishing side of the equation. On the consumption
side, Modes, Adlib and CALM have all implemented some sort of "web
termlist" functionality, which allows users of their systems to select
URLs from web-based authorities and include them in their data. (Unless
our Linked Data is chock-full of standard URLs representing our shared
understanding of cultural history, it won't be worth having. So we need
a mechanism for getting those URLs into our data.) All the standard
Modes termlists are now available as Linked Data (for anyone to use) at
data.modes.org.uk [1].
> With a federated approach combining relevancy scoring across search is challenging - ref Ade's presentation on JISC WW1 at MCG
>
> So surely future-proofing middleware must sit in the, er, middle of all this?
> Talking to Paul from Vernon/e-Hive/DigitalNZ: there's lots of SOLR based indexers with various, but similar, RSS style search responses as APIs on top (as per Europeana).
> If the 'common' interchange in the UK were, for example, Collections Trust's SPECTRUM XML interchange ....
> --
> James Grimster
> www.orangeleaf.com
There are two aspects to this: how do you ask questions, and what form
do you get your answers in.
The "asking questions" side could be addressed by SOLR-style queries, by
adopting Opensearch [2] (which is what the MLDF is leaning towards;
partly following a suggestion of yours, James), or by going the whole LD
hog and providing a SPARQL end-point.
SPECTRUM XML would come into the second aspect: delivery formats. I
wonder whether we should be moving on from this and looking towards a
vendor-independent RDF delivery format, based on best practice use of
the CIDOC CRM [3]. For a start, we could do worse than look at what the
British Museum have done when they release their updated Linked Data
site [4].
Richard
[1] http://data.modes.org.uk/Termlist/void/rdf/ lists the resources
available. Search has this syntax:
http://data.modes.org.uk/Termlist/HertsSimpleName_termlist/search/rdf/?q=rope
while individual concepts have URLs like:
http://data.modes.org.uk/Termlist/HertsSimpleName_termlist/id/ball
[2] http://en.wikipedia.org/wiki/OpenSearch; http://www.opensearch.org/Home
[3] http://www.cidoc-crm.org/
[4] http://collection.britishmuseum.org/
>
> On 19 Dec 2012, at 23:43, Mia wrote:
>
>> What a great thread! I'd agree with what Nick Poole and James Grimster
>> said above, and...
>>
>> On 30 August 2012 11:51, Richard Light <[log in to unmask]> wrote:
>>
>>> We probably need to give more thought to engineering the pipework through
>>> which our information flows. It probably won't be too long before a typical
>>> cultural heritage institution is storing its core information in three or
>>> more places (collections management system, image management system,
>>> blog/UGC/social media repository), and needing to meld and deliver that
>>> information to a variety of platforms and audiences. Writing each
>>> interface by hand simply won't scale.
>>>
>>>
>> I think I've spent too long away from writing code because making that
>> actually sounds like it'd be fun (as well as useful). The trick would be
>> making it enough like core business - perhaps as part of a digital
>> preservation or collecting strategy - to justify the resources. Each
>> institution has different needs, but there's already a number of WordPress
>> plugins (for example) that deal with collections APIs or repositories, so
>> you might get a critical mass of tools around Nick's first 'middleware'
>> option. The middleware option also seems slightly more future-proof and
>> realistic than a grand unified system that does everything, but then I'm
>> probably biased by the Unix philosophy of writing programs that do one
>> thing and do it well, or the more recent 'do the simplest thing possible'.
>>
>> Peigi - this thread started quite a while ago but if you missed the start
>> the archives are available via the JISCMail site - Nick's post here sums up
>> http://bit.ly/SVbjcm why you'd want to use a specialist Collections
>> Management System (as you are), tools like WordPress are just a way of
>> creating a user-friendly public-facing interface to them (to build on what
>> Mike said).
>>
>> Tehmina - Neatline is very cool but still very beta (though there's a new
>> version coming out soon). As it's based on Omeka, documentation/library
>> science experience really helps people get their heads around the
>> underlying record model. I've got an instance set up that I'd be happy to
>> send logins for if you (or anyone else) wants to try it out beyond the
>> sandboxes Omeka and Neatline provide. I've also written something on my
>> experiences teaching Neatline at
>> http://openobjects.blogspot.co.uk/2012/11/reflections-on-teaching-neatline.html
>>
>> 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/
****************************************************************
|