Re: Discussion of id.loc.gov

So I say the concept representing "Italy--History--1492-1559--Fiction" 
needs to have a relationship defined to the "concept" from the NAF 
representing "Italy". 

The problem with this is right now there's no semantic web URI for the 
NAF.  So, there needs to be.

Is there any guidance as to what terms from the "name headings" can be 
used to construct LCSH subjects?

It's still odd to me that "Italy" winds up in the name file.  I guess 
it's a "corporate author"?  But I don't think there are any works 
written by "Italy".  Weird.  I guess geographic headings just wind up in 
the "name" file instead of the "subject" file as a matter of convention?

I guess the relationship from "Italy--History--1492-1559--Fiction" to 
"Italy" could/should be recorded in such a way that it says that the 
relationship represents the FIRST component of the complete heading. 
There's probably not a way to do that in SKOS. So something non-SKOS 
needs to be used, or invented. 

Jonathan


Karen Coyle wrote:
> OK, I did a blog post at:
> http://kcoyle.blogspot.com/2009/05/lcsh-as-linked-data-beyond-dash-dash.html
>
> Here's a cut and paste:
>
> The SKOS version of LCSH <http://id.loc.gov/authorities/> developed by 
> LC has made some choices in how LCSH would be presented in a linked-data 
> format. One of these choices is that the complex headings (which is the 
> vast majority of them) are treated as a single string:
>
>     Italy--History--1492-1559--Fiction
>
>
> While this might fit appropriately as a SKOS vocabulary, in my opinion 
> it does not work as linked data. I'm going to try to explain why, 
> although it's quite complex. Part of that complexity is that LCSH is 
> itself complex, primarly because there are many exceptions to any 
> pattern that you might care to describe. (For more on this, I suggest 
> Lois Mai Chan's Library of Congress Subject Headings, 4th edition, the 
> chapter on geographic subject headings, pp. 67-89)
>
> Taking the heading above, as I mentioned in my previous post, the 
> geographic term Italy is not in LCSH even though it can indeed be used 
> as a subject heading. Instead, Italy is defined as a name heading in the 
> LC name authorities file. In that file, and only in the name file, 
> alternate forms of the name are included (altLabels, in SKOS terminology):
>
>     451 __ |a Repubblica italiana (1946- )
>     451 __ |a Italian Republic (1946- )
>     451 __ |a Wlochy
>     451 __ |a Regno d’Italia (1861-1946)
>     451 __ |a It?alyah
>     451 __ |a Italia
>     451 __ |a Italie
>     451 __ |a Italien
>     451 __ |a Italii?a?
>     451 __ |a Kgl. Italienische Regierung
>     451 __ |a Ko¨nigliche Italienische Regierung
>
>
> There are no altLabels in the LCSH entry for Italy--etc. And because the 
> term Italy is buried in an undifferentiated string, there is no linked 
> data way to say that the Italy in Italy--History--1492-1559--Fiction is 
> the same as http://id.loc.gov/authorities/n79021783, which will 
> presumably be the URI for the name.
>
> It is assumed in LC authorities that the altLabels for a name term that 
> appears in a subject heading apply to both the name used as a name and 
> the name used as a subject heading. In the card catalog, where the name 
> alone would appear first in the alphabetical browse of the cards, it was 
> only necessary to make references to that "head" of the list, which 
> would, in our case, be Italy alone. This has caused great problems in 
> online catalogs where searching is by keyword, not a linear alphabetical 
> search. Some systems manage to get around this by doing a string compare 
> to the same subfields in name headings and subject headings, and then 
> transferring the altLabel forms to the related subject headings.
>
>     $a Shakespeare, William, $d 1564-1616
>     $a Shakespeare, William, $d 1564-1616 $v Adaptations $v Periodicals
>
> In this case, the $a and $d subfields represent the same authoritative 
> entity. The rules say that they are, and must be, the same authoritative 
> entity. If they don't match exactly then someone has done something 
> wrong. They are both instances of a name identified as "n 78095332", and 
> which will presumably be given the URI 
> http://id.loc.gov/authorities/n78095332. There is no question about that.
>
> There is also no question that when the name is used in a subject 
> heading it has the full meaning that it is given in the name heading 
> record, including alternate forms of the name and the many notes fields 
> provided by the catalogers that created the authority record. That this 
> don't appear in the LCSH file does not mean that it is not the case: it 
> means only that the LCSH record assumes that the name record exists and 
> provides that information, and that the information is applied to the 
> name in the subject entry through the linear nature of the dictionary 
> catalog.
>
> We musn't confuse the form with the meaning. That LCSH has a rather 
> arrested form is unfortunate, but it was never intended to be used 
> outside of the context of the full set of authorities that gives full 
> treatment to those things that have "proper names." (c.f. Chan, chapter 4)
>
> If we wish for the LC authorities to be used in a linked data 
> environment, then we have to make sure that the linking capabilities are 
> there. Although I agree that each LCSH record has an identifier, and 
> that identifier should be used, I don't agree that what is expressed in 
> the LCSH record is a dumb, undifferentiated string. In this post I have 
> addressed the relation to name headings, but there are other uses of 
> controlled vocabularies within the subject headings that I haven't fully 
> investigated yet.
>
>
>