innovation in metadata design, implementation & best practices
Topic: MARC Relator terms as sub-properties of dc:contributor
Agenda frozen: 2004-10-02 07:25, Saturday
Maintainer: Tom Baker
See also: http://dublincore.org/usage/meetings/2004/10/ISSUES/
Note: If any of the links below are broken, please refer to
the meeting packet
for copies of the key documents discussed at the meeting.
In Bath , there was broad agreement that the full list
of relator codes extends beyond the the semantic scope of
"dc:contributor" per se. There was agreement that a refinement
of an element (sub-property) must be a sub-property of that
property in every case -- e.g., "abstract" must always be a
kind of "description". We agreed that the challenge is to
come up with final list of properties from the relator codes
which are "contributors" in every instance.
This topic raises several related issues:
-- Deciding which Relator terms are valid refinements.
-- Guidelines for using Agent Roles in Dublin Core -- a draft
prepared by Diane and Rebecca .
-- The mechanics of declaring machine-processably that the
selected Relator terms are subPropertyOf
-- The mechanics whereby DCMI would endorse, acknowledge, or
disseminate the Library of Congress assertions.
-- Articulating assumptions and expectations regarding the
declaration and maintenance of the assertions.
It was recognized that DCMI needs to better understand
the relationship between DCMI and LC in terms of namespace.
Does LC have a namespace policy with respect to MARC Relators,
and is that policy compatible with DCMI's own policy (e.g.,
with regard to the persistence and semantic stability of
There was general agreement that DCMI need not be interested
in the list as a whole; rather, more specifically it needed
to focus on the assertions made regarding the sub-property
relationship between specific MARC Relator terms and DCMI
terms. It was felt there was a need to understand how LC
adds terms to the namespace and by what process an assertion
could be made relating that LC term to a DCMI term.
It was pointed out that there is no intrinsic harm to
"interoperability" if some MARC Relator terms have no
relationship to dc:contributor -- it simply means that those
terms fall "outside the scope" of the DCMI core elements.
Original term Dumb-Down "Simple DC"
marcrel:degreeGrantor marcrel:degreeGrantor ---
marcrel:owner marcrel:owner ---
marcrel:illustrator dc:contributor dc:contributor
On 2004-09-29, Rebecca posted a revision
of the MARC relators list in RDF at:
1. Evaluated each term to see if it truly refined
dc:contributor all of the time. Took out the subproperty
assertion if it didn't.
2. Made the token (MARC code at the end of the URI)
upper case. I decided to keep the code rather than term
as part of the URI 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.
3. Added additional statements: "depicted" is subproperty
of dc:subject "distributor" is subproperty of dc:publisher
"publisher" is NOT a subproperty of contributor (because it
does not always contribute to the content of the resource)
At some point in the near future, before we make it
publicly available we need to settle on the issue of
what the persistent URI will be. We are probably going
to use info: URIs instead of http: URIs. This is part of
a larger effort that we need to coordinate with.
We are generating this on the fly from the master
relators list. As we add to that list we will need to
determine whether the new term is indeed a refinement of
dc:contributor. Default is that it isn't (since most of
these seem to have already been defined).
In Shanghai, we are going to review a version of the above
which is limited to the subset of the relators list that are
refinements of dc:contributor (included in the packet):
As you'll see we've formulated to look like other
dcterms. I've used today's date as date issued. I've
also included those roles that refine or are equivalent
to other DC elements.
So we can review this list to see if everyone agrees that
these roles are subproperties of dc:contributor and people
can also use the full list to see what I've left off.
In Shanghai, we also need to review the guidelines drawn up
by Diane and Rebecca on using the MARC Relator terms (also
included in the packet as:
I would say we would probably need an hour and a half
(at least) for this discussion. I will shortly send Tom
the guidelines, which will probably be another half hour
or so. So we'll say 2 hours for this topic all together.
On 2004-10-01, Pete posted a note (see ACTION 5 below) what
element refinement/subproperty means:
[I have] tried to draw out some thoughts about how to
decide when to assert a refinement relationship and when
It goes a bit beyond what DCMI actually does in practice
(e.g. I've discussed what it means if a property is the
subject of multiple refinement relations), but I think that
we do need to think about those cases if we are using terms
from other vocabularies in DC metadata descriptions, as it's
quite possible that the owners of those vocabularies declare
multiple refinement relations (and possibly to DCMI terms!),
even if DCMI itself has the approach of not doing so.
Appendix: List of old actions (to check)
ACTION 1 (Andy and Rebecca): To create one document with
definitions and sub-property assertions for the relator terms
and circulate it to the UB list.
ACTION 2 (everyone): Each UB member will read through the list
prepared by Andy and Rebecca and sign-off on the sub-property
ACTION 3 (everyone; Tom): 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 remains to be clarified.
ACTION 4 (Tom and Rebecca): To develop a document defining
the etiquette for the relationship between DCMI and LC with
regard to maintaining the assertions. This document should
describe any relevant policies on the part of LC (analogous
to the DCMI Namespace Policy).
ACTION 5 (Andy and Pete): To formulate a FAQ-size answer on
what constitutes a valid element refinement.
ACTION 6 (Andrew): There was also a decision in Bath --
the text of which was to be finalized by Andrew -- that
proposals for DCMI "role" terms (i.e., any property that
relates a resource to an agent) would be accepted only for
terms that met the requirements for "recommended" status.
For term proposals meeting the requirements for "conforming"
(and not those of "recommended") it would be recommended that
these either be submitted to LC for inclusion in the MARC
Relator terms or that an independent namespace be created.
Diane and Stuart were to review the process document for any
revisions caused by this decision.
ACTION 7 (Rebecca): Andy and Andrew prefer using terms rather
than numeric codes for the names (and hence URIs). LoC can
use owl:samePropertyAs to designate the code (or label, see
below). URIs of Relators should also use same upper/lowercase
conventions as DC terms; this will 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
ACTION 8 (Diane and Rebecca): To revise the "Guidelines for
using Agent Roles in Dublin Core" as per the discussion above
and prepare as an appendix to Usage Guide . The guidance
document will need to include process information and more
information on how the refinements will dumb down to simple
DC. It will also include some examples. Diane will revise
the current draft and send to Rebecca.