Quoting Weinheimer Jim <j.weinheimer_at_AUR.EDU>:
>
> The suggestions I have seen, and the project of subject headings at
> http://id.loc.gov/ does the same, is that this heading must be
> turned into a URI to be useful. I disagree since I don't think that
> even if this headings were turned into a URI, it would be very
> useful at all. What would be extemely useful however, is to link
> what can be linked, and there is an awful lot here: separate links
> to Shakespeare's authority record (an extremely rich source); to the
> Name/title record of the Sonnets; to the different German/English
> versions, and to different Selections. As a result, this single
> heading is extremely rich in linked data. So, this text-based string
> should be dismantled and linked wherever possible, and it is very
> possible here.
This is something I brought up on the id-loc list when LCSH was first
issued, and there was a discussion there although no real resolution.
[1] There are two problems:
The first is in the concept of "heading", which is not a single thing
but a complex of different things that are put together, serially, to
form a string. This itself needs to be questioned because it is based
on the linear filing in physical catalogs. If we have a work in a
language other than the original, there are better ways to express
that than the creation of a string for "Original title. Language."
Trying to model these strings in the linked data world is difficult,
in part because the other players in the linked data world do not have
these kinds of data structures. It *may* make sense to have an
identifier for each translation of a work, but doing that through the
headings that we create is not the way to go.
The second is that the LCSH at id.loc.gov loses the difference between
subject heading types (topical-150, geographic-151, etc.), and loses
the meaning of the subheadings when it flattens the multi-part
headings into their display form (topic--geographic qualifier). The
first part is easier to solve than the second. LC needs to create its
own properties that will keep the types intact, rather than trying to
fit LCSH into standard SKOS. The second part is more difficult, again
because it means creating a complex structure to store the heading
(once again the "heading question"). Jon Phipps put out a couple of
suggestions on how that could be done, for example:
<http://id.loc.gov/authorities/sh2008115565#concept>
loc_id:geographicName http://id.loc.gov/authorities/n79021783
loc_id:type http://id.loc.gov/authorities/sh2002011429
loc_id:topicalDivision http://id.loc.gov/authorities/sh85061212
loc_id:formSubdivision http://id.loc.gov/authorities/sh85048050
dcterms:temporal "1492-1559"
dcterms:spatial http://sws.geonames.org/3175395/
dcterms:spatial http://id.loc.gov/authorities/n79021783
In fact, what this calls for is something "FAST-ian" as a base, and a
way to combine the parts into a more complex unit. Both parts and
combinations of parts could have identifiers. If we want our data to
go out *there* (for however you wish to define "there") then we have
to think about what it is we are trying to do with headings, and how
we would do that same thing in a non-linear data environment.
kc
[1] http://listserv.loc.gov/cgi-bin/wa?A1=ind0905&L=id See the
discussion called "dashes"
--
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Received on Wed Nov 11 2009 - 09:39:16 EST