On Wednesday, August 22, 2018 7:21 PM, Bibliographic Framework Transition Initiative Forum On Behalf Of Karen Coyle wrote:

> The one thing that I always find missing in the discussion of linked
> data is: what linking will be done? There isn't much use in moving to
> linked data if our systems don't use it for linking.

This brings me to another important requirement that I usually take for granted but that probably needs to be explicit:

The system must expose dereferenceable URIs for all entities managed in the system. There must also be a way for the administrators to disable this for all or some kinds of entities (e. g. resources that must not be shared).

> Admittedly, some of
> the resources we might like to link to either aren't open or aren't yet
> linked data. I would think that one might want to link from courseware
> to the library. I would also think that the library might want to link
> to Wikipedia via Wikidata, and to Wikicite. I suppose there could be
> some interest in linking to geographic databases and other data sets.

I think so, too, but don't have use cases for it. I also don't think that all linking can/should be made from within the system but that there needs to be an import interface in place, possibly supporting Beacon or other link formats.

> I'm sure others have even better ideas. To me, this is the key to making
> a change, and making library catalogs more informative.



> On 8/22/18 1:55 AM, Svensson, Lars wrote:
> > Dear all,
> >
> > One of the outcomes of the 2017 European BIBFRAME Workshop [1] was a paper
> called “BIBFRAME Expectations for ILS tenders” containing suggestions for
> “requirements for Integrated Library Systems (ILS) vendors to fulfil Linked Data
> model, with particular focus on BIBFRAME conformance“. [2]. Over the past few
> weeks I have pondered this document a bit and wanted to share my reflections with
> the community.
> >
> > First of all: Tiziana and the Organiser Group for the 2018 European BIBFRAME
> Workshop have made a nice good job putting this together; I found the idea to use the
> Maturity Model particularly interesting. Thank you!
> >
> > That said, I do have some issues with the general direction this paper takes. The
> main one it that I find it too focused on technology and too little on functional
> requirements. The paper suggests a transition from a paradigm (1) where cataloguing
> is done directly in MARC records and where the Integrated Library Systems (ILSs) use
> a relational database (RDBMS) to store this and any associated data to another
> paradigm (2) where cataloguing is done in RDF (using the BIBFRAME data model) and
> ILSs use a triple store to store the necessary information. I’d say that the first
> assumption isn’t necessarily true (there are quite some ILSs where data is not stored
> using an RDBMS and at least some libraries where cataloguing is not done by creating
> or editing MARC records but using another metadata format that can be converted to
> MARC if so desired). And I’d also say that the suggestion for a new system paradigm is
> far too narrow and might even hinder innovation by mandating too strong
> requirements on which technology to use. There is, for instance, an emerging
> technology called graph databases that allow for interesting ways of analysing the data
> in the graph, including finding the shortest path between two nodes, finding “islands”
> (graphs or subtrees not connected to any other part of the graph) or loosely connected
> subtrees (e. g. subtrees that are connected by only one edge). If we mandate the use
> of a triple store, a vendor would not be able to use this technology and thus would lose
> the possibility to implement interesting statistical functions. In my opinion, a call for
> tender should be as technology neutral as possible (at least with regard to system
> internals).
> >
> > So what should a call for tender contain instead?
> >
> > My take is, that it should specify the desired functionality. After all, the interesting
> thing is what we want the system to do (or at least what we want to do with the
> system). A non-exhaustive list of things I can think of for a LinkedData-based system
> would be [3]:
> >
> > - The system must be able to import library data in the following formats:
> > -- MARC 21 (perhaps in different flavours)
> > -- RDF using the BIBFRAME data model
> > -- RDF using the RDA data model
> > -- …
> >
> > - The system must be able to export data in the following formats:
> > -- MARC 21 (perhaps specifying a flavour)
> > -- RDF using the BIBFRAME data model
> > -- DC-XML (for use with OAI-PMH)
> > -- …
> >
> > - The system must support the following machine import and export interfaces:
> > -- SRU/SRW
> > -- OAI-PMH (synchronising both ways)
> > -- Z39.50 ;-)
> > -- W3C WebSub (to ensure the system is “webby”)
> > -- …
> >
> > - The cataloguing module must allow cataloguers to:
> > -- Connect titles and authorities to other titles and authorities residing inside the local
> system (e. g. connecting a publication to its successor or to its author; connecting an
> author to her/his place of birth and the place of birth to the country it’s part of)
> > -- Connect titles and authorities to other titles and authorities residing in online
> databases (perhaps mandating a list of search interfaces the system must support)
> > -- …
> >
> > - The system must allow administrators to
> > -- Configure the data input forms, e. g. restricting which authority files the
> cataloguers can use
> > -- Import and export data input configurations and metadata profiles in a
> standardised format (possibly stating a list of such formats, e. g. SHACL, ShEx, JSON
> Schema, XML Schema)
> > -- Seamlessly include third party databases (IEEE Xplore, EconBiz, PubMed, …) into
> end user search
> >
> > - The system must allow end users to:
> > -- Search in both library internal content and third party databases using a single,
> united search interface
> > -- Export bibliographic citations into third party citation management systems
> > -- Subscribe to an RSS/Atom feed for new content matching a custom search
> > -- …
> >
> > To me, this approach would have the advantages that
> > 1) The customers need to think of what they really want the system to do
> > 2) The vendors can concentrate on implementing this functionality in a way they are
> comfortable instead of having to focus on new technology.
> >
> > What do you think?
> >
> > Best,
> >
> > Lars
> >
> > [1]
> > [2]
> _Tenders.pdf
> > [3] Some of those and much more can be found in the 2013 list of use cases and
> requirements:
> >
> >
> > *** Lesen. Hören. Wissen. Deutsche Nationalbibliothek ***
> >
> --
> Karen Coyle
> [log in to unmask]
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600