W3C home > Mailing lists > Public > public-lld@w3.org > August 2011

Re: Comments on LLD from ExLibris

From: Till Kinstler <kinstler@gbv.de>
Date: Fri, 05 Aug 2011 11:02:23 +0200
Message-ID: <4E3BB19F.3080700@gbv.de>
To: public-lld@w3.org
Am 04.08.2011 18:15, schrieb Karen Coyle:

> Carl Grant asked me to post the text of his blog post here, which I
> should have thought of. This way it's in our email record, and it may
> make discussion here more "fluid." Thanks, Carl.

Yes, thanks to Carl Grant for writing this blog post, because it really
gives some answers...
And it adds well to Lukas Koster's email from a few days back, where he
raised the question about the role of library software vendors in the
linked data world...

> The Library Linked Data Model ? from a librarian/vendor point of view
> by Carl Grant, Chief Librarian, Ex Libris Group


> I was at the ELAG 2011 conference in Prague in the Czech Republic
> recently and was sitting on a panel when an attendee asked the vendor
> organizations on the panel (a representative of OCLC and me):  What were
> our plans concerning Library Linked Data?

I think this refers to my question in that discussion at ELAG.
I think, I formulated the question a bit different, not directly
referring to linked data. I asked in a very open way, what vendor's
plans for future data models are in their new "cloudy" systems, when one
of the major topics at ELAG 2011 were the problems with current data
practices. We had a "MARC must die" workshop there, at the same time,
LoC published its statement on the transformation of "the bibliographic
framework", and at least every second contribution to ELAG 2011 was
about necessary change in current data library data practices. Overall
it is perhaps well (though a bit pathetically) summarized in this
statement by Anders Söderbäck:
http://www.flickr.com/photos/tillk/5775197941/ (in his presentation in
the same session on the future of library systems that Carl is referring
With my question, I wanted to see, if vendors are aware of the problems
we discussed at ELAG and if they somehow see some connection with linked
For me (and many others), it was disappointing, that the vendors didn't
really give an answer (beyond "we support XML and N different record
formats" and stressing the "openness" of the cloud data collections).
They didn't mention linked data or conceptual shifts from a record
centred to a graph (statement/link) oriented view, not even as something
to consider or by saying "that's just a hype". And we were talking about
library systems we will build our future on...
So thank you, Carl, again for this blog post. That gives good answers.
Something like that would have contributed to the discussion at ELAG 2011..

> It is a very important
> contribution to the development of new technology and helps to bring
> ideas to life.  However, at this stage, for a vendor, it doesn?t help to
> pay our staff or bills.

Yes, that's what I suspect. And that's a totally fine and legitimate
view for a vendor...
But then the question then is: Who drives innovation in libraryland?
Carl's blog post lists 4 good points, telling us, why vendors tend to be
careful in the library world.
And in the 4th point he mentions some common concerns about (open)
community processes as well.
So, but where does innovation come from, then?
Could it be a solution, that vendors become (better) part of the (open)
community processes?

> Conceptually, we?re on board with the ideas behind the Library Linked
> Data model and in fact, we?re designing our new system Alma with the
> necessary capabilities at the core to support the Library Linked Data
> model.

That's good to hear. Because we are going to build the future of our
library business on these systems in the foreseeable future...

Just my 2 Cents...

Again, thank you, Carl, for sharing this blog post,

Till Kinstler
Verbundzentrale des Gemeinsamen Bibliotheksverbundes (VZG)
Platz der Göttinger Sieben 1, D 37073 Göttingen
kinstler@gbv.de, +49 (0) 551 39-13431, http://www.gbv.de
Received on Saturday, 6 August 2011 06:51:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:19:03 UTC