[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [docbook-tc] Proposed new Dublin Core elements
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC