[tei-council] bibliog doc
O'Donnell, Dan
daniel.odonnell at uleth.ca
Wed May 19 13:54:58 EDT 2010
I think that is P5.2 or P6 talk. I like the idea, and that is starting
to come up enough that (shudder) we may need to start thinking of what
might go in P6. But I think it would be a major issue for p5 users. The
other possibility (but not now, I think) is to go with an idea like the
W3C's xhtml strict and transitional system.
On 10-05-19 09:22 AM, Laurent Romary wrote:
> I would not necessarily slim down the core just on this issue. Let us
> wait until we have an master plan of a set of reduce-sized modules. SO
> let us wait a while...
> Laurent (from Malte)
>
>
> Le 19 mai 10 à 17:14, Lou Burnard a écrit :
>
>
>> Another suggestion, which probably wont make me any friends, might be
>> to hive biblStruct and biblFull off to a chapter of their own. We
>> might
>> even go so far as to take them out of the core and put them in their
>> very own module. Yes that would cause all existing ODDs using them to
>> crash and burn, but it would slim the core down a bit, which has long
>> been a desideratum.
>>
>> Martin Holmes wrote:
>>
>>> Hi all,
>>>
>>>
>>>>> 2. I revised the additional material proposed for the end of
>>>>> section
>>>>> 3.? as follows:
>>>>>
>>>>>
>>>>> <p>The most commonly used elements in the model.biblLike class are
>>>>> <gi>biblStruct</gi> and<gi>bibl</gi>.<gi>biblStruct</gi> will
>>>>> usually be easier to process mechanically than<gi>bibl</gi>
>>>>> because
>>>>> its structure is more constrained and predictable. It is suited to
>>>>> situations in which the objective is to represent bibliographic
>>>>> information for machine processing directly by other
>>>>> systems or after conversion to some other bibliographic markup
>>>>> formats
>>>>> such as BibTeXML or MODS. Punctuation delimiting the components
>>>>> of a
>>>>> print citation is not permitted directly within a<gi>biblStruct</
>>>>> gi>
>>>>> element; instead, the presence and order of child elements must
>>>>> be used to
>>>>> reconstruct the punctuation required by a particular style.
>>>>> <!--While<gi>biblStruct</gi> offers enough
>>>>> flexibility for encoding bibliographic references to simple print
>>>>> works, for many documents, especially electronic ones, it proves
>>>>> problematic.--> <!-- no problems presented -->
>>>>> </p>
>>>>>
>>>>> <p>By contrast,<gi>bibl</gi> allows for considerable flexibility
>>>>> in
>>>>> that it can include both delimiting punctuation and unmarked-up
>>>>> text;
>>>>> and its constituents can also be ordered in any way. This makes it
>>>>> suitable for marking up bibliographies in existing documents,
>>>>> where it
>>>>> is considered important to preserve the form of references in the
>>>>> original document, while also distinguishing important pieces of
>>>>> information such as authors, dates, publishers, and so
>>>>> on.<gi>bibl</gi> may also be useful when encoding<soCalled>born
>>>>> digital</soCalled> documents which require use of a specific style
>>>>> guide when rendering the content<!-- why is this true of born
>>>>> digital
>>>>> dox in particular? -->; its flexibility makes it easier to
>>>>> provide all
>>>>> the information for a reference in the exact sequence required by
>>>>> the
>>>>> target rendering, including any necessary punctuation and linking
>>>>> words, rather than using an XSLT stylesheet or similar to reorder
>>>>> and
>>>>> punctuate the data.<!-- tough if you later want it in a different
>>>>> form for another rendering engine of course --> </p>
>>>>>
>>>>>
>>>> Lou wants a clearer rationale here.
>>>>
>>>> Martin's done a good job of explaining his rationale, but let me try
>>>> stating this in different terms just in case it alleviates
>>>> confusion over
>>>> Martin's use of "electronic" documents and "born-digital" ones.
>>>>
>>>> I believe Martin envisions two approaches to encoding bibliographic
>>>> citations given in a source document:
>>>>
>>>> a) You want to represent the source document as it is, even if it
>>>> has
>>>> inconsistencies in it.
>>>>
>>>> b) You want to impose structure on the citations to catch errors
>>>> and allow
>>>> you to format the citations according to various style guides (MLA,
>>>> Chicago, APA, etc.) automatically by displaying the content of
>>>> various
>>>> bibl/biblStruct/biblFull child elements in different orders. This
>>>> is the
>>>> born-digital case in the second paragraph: you're creating a new TEI
>>>> document for which there's no print source to be represented.
>>>>
>>>> If you're doing (a), you basically have to use<bibl>.
>>>>
>>>> If you're doing (b), people are generally inclined to use
>>>> biblStruct, but
>>>> Martin argues in this document (and at the symposium in Dublin)
>>>> that it's
>>>> more practical to use bibl. As described in the first paragraph,
>>>> he has
>>>> found that citations to electronic works are often quite
>>>> complicated in
>>>> structure and that if you try to use biblStruct, it will be quite
>>>> difficult to format according to the rules of MLA, Chicago, APA,
>>>> etc.
>>>>
>>>> Martin, chime in if I got this wrong.
>>>>
>>>>
>>> That's exactly my point, expressed more clearly than I've managed to
>>> express it so far myself. My worry is that we push people into using
>>> <biblStruct> when<bibl> would actually be more suitable, simply
>>> because
>>> of the weight of examples of<biblStruct> and the absence of any
>>> encouragement to think about<bibl> as a more practical alternative.
>>>
>>>
>>>
>>>>> 3. Use of persName inside biblStruct
>>>>>
>>>>> <!-- Name markup is essential for proper
>>>>> indexing and other forms of processing. It
>>>>> seems advisable that all biblStruct examples
>>>>> use it, since the purpose of biblStruct is to
>>>>> provide a highly-structured reference. -->
>>>>>
>>>>> While this may be true, it presents us with quite a problem in
>>>>> terms
>>>>> of house style. Usually we try not to use elements from one
>>>>> module in
>>>>> examples appearing in a chapter which describes another. In the few
>>>>> rare exceptions, we make quite a song and dance about the need to
>>>>> include the other module etc. But biblStruct and friends are
>>>>> described in the core module, whereas the<persName> etc. elements
>>>>> are described in names and dates. (That incidentally is why
>>>>> the<name>
>>>>> element was originally used in some of these examples -- name is
>>>>> available in the core). So, while I am perfectly to change some
>>>>> of the
>>>>> examples to indicate what you propose as appropriate use of the
>>>>> naming elements, I don't think it should be done uniformly. I fear
>>>>> this needs more mulling over.
>>>>>
>>>>>
>>>> Yes indeed. In the summary of our proposal to Council, Martin,
>>>> Laurent,
>>>> and I asserted in principle 1 that if you use biblStruct, you really
>>>> should use the Names and Dates module. Council agreed to this.
>>>> If we
>>>> don't change all of the examples to reflect this, it needs to be
>>>> as clear
>>>> as possible to readers why this is the case.
>>>>
>>>>
>>> This issue is similar to the one above: if we assume (and my
>>> experience
>>> suggests this is true) that most users, at least in the early
>>> stages of
>>> using TEI, will tend to copy-paste examples from the Guidelines and
>>> adapt them, then we ought to avoid providing examples which will not
>>> work very well for them in real projects. A<biblStruct> whose name
>>> components are not marked up is not very useful for its intended
>>> purpose
>>> -- automated processing and interchange.
>>>
>>> I'd suggest that we add a section on "Name encoding in
>>> bibliographical
>>> references", fairly early in the chapter, to clarify this. Does that
>>> make sense?
>>>
>>> Cheers,
>>> Martin
>>>
>>>
>>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
> Laurent Romary
> INRIA& HUB-IDSL
> laurent.romary at inria.fr
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
--
Daniel Paul O'Donnell
Professor of English
University of Lethbridge
Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/)
Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America
President-elect (English), Society for Digital Humanities/Société pour l'étude des médias interactifs (http://sdh-semi.org/)
Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/)
Vox: +1 403 329-2377
Fax: +1 403 382-7191 (non-confidential)
Home Page: http://people.uleth.ca/~daniel.odonnell/
More information about the tei-council
mailing list