OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


/ Bob Stayton <bobs@caldera.com> was heard to say:
| 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).

Thanks for the excellent summary, Bob!

| 1.  Resource Identifier.
| ---------------------------

I think this is already covered by our new biblioid element:

<!ENTITY % biblioid.element "INCLUDE">
<![%biblioid.element;[
<!ELEMENT biblioid %ho; (%docinfo.char.mix;)*>
<!--end of biblioid.element-->]]>

<!ENTITY % biblioid.attlist "INCLUDE">
<![%biblioid.attlist;[
<!ATTLIST biblioid
		class	(urn|doi|isbn|issn|pubnumber|other)	#IMPLIED
		otherclass	CDATA	#IMPLIED
		%common.attrib;
		%biblioid.role.attrib;
		%local.biblioid.attrib;
>

Absent from that class list are 'url' and 'loc', both of which could
be added. Though I think I'd prefer to add 'uri' in place of 'urn' and
'libraryofcongress' instead of 'loc' which I think is too much like
'location'.

| 2.  Source.
| --------------

Do you think there's any chance we could make biblioid do double duty here?
Perhaps by allowing it to be an xlink element and impose the semantic that
if it points to something else, it's pointing to a source? Or maybe we need
a new attribute...

| 3.  Relation
| -----------------
| This element would capture relationships with other
| resources that are not already expressed with the various
| DocBook linking elements.  

This could be done in other ways, of course, but I think I'm in favor
of adding relation.

| 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;
|>

We probably want to allow at least the coverage qualfiers[1]

                                        Be seeing you,
                                          norm

[1] http://dublincore.org/documents/dcmes-qualifiers/#relation
-- 
Norman Walsh <ndw@nwalsh.com>      | Until death, it is all
http://www.oasis-open.org/docbook/ | life.--Cervantes
Chair, DocBook Technical Committee |


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC