Re: [docbook-tc] Proposed new Dublin Core elements

["Nancy (Paisner) Harrison" <nancyh@rational.com>]

Bob

Thanks for a fine summary.  The table was very helpful.

I like your suggestions for identifier, source, and relation.

The idea of a Coverage element I find a little difficult, ranging into
the very field-specific and leaving us open to adding all sorts of little
quirks.  Not that DocBook doesn't have lots of quirks already, but
they're generally in the service of its original charter.  I can
understand how, from the point of view of interoperability, reusability,
and general integration with another standard, we  want to have good
matches for DC. On the other hand,  I would prefer the use of a
'keyword' or 'subject' with a role of 'coverage' for the purpose, since
that's how the usage/semantics of the term come through to me.


Nancy

At 06:14 PM 1/8/02 , Bob Stayton wrote:
>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
>
>

________________________

Nancy (Paisner) Harrison

Rational Software

Lexington  MA

nancyh@rational.com