RDA-L “founded corporate body” now three wordy RDs

Posting to RDA-L

On 08/09/2016 00:56, Adam L. Schiff wrote:

Has anyone yet noticed this change to Appendix K from the August release of the RDA Toolkit:

“founded corporate body” has now been split up into three designators with truly unfortunate phrases:
founded corporate body of person An organization that the person founded.
founded corporate body of family An organization that the family founded.
founded corporate body of corporate body A corporate body that the other corporate body founded.

Besides the unwieldiness of these phrases, and the difficulty that catalogers will have interpreting them, I’m wondering if PCC will make any effort to replace all of the existing 5XXs that have the old RD with the appropriate new one?

I wonder also about the practical utility of all of this. First, I wonder how many users would find this sort of additional information and coding generally useful and whether catalogers should spend their time on this rather than other tasks that may be more urgent. But second, and more important when considering linked data, it seems to me that this means catalogers doing a massive amount of duplicated labor. For instance, take the example found in the PCC guidelines, for the architectural firm, Skidmore, Owings & Merrill (https://lccn.loc.gov/n50012009):

110 2_ Skidmore, Owings & Merrill
368 Architectural firms $2 lcsh
370 $e Chicago (Ill.) $f New York (N.Y.) $c United States $2 naf
410 2_ S.O.M.
410 2_ Skidmore, Owings, and Merrill
410 2_ SOM
500 1_ $i Founder: $a Skidmore, Louis, $d 1897-1962 $w r
500 1_ $i Founder: $a Owings, Nathaniel Alexander, $d 1903-1984 $w r
500 1_ $i Founder: $a Merrill, John O., $d 1896-1975 $w r
510 2_ Crosstown Associates
667 Unable to determine relationship with Crosstown Associates, n 87113575.

Now, let’s compare this to the information in dbpedia and wikidata. [I am just giving the URIs because there is too much information]
Dbpedia: http://dbpedia.org/page/Skidmore,_Owings_%26_Merrill
Wikidata: https://www.wikidata.org/wiki/Q459464

All of the information in the authority record is already in the dbpedia and wikidata records. I confess that I do not fully understand the relationship between dbpedia and Wikidata. I had thought that Wikidata was supposed to replace dbpedia but that doesn’t seem to be the case here because each appears to have information the other doesn’t have. Setting that concern aside, there is *a lot* more information about this company than in our authority record and in particular, the information about the founders is already encoded in dbpedia. Here it is in JSON-LD:

“http://dbpedia.org/property/founder” : [ { “type” : “uri”,
“value” : “http://dbpedia.org/resource/John_O._Merrill” } ,
{ “type” : “uri”, “value” :
“http://dbpedia.org/resource/Louis_Skidmore” } ,
{ “type” : “uri”, “value” :
“http://dbpedia.org/resource/Nathaniel_A._Owings” } ] ,

If the entire library universe is aiming for linked data, then why are we duplicating information that already exists elsewhere? All that is required are to add the links plus some rather prosaic programming, and all that work from dbpedia/wikidata will be available immediately within our catalogs. For instance, if a library decided that it was important for their users to have “Key people”–something that exists in dbpedia (I guess the current CEOs or something)–catalogers would not have to do anything at all. It would require only a programmer to add a few lines of code.

“http://dbpedia.org/property/keyPeople” : [ { “type” : “uri”,
“value” : “http://dbpedia.org/resource/Fazlur_Rahman_Khan” } ,
{ “type” : “uri”, “value” :
“http://dbpedia.org/resource/John_O._Merrill” } ] ,

That’s the primary reason for the linked data idea, after all: you can use information that others have input, and if you are nice, you will allow others to use your data. You don’t have to let others use your data, but you can if you want. Linked data is not about re-entering everything into your own databases.

To emphasize, this is discussing the ideal of linked data, and there are many problems with that ideal when it comes to the real world and practical implementation. I’ll skip those, but in the present case, it seems to be duplicated effort.