> From [log in to unmask] Fri Oct 4 13:58 MET 2002
> Mime-Version: 1.0
> Content-Disposition: inline
> User-Agent: Mutt/1.4i
> X-MIME-Autoconverted: from 8bit to quoted-printable by ori.rl.ac.uk id
> Date: Fri, 4 Oct 2002 13:59:11 +0200
> From: Thomas Baker <[log in to unmask]>
> Subject: Re: MARC relator list
> To: [log in to unmask]
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by scarlett.mathematik.Uni-Osnabrueck.DE id NAA12526
> On Fri, Oct 04, 2002 at 11:41:58AM +0100, Rachel Heery wrote:
> > I think it would be useful to include in this proposal some reasoning as
> > to why the terms in the MARC relator list are being considered as element
> > refinements of contributor rather than as a scheme. In fact it might be
> > helpful to rehearse that argument on this list?
> Before doing so, I attach the proposed set of decisions that
> has been emerging from the discussion on the Usage Board list.
> Please bear in mind that this is just a draft proposal and
> that any decisions will need to be made at the UB meeting
> in Florence:
> Step 1. Declare dc:creator to be a refinement of dc:contributor.
> Step 2. Approve MARC Relator terms as refinements of dc:contributor.
> 2.1. The Library of Congress would need to assign and
> maintain a set of URIs for the Relator terms in an
> LoC namespace. It would need to document those URIs,
> together with other relevant information (labels and
> definitions), on the Web. The entire set of Relator
> terms to be approved would ideally be defined within
> just one namespace -- i.e., identified by one URI.
> 2.2. Usage Board approval would relate to an entire set
> of Relator terms (i.e., one namespace URI). Terms
> within that set would not be discussed or approved
> on an individual basis. The Usage Board would say,
> in effect: "terms from this list can be used as
> refinements for dc:contributor".
> 2.3. LoC would be the sole agency responsible for the
> maintenance of the Relator terms. DCMI Usage Board
> approval would extend to new terms as they are added
> by LoC on an ongoing basis. Ideally, the Library of
> Congress would maintain these terms in accordance
> with principles generally compatible with the DCMI
> Namespace Policy  with regard to permanence and
> semantic stability over time.
> 2.4. Since this declaration with regard to a non-DCMI
> namespace would set a precedent that presumably
> could apply to other such vocabularies, the Usage
> Board would need to clarify in general what status to
> assign to such a decision (Recommended, Conforming, or
> something else); decide how to declare and document
> such a decision in its Web pages; and articulate
> processes by which other such vocabularies might be
> considered in the future.
> 2.5. In cooperation with the maintainers of schemas
> expressing DCMI terms formally (e.g., in RDF),
> the Usage Board would need to understand how the
> Usage Board approval of a non-DCMI vocabulary would
> be modeled.
> 2.6. Possibly, declare the existing MARC Relator term
> "creator" to be equivalent to dc:creator.
> Step 3. Possibly, ask the DC-Architecture working group to develop
> recommendations for appropriate syntax for expressing these
> element refinements.
> Now to your questions and comments, taken in reverse order:
> >Are we in effect now allowing the DCMI terms list to 'grow' with
> >registering of domain specific refinements?
> Not if we follow the course of action above because
> no new DCMI terms would be added. Library of Congress
> would hold and maintain the terms in the context of a
> namespace URI we could cite (for the sake of argument,
> let's say it is http://www.loc.gov/standards/marcrelators/)
> and give each term its own URI on that basis (e.g.,
> for "Illustrator"). The Usage Board would
> simply say, in effect: "The terms defined in
> http://www.loc.gov/standards/marcrelators/ can be used as
> refinements of http://purl.org/dc/elements/1.1/contributor)".
> The only thing the DCMI Usage Board would need to maintain
> and document is the statement itself; Library of Congress
> alone would maintain the vocabulary and its URIs.
> >The sheer number and detail of the roles in the MARC relator
> >list indicate to me that they are not at the 'generic' level
> >which is the business of DCMI.
> > I am aware that the Library
> >world may want to use these terms (and in particular that the
> >Library Application Profile discussions have reached consensus
> >on the need for these terms in that context).... however it
> >might seem that such 'domain specific' usage might be dealt
> >with by registering a scheme??
> A long time ago, back in 1998, the Data Model group
> thought these roles could be used as values of a property
> -- named "Role" -- of an intermediate node representing a
> Creatør/Contributor . In which case, the value of that
> property could be contextualized by an Encoding Scheme saying
> that the values come from the MARC Relator list.
As a matter of fact the proposal of the data model group has been
smashed at the Frankfurt meeting and is incompatible with the
the definitions of subProperty and subClass.
The reason for it has been smashed in the retrospect were well
taken. It didn't scale to more elaborate ontologies.
Some marc relators imply dc:contributor - but it might happen, that
in a given case A --loc:ill--> B
A --dc:creator--> B both hold and in those
cases one has to use BOTH to indicate, what one wants to.
An alternative would be to create monsters like in the HTML-DOT-DOT-DOT
notation, which assumes a unique path of decendence or a technology
(DMAL+OIL ?) to declare certain path expressions as equivalent.
In my view this would create a substantial maintainance problem
when DC as organization wants to triple or dublicate other peoples
DC can declare relations on a per entry base - it's not possible and
unneccessary to do so on a "for all" basis.
> Handling Roles in the 1998 style, however, assumes that we have
> a data model for agents that includes this special property
> called Role. Whereas discussion since then, notably at the
> Usage Board meeting in Tokyo, has affirmed that role values are
> to be considered element refinements (see , paragraph 4).
> Handling Roles in the manner currently being proposed (above)
> allows us to re-use existing "schemes" for things such as the
> MARC Relator list without having to specify a more elaborate
> data model.
>  http://www.mailbase.ac.uk/lists/dc-datamodel/files/decisions.html
>  http://www.loc.gov/marc/dc/Agent-roles.html
> Dr. Thomas Baker [log in to unmask]
> Institutszentrum Schloss Birlinghoven mobile +49-171-408-5784
> Fraunhofer-Gesellschaft work +49-30-8109-9027
> 53754 Sankt Augustin, Germany fax +49-2241-144-1408