innovation in metadata design, implementation & best practices
Topic: MARC Relator terms
See also: http://dublincore.org/usage/meetings/2005/05/washdc/
Modified: 2005-05-16 17:28, Monday
Maintainer: Tom Baker
Agent Roles Guidelines - UB members please review!
Changes to definitions - UB members please review!
-- 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.
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:
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
Term Name: applicant
URI: http: //www.loc.gov/marc.relators/APP
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,
Comment: Typically, the name of the Applicant should be used
to indicate the agent.
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.