See also: Spero,

S. E. (2012, March). What, if anything, is a subdivision?. In *Facets of
Knowledge Organization: Proceedings of the ISKO UK Second Biennial
Conference, 4th 5th July, 2011, London* (p. 69). Emerald Group Publishing.
Available at:


On Tue, Nov 27, 2012 at 12:35 PM, Diane Hillmann
<[log in to unmask]>wrote:

> 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 (
> 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
> ...
> 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
>> 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