Topic: MARC Relator terms Identifier: http://dublincore.org/usage/meetings/2005/05/washdc/topic-relators/ See also: http://dublincore.org/usage/meetings/2005/05/washdc/ Created: 2005-05-13 Modified: 2005-05-16 17:28, Monday Maintainer: Tom Baker Agent Roles Guidelines - UB members please review! http://dublincore.org/usage/meetings/2005/05/washdc/public/2005-05-14.Agent-Roles-Guidelines7.txt Changes to definitions - UB members please review! http://dublincore.org/usage/meetings/2005/05/washdc/public/2004-10-21.relators-review.txt -- some definitions to be changed based on suggestions from Diane ACTION: These changes would be made by LoC, so it is a decision for LoC, but at the Washington meeting we could review these changes and make a recommendation. LoC identifier policy Library of Congress is currently deciding how to handle identifiers generally, after which the URIs in the RDF expression will be changed. INFO URIs are being considered. The URIs may use the MARC code instead of the term (label) because 1) it could be more persistent than the term; 2) the terms are sometimes rather long winded (e.g. "Author in quotations or text extracts"); 3) the codes ARE tokens for the terms. (There was some UB discussion in the past about advantages and disadvantages of using terms rather than numeric codes for the names, and hence URIs. A suggestion was made that LoC use owl:samePropertyAs to designate the code or label. It was also suggested that URIs of Relators use the same upper/lowercase conventions as DC terms. This would not affect how the codes are depicted in LoC's database -- they can use "cre" as a label or have two labels -- one a numeric code and one a human-language-like string.) RDF expression of MARC relator terms The RDF expression is generated automatically from a the database used to maintain the MARC Relator list. The full list (and its RDF expression) are quite long and are therefore not included in this packet. http: //lcweb2.loc.gov/cocoon/relators/relators.xml Maintenance relation between DCMI and Library of Congress Library of Congress generates the RDF from the official documentation (in HTML) at: http: //www.loc.gov/marc/relators. They make changes regularly. The procedure will be when something is added, they will determine whether it might be a refinement of contributor. By default, the new term will not be a refinement (since most of these seem to have already been defined). If Rebecca thinks it is or might be, she will send it as a proposal to the UB list. If the UB determines it is, then the statement <rdfs:subPropertyOf rdf:resource="http: //purl.org/dc/elements/1.1/contributor"/> will be included. There is a question as to whether each addition to this list would need to be announced to DC-GENERAL. ACTION: A Web document describing the process outlined above is needed. This document could reside on either the LoC or DCMI Web site and be pointed to from the other. This document could summarize any relevant policies (e.g., identifier persistence) on the part of both organizations. LoC Documentation of MARC Relators which refine dc:contributor LC is also generating a page that takes out the subset that refines dc:contributor: http: //lcweb2.loc.gov/cocoon/relators/dccontributor.html Rebecca: I'm thinking that it would be nice to also have an HTML display (which is easy to do) that also gives an eye readable display of both those that refine contributor and those that don't, i.e. the whole list. Here is my proposal for a sample entry (note that the URI is still under discussion): Term Name: applicant URI: http: //www.loc.gov/marc.relators/APP Label: Applicant Definition: A person or organization responsible for the submission of an application or who is named as eligible for the results of the processing of the application (e.g., bestowing of rights, reward, title, position). Comment: Typically, the name of the Applicant should be used to indicate the agent. Status: endorsed Date Issued: 2004-09-30 So, I've left out the statement that it refines dc:contributor and its status is "endorsed" rather than "recommended". We had said at the UB meeting in Shanghai that there will be this new status of "endorsed". DCMI endorsement of LoC subProperty assertions DCMI will need to make some form of endorsement of the sub-property assertions. For example, the UB should assert that the Relator terms conform to the DCMI model and that it agrees with the specific assertions. Exactly where and how these assertions/endorsements should be made (e.g., by what sort of RDF assertions) remains to be clarified. ACTION: On 2005-02-25, the UB agreed that we could finalize an announcement of the LoC sub-property assertions without having an RDF mechanism in place -- i.e., DCMI could simply endorse the assertions verbally until an RDF mechanism for doing the same is worked out. ACTION: Liaise with Semantic Web community about RDF expression of endorsement.