17 September

Lightning talks

Closing day 1

18 September

Panel 1: Concerning Identities

We talk about a new environment in which we can expand our resources for managing identities, specially names authorities. What are the sources we would like to use? Wikidata? ISNI? NACO?

How could it work when, for example, we point to a VIAF resource, which contains 20 labels? Does an institution still have a local authority file? Would that mean that institution should host a mini-Linked Data website similar to ID.LOC.GOV or DATA.DNB.DE?

Do authority descriptions still need to follow specific rules for the construction of the authorized access point? How are the rules enforced if authorities reside outside a local system? Are service centers needed to maintain the descriptions and URIs needed for the descriptions? Would any services be free or not? Do all descriptions reside in a “local” file or do some stay at another site with links?

While machines operate on identifiers, humans require labels: How does label caching fit into the picture? Are there services that collect different files that are used instead of storing everything locally? This session is not for discussion of RWO (Real World Object) vs. identifiers vs. labels for names. The real issue is working in a communal environment.

• Identies are elusive. "Authorities" are organizational points of view, linked together in a mesh of agreements. (Prefer borrowing over defining.) / Niklas Lindström

Panel 2: Concerning Changes

In the current environment, we have different ways to supply and apply changes to a description of a resource. How could that translate to an RDF/triplestore environment? Do we need to signal that we have made a change to a description that is used by others? If so, what strategies exist or might we consider to communicate changes to downstream consumers?

Do we need to show provenance for triples in our local or shared systems? Could recording who made a change become challenging for the triple/statement? Are there changes that are tracked locally and other changes that are shared?

What types of changes require notification, such as changes to labels, or the addition/removal of subjects, or simply whenever the resource changes? Will local systems and local practices need to be modified?

• Named graphs as Documents, tracking sources and derivations. (Future work on WebSub and notifications.) / Niklas Lindström

Panel 3: Concerning Infrastructure

To support RDF/Linked data we need infrastructures that supply descriptions and URIs. For example, the Library of Congress has built http://id.loc.gov into a source of data to assist with the addition of URIs in our BIBFRAME database, and to support lookups and other aides for description creation. While LC has made ID accessible to others, we expect any institution or network will need its own version of such tools to support both description creation and retrieval. How are others handling this infrastructure need?

• Just JSON inside, governed by RDF rules and Linked Data interfaces. Map and cache. / Niklas Lindström

Panel 4: Concerning Relationships

Relationships are the cornerstone of the new environment. Within an institution or network, how are they handled? How are relationships between resources inside and outside the institution treated? Do other institutions see the need for over-arching gathering devices like Hubs (Library of Congress) or Superworks (Casalini)? What are the key components of this linking?

What are the challenges of converting legacy data from MARC to BIBFRAME and (potentially) back to MARC?

Panel 5: Concerning Editors

Editors for creating and modifying Bibframe descriptions are a major development needed for movement to a BIBFRAME environment. What additional features in this new environment will assist catalogers with their ability to efficiently, yet richly, describe library resources?

Must we edit RDF-resource-by-RDF-resource, which may be inefficient for catalogers, or can we edit by RDF graph, which is technologically more challenging? If by graph, what are the challenges of scoping the graph we load into an editor and how we save it back, i.e. deleting/replacing the edited graph?

What is the best use of profiles? What do you do with descriptive elements (triples) belonging to a graph that do not match your edit profile? What are the complications of editing a description that started as MARC and therefore has no explicit profile?

• Deciding what to edit / Jodi Williaschen

Closing Session