DC-Citation meeting, Bath, 15-Mar-2001

DC-Citation Meeting, University of Bath, 15 March 2001

Chair: Ann Apps (MIMAS)

Attendees: Karen Coyle (University of California Digital Library) Michael Day, Rachel Heery, Andy Powell (UKOLN).

The meeting decided that it would:

Agree on a statement of the problem that we are trying to solve.
To recommend some encoding mechanisms.
To recommend a way to take this forward with the DCMI.

1. The problem that we are trying to solve

After discussion of the scope of the original DC Citation Working Group [1] and the statements in section 7 of the Powell/Apps paper on OpenURLs [2], the meeting agreed the following scope statements:

To agree on mechanisms for providing a DC-based set of metadata elements or attributes for recording journal articles, and this must include the journal full title, journal abbreviated title, volume, issue and part. All of these to be optional and repeatable.
To recommend encoding mechanisms for this set of elements

The Discussion then moved to agree the set of metadata elements might be required. It was agreed that the purpose of the elements would primarily be to support resource discovery. They may also help support discovering its location, but this would not be an express requirement. Elements were initially identified without regard to how they would need to be encoded. Elements were identified at three distinct levels: the Journal level, the journal Issue level and the individual Article level.

The elements that were identified are outlined briefly in the following table. The starred elements are those elements that are not included within the existing DC element set and are therefore within the scope of the meeting's recommendations.

Level	Element (proposed element name)	Mapping to OpenURL term
Journal:	* Title (journalTitle)	title
	* Abbreviated Title (journalTitleAbbreviated)	stitle
	* Identifier (journalIdentifier)	issn, eissn, coden, sici
Issue:	* Volume (journalVolume)	volume
	* Number (journalIssueNumber)	volume?
	* Chronology (journalIssueDate)	date, ssn
	* Identifier - e.g. an article level SICI (journalIssueIdentifier)
Article:	* Page range (pagination)	pages, spage, epage
	All 15 DC elements, e.g.:
	Title	atitle
	Creator
	Date
	Identifier
	Publisher

Some discussion:

JournalTitleAbbreviated - this might be seen as a kind of identifier (as might JournalTitle itself). Some journal title abbreviations adhere to published schemes, e.g. ISO4, Chemical Abstracts, etc.
JournalIdentifier - this would normally be an ISSN, but might also include CODEN, etc.
Issue - there was some discussion about journals that were not arranged in volumes, issues and parts, like those arranged by year (e.g. 12/1999, 1/2000, etc.).
JournalIssueIdentifier - it was considered unlikely that individual journal issues would include identifier information, but as the SICI can be used to encode this it has been included here.
JournalIssueDate - this may be identical to the article date given in DC.Date.
Article information would be included in the DC record itself. For example, the authors in the DC.Creator element, the publisher in the DC.Publisher element and the date of publication in a DC.Date element. It was acknowledged that there were differences between the real date of publication and the dates printed on the issue by the publisher but this problem could not be addressed here. The only information that could not be carried by the existing DC was the information on pagination (logically part of DC.Format?).

2. Encoding this information

The meeting went on to consider how this information could be encoded. The one-to-one principle would mean that it would not be acceptable to encode all of this information in a single DC record for an article.

At present, there are several possible ways to implement (e.g. encode) the additional elements. It was suggested that a new DC Citation working draft could include information on more than one way to implement its recommendations. Three possible implementations were discussed:

Dublin Core Structured Value - the original DC-Citation Working Group had recommended an encoding mechanism based on a Structured Value (SV). In this, the DC-Citation SV had been a included in DC.Relation as a type of identifier. Taken together, the eight proposed elements might form some kind of identifier for an article, so this may suggest that they could be implemented as a structured value for DC.Identifier (with a scheme like DC-cite). However, Structured Values had not been widely implemented in other DC elements (with the exception of DC.Coverage) and their use has been deprecated by DCMI. Information that needs to be human-readable could go into DC.Description.
OpenURL - this emerging standard [3] could be used for encoding the new elements required. Most of the identified elements would map to an OpenURL term (see table above). This would also be a potential value for DC.Identifier. There was some discussion as to whether the OpenURL standard would be suitable with regard to things like character sets, or whether it would be easier to generate OpenURL information from DC metadata rather than the other way around.
Defining new elements - a third way to encode the new elements would be to define the eight new elements within a new namespace. The main objection to this is that this would break the one-to-one principle. It was suggested that consideration could be given to creating three new elements for HostJournal, HostIssue and Pagination and to add the relevant data to those fields. There was also a suggestion of a new more generic DC.Host field that could be used for journal articles or for chapters or images in books. It might also be possible to devise a RDF schema that would be able to avoid breaking the one-to-one principle.

It was suggested that a new working draft would need to show the different ways of encoding this information, e.g. using a defined DC Structured Value or OpenURL in DC.Identifier. Giving examples in RDF would be more difficult as it might preempt the conclusions of the DC-Architecture working group.

3. Agree what to do to move this forward within DC

To contact Stu Weibel and Makx Dekkers first about the required process. Then write up a new DC Citation recommendation based on the 1999 document (and superseding it) with added examples showing how it could be implemented as

DC Structured Value
OpenURL
RDF

There was also scope for a wider range of work to be done by a DC WGs, e.g. the DC Libraries WG.

References

[1] Morgan, C., Bibliographic citation working draft. DCMI Working Draft, 1999-07-02.
http://www.dublincore.org/documents/bib-citation/

[2] Powell, A., Apps, A., "Encoding OpenURLs in Dublin Core metadata." Ariadne, Issue 27, March 2001.
http://www.ariadne.ac.uk/issue27/metadata/

[3] OpenURL: http://www.sfxit.com/openurl/

DC Citation Working Group Web pages at:
http://www.dublincore.org/groups/citation/

The <DC-CITATION@jiscmail.ac.uk> archive is available at:
http://www.jiscmail.ac.uk/lists/dc-citation.html

Maintained by Michael Day of UKOLN
Created: 21-Mar-2001
Last updated: 03-Apr-2001