Print

Print
Karen:

I think you've hit an important point here: we need to consider the place of library authority data in a much larger context before we make large investments in time and energy 'repurposing' what we already have. The example you show of name authorities in a wikipedia world is a particularly nice example, since the Wikipedia entry contains (way at the bottom) a link to VIAF. 

Remembering that authority files were never intended to provide user-friendly information but instead disambiguate the names authors used in their work (or corporate bodies used over their lifetimes) for the purpose of determining uniqueness suggests that those two resources providing information about the same person actually have two different roles. Over the last few years there have been intermittent calls for libraries to start adding the sorts of information that Wikipedia offers, but so far the sheer cost of doing that has deterred most of those efforts, thankfully. Libraries aren't in a position to compete with Wikipedia in those arenas, and vice versa (which Wikipedia seems to have figured out, but we haven't yet).

But the LCSH issues are quite different. Harking back to the issue Owen brought up (asking his important question about whether text strings should be included, a la MODS), and asking a few more:

Is LC still intending to provide URIs for complete strings as well as the components? How does that work in a LOD environment? There are a lot of unanswered (and largely undiscussed, afaik) questions about whether pre-coordination is a viable strategy going forward, and just figuring out how to encode them in XML doesn't help much, because, as Jon Phipps points out in his post a few years ago (
http://managemetadata.com/blog/2009/05/20/lcsh-skos-and-pre-coordinated-headings/), the machine usable 'rules' for combining them (and validating them) seem to be an important 'missing' part.

It's my understanding that http://id.loc.org does not include a large swath of the precoordinated strings, certainly not those derived from pattern headings, but also others (for reasons I'm not clear about). What are the implications of that, and is it possible to get some information up on the site about what's missing, and why?

I'd sure like to see some discussion about that sort of thing on this list ...

Diane


On Tue, Nov 27, 2012 at 11:46 AM, Karen Coyle <[log in to unmask]> wrote:
On 11/27/12 8:12 AM, Owen Stephens wrote:
I might be jumping the gun with some of these questions but just becuase I'm interested ...

 From the Bibliographic Framework as a Web of Data p.11
"Authorities are not designed to compete or replace existing authority efforts but rather provide a common, light weight abstraction layer over various different Web based authority efforts to make them even more effective."

 From this it seems clear that it is intended that authorities can make use of existing linked data representations of LC authorities via http://id.loc.gov.

Wow, Owen. I'm impressed that you made sense of that sentence because it was one of the ones that just said NOTHING AT ALL to me. What is a "light weight abstraction layer" anyway? Now that you've put out a concrete example I can see it as something like VIAF that can bring together authority identifiers (including ones like DBPedia) from various sources. Yes? No?

However, and partially in response to John Myers' post, there is a difference between library authorities, which is a mechanism to control name forms (as identifiers), and full-blown entities that represent all information about the entity. I was hoping/assuming that our future model would be, as John says, a set of interacting entities, and that would mean greatly expanding beyond the minimalist authority data we have to something much fuller. To give an example, compare this authority record for T.C. Boyle:

http://tinyurl.com/c4gqtrb

with his Wikipedia entry:

http://en.wikipedia.org/wiki/T._C._Boyle

The latter is actually a small Wikipedia page compared to many others, but it still provides much more information that may be useful to readers than what the authority record provides. The authority record was always intended to be a "back room" entity. I'm hoping that what replaces it has more information that is helpful to information seekers. "Lightweight abstraction layer" doesn't read like that to me.

kc

The example Bibframe serialisation supports this:
  <!-- BIBFRAME Topic -->
<Topic id="http://bibframe/auth/topic/bibliography">

   <label>Bibliography</label>
   <generalSubdivision>Methodology</generalSubdivision>

   <hasIDLink resource=”http://id.loc.gov/authorities/subjects/sh85013838” />

</Topic>

I did some work previously on linking to LCSH - see page 7 onwards of this presentation http://www.slideshare.net/ostephens/linking-lcsh-and-other-stuff, and based on this experience this example prompts me to ask:

Is it expected that the Topic will include textual strings representing the subject as here?
The example here suggests that there is some structure (LCSH based) within the Topic - is that the case? How would ordering be dealt with?
Since id.loc.gov only issues URIs for Authorised headings, how would valid but unauthorised headings be represented (this was the focus of my presentation)

Representing the topic as madsrdf could solve these problems?

Finally - just to pedantically note that http://id.loc.gov/authorities/subjects/sh85013838 is the URI for the LCSH Topical Term Bibiliography. The correct URI for Bibliography--Methodology is http://id.loc.gov/authorities/subjects/sh85013859

Owen

Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: [log in to unmask]
Telephone: 0121 288 6936

--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet