 |
 |
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: http://www.iskouk.org/conf2011/papers/spero.pdf Simon 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 ( > > 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<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<http://bibframe/auth/topic/bibliography> >>> "> >>> >>> <label>Bibliography</label> >>> <generalSubdivision>**Methodology</**generalSubdivision> >>> >>> <hasIDLink resource=”http://id.loc.gov/**authorities/subjects/** >>> sh85013838 <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<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 <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 <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 >> > >