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 (,
the machine usable 'rules' for combining them (and validating them) seem to
be an important 'missing' part.

It's my understanding that 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


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
> 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:
> with his Wikipedia entry:
> 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<http://bibframe/auth/topic/bibliography>
>> ">
>>    <label>Bibliography</label>
>>    <generalSubdivision>**Methodology</**generalSubdivision>
>>    <hasIDLink resource=”**authorities/subjects/**
>> sh85013838 <>” />
>> </Topic>
>> I did some work previously on linking to LCSH - see page 7 onwards of
>> this presentation**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 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**
>> subjects/sh85013838 <>is the URI for the LCSH Topical Term Bibiliography. The correct URI for
>> Bibliography--Methodology is**
>> subjects/sh85013859 <>
>> Owen
>> Owen Stephens
>> Owen Stephens Consulting
>> Web:
>> Email: [log in to unmask]
>> Telephone: 0121 288 6936
> --
> Karen Coyle
> [log in to unmask]
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet