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

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

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


Subject: Re: [docbook] [docbook-apps] Biblioentry markup standards -- identifying the type of entry


Hi Peter,

I think we agree on pretty much everything. I put a couple of clarifying notes in your message below. I was a bit sloppy in my terminology.

I think my next step will be to come up with a proposal for some conventions so thereâs something concrete to bat around. Any input from you and anyone on the list would be most welcome.

Best regards,
Dick
-------
XML Press
XML for Technical Communicators
http://xmlpress.net
hamilton@xmlpress.net



> On Jun 12, 2020, at 03:59, Peter Flynn <peter@silmaril.ie> wrote:
> 
> 
> On 12/06/2020 08:21, Richard Hamilton wrote:
>> Thanks Peter, Tony, and Norm for your thoughts,
>> A lot to consider here.
> 
> Indeed. It also impinges a lot on other disciplines, especially Library and Archive aspects, which have a different take on what 'a record' ought to contain. As a former colleague said "I gathered 40 librarians and asked them what I should do, and I got 40 mutually incompatible answers." That's not to knock librarians, just to highlight that this has been rattling on since the 50s, and doesn't look like being resolved any time soon :-)
> 
>> - What guidance can these initiatives provide in designing markup
>> conventions for biblioentry?
> 
> Lots, but long-term.
> 
>> - How can these initiatives make it easier to process biblioentrys
>> into multiple bibliographic formats?
> 
> By minutely documenting the algorithms for selection, placement, punctuation, and formatting; in a way that they can be implemented in any suitable processing language.
> 
> Or by providing algorithms for the transformation into a language that already knows all about reformatting into different formats.
> 
>> My thoughts are that on the markup side, these projects donât provide much guidance that can be applied directly to biblioentry.
> 
> I think you're right; but nor to other XML formats for doing the same thing (eg TEI, JATS). Those projects did a LOT of research into the bibliographic area, but they were looking at it from an entirely different angle.
> 
>> The main thing they do is provide help with identifying what
>> information needs to be captured for a wide variety of bibliographic
>> types, but not much guidance on how to structure that information
>> consistently in biblioentry. And, given the variation in how
>> biblioentry is used in practice, I believe that some conventions are
>> needed if we want to make biblioentry useful.
> 
> That would be great.
> 
>> I think there is also a pretty good argument for being able to convert biblioentry into BibTeX (as Peter does) and for converting
>> BibTeX (or some of the other formats) into DocBook. 
> 
> JabRef can export BiBTeX as DocBook 4.4.
> 
>> It also exports DocBook 5.1, though (to highlight some of the inconsistencies out there)
>> the biblioentry conventions that it uses are incompatible with the ISO690 module, and
>> would also probably work poorly (if at all) with your conventions (though I didnât try 4.4;
>> that might work better).
>>
>> There there are thousands of citations available in some of these
>> formats, often easily accessible in web databases. Being able to
>> select and convert citations into DocBook would give DocBook users
>> access to a huge number of citations 
> 
> Most desktop bibliographic database systems can read and write RIS, BiBTeX, and EndNote (XML).
> 
>> (I searched around in one database and found one of the first
>> conference papers I ever wrote, in 1979:-)
> :-)
> 
>> On the processing side, the style information that CSL or BibTeX encode might be used by a program to generate a stylesheet that could
>> process biblioentrys into any format that CSL or BibTeX has encoded
>> but it doesnât look like an easy job, so the question becomes whether
>> it would be used by enough people to justify the effort required to
>> write such a program.
> 
> [Old] BiBTeX styles (.bst) files are probably not an option as they are written in a language used only by the bibtex program.
> 
> biblatex, however, is written in LaTeX, so it is at least comprehensible, and biblatex already uses some XML in its config and runtime directives. But the .lbx files which define a particular style (eg APA, MLA, IEEE, etc) are in LaTeX, which is not really parseable except by the latex program.
> 
> I believe this is a blind alley, but I would be delighted to be proved wrong.
>>
>> Agreed. My guess is that the only people with enough knowledge of that system are people,
>> like you, who use LaTeX on the back end and donât need or want XSL for that function:-).
>>
> 
>> My opinion is that it is worth the effort to create a set of conventions for creating biblioentry elements 
> 
> Yes, absolutely. The rules we have created in-house notoriously trample all over bits of DocBook in order to make life easier when transforming to LaTeX and BiBTeX. Bringing order to chaos would be welcome.
> 
>> and for creating programs that would convert between biblioentry and
>> one of the common citation standards, 
> 
> I'm not clear what this means. None of the common citation standards have a file format, only a typographic appearance.
> 

> Or did you mean convert biblioentries to other bibliographic formats (RIS, EndNote/XML, BiBTeX, etc); for which I suspect lots of code already exists.
> 
>> Exactly, I was unclear in my terminology. Also, to keep this already long message from becoming a novel,
>> I didnât mention that I did look into code that converts BibTeX to DocBook, and found a bunch of programs,
>> most of which havenât been updated in years. The one exception I could find was JabRef.

>> but Iâm not convinced itâs worth the trouble to write a generalized
>> program to take CLS or BibTeX style definitions and convert them into
>> XSL stylesheets to process biblioentries.
> 
> No, absolutely a waste of time, IMNSHO.
> 
>> I think it would be easier to create modules similar to the ISO690 module, hopefully in a consistent manner that could be easily
>> modified to support other styles. 
> 
> Yes, building on existing work is usually A Good Idea.
> 
>> I think you could handle a fairly large number of output formats
> 
> I'm still unclear what this means, file formats or common citation standards typographic layouts (which would need a file format).
> 
>> Again my sloppy terminology. In this case, I meant citation styles (CMOS, APA, etc.).

> There are only a handful of relevant file formats for bibliographic work: those above plus TEI, JATS, a number of libary-based ones including MARCxml, and perhaps HTML-with-divs-and-spans-and-classes.
> 
> But there is an infinity of bibliographic reference formats: basically every book publisher and journal publisher on the planet has seen fit to create their own incompatible layout. On my system, there are 360 unique biblatex .lbx files and 425 unique old bibtex .bst files.
> 
>> before you would come close to the amount of time it would take to
>> create a reliable generalized program, especially considering the
>> issues that Norm found with CSL. If there were a bunch of people
>> clamoring for a whole bunch of different formats, that might be a
>> reasonable course, but after 20+ years of DocBook development, that
>> doesnât seem to be the case.
> 
> Yes, the most common reference formats probably number a dozen or so. But they are a nightmare to program: the work on APA and MLA still isn't complete in any language. It reminds me of the work to create the STIX fonts for mathematics: no sooner than there is a new release, someone invents a new notation.
> 
>> P.S. Regarding my original question, I like Norm's idea to allow
> > pubwork on biblioentry.
> 
> I think he had it on citetitle.
> 
>> He suggested that at first, but at the bottom of that same message, he suggested pubwork on biblioentry.
>> Either could work, though I prefer giving the entire entry a type, rather than having to dive down to the
>> title to figure out what the type is.




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