[docbook-tc] Proposed new Dublin Core elements

[Bob Stayton <bobs@caldera.com>]

Draft Proposal for new DocBook elements to support Dublin Core
---------------------------------------------------------

This proposal is my other action item from the last DocBook
TC meeting.  While reading it you should have at hand
the HTML table mapping Dublin Core to DocBook
that I sent out earlier (actually, I attached it
here again).

The following Dublin Core elements are already
covered by DocBook elements and nothing new
is needed.  Please refer to the
HTML table for explanations. 

Title
Creator
Subject
Description
Publisher
Contributor
Date
Language
Rights

The following Dublin Core elements are not covered by
DocBook elements, but can be inferred from them.
I think no new elements are needed for them either.

Type
Format


Below is a description of four new elements that I'm
proposing to support Dublin Core metadata:
  <identifier>
  <source>
  <relation>
  <coverage>

The first three have similar structure since they are
describing resources.

1.  Resource Identifier.
---------------------------
There is a need in DocBook to uniquely identify the current
document.  Any number of identifier schemes could be
used, both formal and informal.  I propose a new
<identifier> element to be included in the *info set.
Given that one resource can be described using more
than one scheme, I think more than one identifier element
should be permitted.

The element's content is an identifier string.  A scheme
attribute can be used to identify a formal scheme, and its
enumerated list can be extended in a customization layer.
I'm open to suggestions on the enumerated list of schema.
One could also use a role attribute to indicate an informal
scheme.  The <isbn> and <issn> elements would eventually be
subsumed under this element.

<!ELEMENT identifier (#PCDATA) >
<!ATTLIST identifier 
                %common.attrib;
                %identifier.scheme.attrib;
                %identifier.role.attrib;
                %local.identifier.attrib;
>

<!ENTITY % identifier.scheme.attrib
               "scheme   (isbn
                         |issn
                         |loc
                         |uri
                         %local.identifier.schema;)       #IMPLIED"
>
<!-- loc is Library of Congress -->

<!ENTITY % identifier.role.attrib "%role.attrib;">


2.  Source.
--------------
It is useful to record if a document or element
(text or graphic) has been derived from another resource.
I propose a new <source> element that is structured
similarly to the <identifier> element to meet that need.
It could appear inside any *info element, including the
<objectinfo> element used for mediaobjects.

<!ELEMENT source (#PCDATA) >
<!ATTLIST source 
                %common.attrib;
                %source.scheme.attrib;
                %source.role.attrib;
                %local.source.attrib;
>

<!ENTITY % source.scheme.attrib
               "scheme   (isbn
                         |issn
                         |loc
                         |uri
                         %local.source.schema;)       #IMPLIED"
>

<!ENTITY % source.role.attrib "%role.attrib;">


3.  Relation
-----------------
This element would capture relationships with other
resources that are not already expressed with the various
DocBook linking elements.  
I propose a new <relation> element that is structured
similarly to the <identifier> element to meet that need.
It could appear inside any *info element, including
the <objectinfo> element in mediaobjects.

The content of <relation> would be the identifier of the
other resource.  The scheme or role attributes would
identify the scheme used in naming the resource.  A "type"
attribute would capture the relationship type, and would
use the enumerated Dublin Core relation qualifiers,
extensible with a parameter entity.

<!ELEMENT relation (#PCDATA) >
<!ATTLIST relation 
                %common.attrib;
                %relation.scheme.attrib;
                %relation.role.attrib;
                %relation.type.attrib;
                %local.relation.attrib;
>

<!ENTITY % relation.scheme.attrib
               "scheme   (isbn
                         |issn
                         |loc
                         |uri
                         %local.relation.schema;)       #IMPLIED"
>

<!ENTITY % relation.type.attrib
               "type     (IsVersionOf
                         |HasVersion
                         |IsReplacedBy
                         |Replaces
                         |IsRequiredBy
                         |Requires
                         |IsPartOf
                         |HasPart
                         |IsReferencedBy
                         |References
                         |IsFormatOf
                         |HasFormat
                         %local.relation.types;)       #IMPLIED"
>

4.  Coverage
----------------
This element's content describes the coverage domain of the
current document or element.  It could appear in
any *info element.  The simplest model
would be just text, but some might want something
more structured.

<!ELEMENT coverage (#PCDATA) >
<!ATTLIST coverage 
                %common.attrib;
                %coverage.role.attrib;
                %local.coverage.attrib;
>



Bob Stayton
8 January 2002
Version 1.0

Title: Dublin Core in DocBook

Dublin Core in DocBook

This table summaries the Dublin Core Elements[1] and how they map to DocBook elements in the DocBook 4.1.2 DTD. For more information on Dublin Core, see:

[1] http://dublincore.org/documents/1998/09/dces/
[2] http://dublincore.org/documents/1999/08/05/resource-typelist/

DC Element	DC Label	Description	DocBook equivalent
Title	Title	The name given to the resource, usually by the Creator or Publisher.	<title>
Author or Creator	Creator	The person or organization primarily responsible for creating the intellectual content of the resource. For example, authors in the case of written documents, artists, photographers, or illustrators in the case of visual resources.	<author>, <corpauthor>
Subject and Keywords	Subject	The topic of the resource. Typically, subject will be expressed as keywords or phrases that describe the subject or content of the resource. The use of controlled vocabularies and formal classification schemas is encouraged.	<keywordset> for freely chosen words, <subjectset> for controlled vocabulary.
Description	Description	A textual description of the content of the resource, including abstracts in the case of document-like objects or content descriptions in the case of visual resources.	<abstract>?
Publisher	Publisher	The entity responsible for making the resource available in its present form, such as a publishing house, a university department, or a corporate entity.	<publishername>
Contributor	Contributor	A person or organization not specified in a Creator element who has made significant intellectual contributions to the resource but whose contribution is secondary to any person or organization specified in a Creator element (for example, editor, transcriber, and illustrator).	<othercredit>, <collab>, <editor>, possibly another <author> with a role attribute.
Date	Date	A date associated with the creation or availability of the resource. Recommended best practice is defined in a profile of ISO 8601 ( http://www.w3.org/TR/NOTE-datetime ) that includes (among others) dates of the forms YYYY and YYYY-MM-DD. In this scheme, the date 1994-11-05 corresponds to November 5, 1994.	<date>, <pubdate>
Type	Type	The category of the resource, such as home page, novel, poem, working paper, technical report, essay, dictionary. For the sake of interoperability, Type should be selected from an enumerated list that is under development in the workshop series.	no element matches the Dublin Core Types [2]. Implied values: text, image. This could be a new metadata element.
Format	Format	The data format and, optionally, dimensions (e.g., size, duration) of the resource. The format is used to identify the software and possibly hardware that might be needed to display or operate the resource. For the sake of interoperability, the format should be selected from an enumerated list that is currently under development in the workshop series.	no element describes this. The XML is an implied text/xml value. When processed to another format, then other format values apply. This does not need a new element, IMHO.
Resource Identifier	Identifier	A string or number used to uniquely identify the resource. Examples for networked resources include URLs and URNs (when implemented). Other globally-unique identifiers, such as International Standard Book Numbers (ISBN) or other formal names would also be candidates for this element.	<isbn>, <issn>, <invpartnumber>, <pubsnumber>. Also id attribute (but not globally unique).
Source	Source	Information about a second resource from which the present resource is derived. While it is generally recommended that elements contain information about the present resource only, this element may contain metadata for the second resource when it is considered important for discovery of the present resource.	no element matches this. An XML document could refer to a data repository from which it is derived, or formatted output could refer to its XML source. Possibly a new DocBook metadata element.
Language	Language	The language of the intellectual content of the resource. Recommended best practice is defined in RFC 1766 http://info.internet.isi.edu/in-notes/rfc/files/rfc1766.txt	<lang>
Relation	Relation	An identifier of a second resource and its relationship to the present resource. This element is used to express linkages among related resources. For the sake of interoperability, relationships should be selected from an enumerated list that is currently under development in the workshop series.	<xref>, <link>, <ulink>, <olink>. Also, any number of implied relationships among a document's elements (next, previous, etc.). XLink elements can also express relations to other resources. This is a potentially very rich area.
Coverage	Coverage	The spatial and/or temporal characteristics of the intellectual content of the resource. Spatial coverage refers to a physical region (e.g., celestial sector) using place names or coordinates (e.g., longitude and latitude). Temporal coverage refers to what the resource is about rather than when it was created or made available (the latter belonging in the Date element). Temporal coverage is typically specified using named time periods (e.g., Neolithic) or the same date/time format ( http://www.w3.org/TR/NOTE-datetime ) as recommended for the Date element.	no element matches this. Could be a new metadata element.
Rights Management	Rights	A rights management statement, an identifier that links to a rights management statement, or an identifier that links to a service providing information about rights management for the resource.	<copyright>, <legalnotice>