On Mon, Jan 14, 2002 at 09:58:56AM -0500, Norman Walsh wrote:
> / 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;
> >
Ah, I had missed that new element in 4.2. Gotta love the name.
Aren't biblioids what androids read? 8^)
> 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'.
Yes, I think 'uri' would cover both 'url' and 'urn'.
> | 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...
Well, biblioid and source can have identical content
models, but I think their semantics differ sufficiently to
warrant two elements. A biblioid points to the current
resource, while source would always point to another
resource. I think the document identifier needs to be
easily accessible. To require some processing of the
element to determine which is the document id and which are
pointers elsewhere puts too much burden on the user.
Are you trying to keep the element count down?
> | 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]
>
> [1] http://dublincore.org/documents/dcmes-qualifiers/#relation
> --
Um, you suggest using the coverage qualifiers but your
reference is to the relation qualifiers. You also agree
that relation could be an element, but don't say whether
you want the relation qualifiers.
I find the relation qualifiers to be useful and easily
understood, but I have to admit I don't see much use for
the coverage qualifiers within the Docbook domain, but others
might.
Bob Stayton 400 Encinal Street
Publications Architect Santa Cruz, CA 95060
Technical Publications voice: (831) 427-7796
Caldera International, Inc. fax: (831) 429-1887
email: bobs@caldera.com