{"id":20,"date":"2009-05-20T15:45:55","date_gmt":"2009-05-20T20:45:55","guid":{"rendered":"http:\/\/managemetadata.org\/blog\/2009\/05\/20\/lcsh-skos-and-pre-coordinated-headings\/"},"modified":"2009-05-20T15:45:55","modified_gmt":"2009-05-20T20:45:55","slug":"lcsh-skos-and-pre-coordinated-headings","status":"publish","type":"post","link":"https:\/\/managemetadata.com\/blog\/2009\/05\/20\/lcsh-skos-and-pre-coordinated-headings\/","title":{"rendered":"LCSH, SKOS and pre-coordinated headings"},"content":{"rendered":"

This week, Karen Coyle<\/a> wrote a post about LCSH as linked data: beyond “dash-dash”<\/a> which provoked a discussion on the id.loc.gov discussion list<\/a><\/a>.<\/p>\n

It seems to me that there are several memes at play in this conversation:<\/p>\n

LCSH and SKOS<\/strong><\/h3>\n

As Karen points out, LCSH is more than just a simple thesaurus. It’s also a set of instructions for building structured strings in a way that’s highly meaningful for ordering physical cards in a physical catalog. In addition, each string component has specific semantics related to its position in the string, so it’s possible, if everyone knows and agrees on the rules, to parse the string and derive the semantics of each individual component. The result is a pre-coordinated index string<\/a>. <\/p>\n

These stand-alone pre-coordinated strings are perhaps much less meaningful in the context of LOD<\/a>, but this certainly doesn’t apply to the components. I think what Karen is pointing out is that, while it’s wonderful to have a subset of all of the components that can be used to construct LC Subject Headings published as LOD, there’s enough missing information to reduce the overall value. As I read it, she’s wishing for the missing semantics to be published as part of the LCSH linked data, and hoping that LC doesn’t rest on its well-earned laurels and call it a day.<\/p>\n

Structured Strings<\/strong> <\/h3>\n

Dublin Core<\/a> calls the rules that define a structured string a "Syntax Encoding Scheme" (SES<\/a>) and basically, that’s what the rules defining the construction of LC Subject Headings seem to be. It’s structurally no different than saying that the string "05\/10\/09", if interpreted as a date using an encoding scheme\/mask of "mm\/dd\/yy", ‘means’ day 10 in the month May in the year 2009 using the Gregorian calendar. Fascinatingly<\/a>, that same ‘date’ can be expressed as a Julian date of "2454962", but I digress.<\/p>\n

As far as I can tell, no one has figured out a universally accepted (or any) way to define the semantic structure of a SES in a way that can be used by common semantic inference engines, and I don’t think that anyone in this discussion is asking for that. What’s needed is a way to say "Here’s a pre-coordinated string expressed as a skos:prefLabel, it has an identity, and here are it’s semantic components."<\/p>\n

Additional data<\/strong><\/h3>\n

So…<\/p>\n

"Italy--History--1492-1559--Fiction"<\/pre>\n
…is expressed in http:\/\/id.loc.gov\/authorities\/sh2008115565#concept as…<\/p>\n
@prefix rdf: <http:\/\/www.w3.org\/1999\/02\/22-rdf-syntax-ns#> .\r\n@prefix skos: <http:\/\/www.w3.org\/2004\/02\/skos\/core#> .  \r\n@prefix terms: <http:\/\/purl.org\/dc\/terms\/> .  \r\n@prefix owl: <http:\/\/www.w3.org\/2002\/07\/owl#> .\r\n\r\n<http:\/\/id.loc.gov\/authorities\/sh2008115565#concept>\r\n    skos:prefLabel "Italy--History--1492-1559--Fiction"@en ; \r\n    rdf:type ns0:Concept ;    \r\n    terms:modified "2008-03-15T08:10:27-04:00"^^<http:\/\/www.w3.org\/2001\/XMLSchema#dateTime> ; \r\n    terms:created "2008-03-14T00:00:00-04:00"^^<http:\/\/www.w3.org\/2001\/XMLSchema#dateTime> ; \r\n    owl:sameAs <info:lc\/authorities\/sh2008115565> ; \r\n    skos:inScheme\r\n        <http:\/\/id.loc.gov\/authorities#geographicNames> , \r\n        <http:\/\/id.loc.gov\/authorities#conceptScheme> ; \r\n    terms:source "Work cat.: The family, 2001"@en . <\/pre>\n
…and has a 151 field expressed in the authority<\/a> file as…<\/p>\n
151 __* |a *Italy* |x *History* |y *1492-1559* |v *Fiction<\/pre>\n
…which has the additional minimal semantics of…<\/p>\n
<http:\/\/id.loc.gov\/authorities\/sh2008115565#concept>\r\n    loc_id:type "Geographic Name" ; #note that this is also expressed as a skos:inScheme property\r\n    loc_id:topicalDivision "History" ;\r\n    loc_id:chronologicalSubdivision "1492-1559" ;\r\n    loc_id:formSubdivision "Fiction" ;\r\n    loc_id:geographicName "Italy" .<\/pre>\n
…and this might also be expressed as…<\/p>\n
<http:\/\/id.loc.gov\/authorities\/sh2008115565#concept>\r\n   loc_id:type http:\/\/id.loc.gov\/authorities\/sh2002011429 ;\r\n   loc_id:topicalDivision http:\/\/id.loc.gov\/authorities\/sh85061212 ;\r\n   loc_id:formSubdivision http:\/\/id.loc.gov\/authorities\/sh85048050 ;\r\n   loc_id:geographicName http:\/\/id.loc.gov\/authorities\/n79021783 ;\r\n   dc:temporal "1492-1559" ;\r\n   dc:spatial http:\/\/sws.geonames.org\/3175395\/ ;\r\n   dc:spatial http:\/\/id.loc.gov\/authorities\/n79021783 .<\/pre>\n
Making sure that those strings in the first example are expressed as resource identifiers is also something that I think Karen is asking for. (BTW, The ability to lookup a label by URL at id.loc.gov is really useful)<\/p>\n
I should point out that Ed, Antoine, Clay, and Dan’s DC2008 paper<\/a> detailing the conversion of LCSH to SKOS goes into some detail (see section 2.7) about the LCSH to SKOS mapping, but doesn’t directly address the issue that Karen is raising about mapping the explicit semantics of the subfields.<\/p>\n","protected":false},"excerpt":{"rendered":"
This week, Karen Coyle wrote a post about LCSH as linked data: beyond “dash-dash” which provoked a discussion on the id.loc.gov discussion list. It seems to me that there are several memes at play in this conversation: LCSH and SKOS As Karen points out, LCSH is more than just a simple thesaurus. It’s also a […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-20","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/posts\/20","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/comments?post=20"}],"version-history":[{"count":0,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/posts\/20\/revisions"}],"wp:attachment":[{"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/media?parent=20"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/categories?post=20"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/tags?post=20"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}