On 8/11/2017 8:58 PM, Rik Kabel wrote:

On 2017-08-11 10:01, Alan Braslau wrote:

...

...

2) Apple Inc. is not a name so you should not be using author: organization is more appropriate.

I do not think that this should be the case.

APA and Chicago/Turbanian (and doubtless others) accept association names as author names, and provide rules for handling them.

and as a consequence i bet this is why journals get typeset partly by hand (tweak and cheat on these things) ... and why each publisher then has its own style (with cheats and tricks)

The lack of either an author or an editor is currently flagged in ConTeXt as an error for books and perhaps other bibtex entry types as well. Or do you mean to apply this recommendation to only the electronic type or some other limited subset of types?

Perhaps it is better to use the association name as an author and protect it with a layer of curlies or quotation marks, as {{Apple, Inc.}}, "{Apple, Inc.}", or '{Apple, Inc.}', any one of which will do

one can do that of course (an dit will work) but then someone will come along and say that ... our recomendation is that one spends some time on a proper database as it pays off

the job and also serve to prevent what would surely be unwanted abbreviation for styles that abbreviate what are parsed as given names. we really try to get away from fuzzyness ... in fact, the bib format or at least the way it's often used is a structural coding nightmare (and often tex commands are then used to bypass things) .. i think that it never went through a proper 'design, test, review, revise' cycle

reverse engineering what is there + side effects took us quite a while and esp the author bit is a pain (this parsing) ... there have been proposals for alternatives in the past decades (take mlbibtex) but so far we're stuck with historic stuff: making a database in a format that is not that suitable (no nesting) using practices that are counter intuitive and demand lots of obscure magic (one day Alan will wrap this up in an article) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

On 2017-08-12 11:28, Rik Kabel wrote:

On 2017-08-12 04:54, Hans Hagen wrote:

...

On 8/11/2017 8:58 PM, Rik Kabel wrote:

...

On 2017-08-11 10:01, Alan Braslau wrote:

...

...

2) Apple Inc. is not a name so you should not be using author: organization is more appropriate.

I do not think that this should be the case.

APA and Chicago/Turbanian (and doubtless others) accept association names as author names, and provide rules for handling them.

and as a consequence i bet this is why journals get typeset partly by hand (tweak and cheat on these things) ... and why each publisher then has its own style (with cheats and tricks)

...

The lack of either an author or an editor is currently flagged in ConTeXt as an error for books and perhaps other bibtex entry types as well. Or do you mean to apply this recommendation to only the electronic type or some other limited subset of types?

Perhaps it is better to use the association name as an author and protect it with a layer of curlies or quotation marks, as {{Apple, Inc.}}, "{Apple, Inc.}", or '{Apple, Inc.}', any one of which will do

one can do that of course (an dit will work) but then someone will come along and say that ...

our recomendation is that one spends some time on a proper database as it pays off

...

the job and also serve to prevent what would surely be unwanted abbreviation for styles that abbreviate what are parsed as given names. we really try to get away from fuzzyness ... in fact, the bib format or at least the way it's often used is a structural coding nightmare (and often tex commands are then used to bypass things) .. i think that it never went through a proper 'design, test, review, revise' cycle

reverse engineering what is there + side effects took us quite a while and esp the author bit is a pain (this parsing) ... there have been proposals for alternatives in the past decades (take mlbibtex) but so far we're stuck with historic stuff: making a database in a format that is not that suitable (no nesting) using practices that are counter intuitive and demand lots of obscure magic

(one day Alan will wrap this up in an article)

Hans

Alan has stated elsewhere that his intent is to provide first an APA-compliant subsystem, and to add after that support for other regimes. He has also expressed an understandable reluctance to add non-standard fields to bibtex. But it is clearly impossible to provide an APA-compliant system under such a constraint—for example, for some works APA requires an original publication date and bibtex does not support that. It is similarly difficult to see how one can comply with other requirements of APA, such as square brackets around estimated dates for archival sources (how do you identify an estimated date?), constructing shortened titles that are then alphabetized by the first non-significant word, spelling out author names where two or more authors share the same abbreviated names, and so on. Biblatex attempts to address some of these issues with an explosion of new fields, and still, I think, does not succeed. CSL may do a better job on some of these, but again, I do not think that the type of organic standards set forth by APA and others are fully amenable to any automated parsing. This is why I suggested to Alan (off-line) that we need a mechanism to override the generated citation and bibliography/reference list entries with customized versions (\citeas, or additional fields for \cite).

Clearly bibtex is not compatible with the requirements of current documentation standards. Those who require compliant citation to whatever standard with which they are burdened need a better database, support for conversion from bibtex, and a mechanism to override whatever automated result is produced. Of these, the last is most crucial.

As to the specific issue of association names as author names: Why is widening the definition of the author name field using an already-supported protection mechanism worse than overloading the use of the organization field, which is intended denote an affiliation and is not currently supported in the major entry categories?

Sorry, rereading what I wrote, I see that I mistakenly suggested that the btx subsystem does not support origdate. It does, but it is a non-standard extension of bibtex, which was my point. -- Rik

On Fri, 11 Aug 2017 14:58:53 -0400 Rik Kabel wrote:

The lack of either an author or an editor is currently flagged in ConTeXt as an error for books and perhaps other bibtex entry types as well. Or do you mean to apply this recommendation to only the electronic type or some other limited subset of types?

This will be corrected for types other than electronic when I look into a consistent set.

Perhaps it is better to use the association name as an author and protect it with a layer of curlies or quotation marks, as {{Apple, Inc.}}, "{Apple, Inc.}", or '{Apple, Inc.}', any one of which will do the job and also serve to prevent what would surely be unwanted abbreviation for styles that abbreviate what are parsed as given names.

This won't happen. We made a design choice not to follow such sloppy bibtex/LaTeX use and to require clean datasets. Apple Inc. is NOT a named author, it is an organization, and the APA specification is clear about this (it even has screwy rules about the first citation and then the following when one should abbreviate names [such as APA]). Of course, the specifications have to be fixed to handle this correctly and consistently, also trying to be consistent with the fields that are defined by the original bibtex documentation and followed by many bibtex manipulating tools (such as jabref). The problem is that the use of bibtex in the real world is a big mess! ALan

On 2017-08-12 22:38, Alan Braslau wrote:

...

On Fri, 11 Aug 2017 14:58:53 -0400 Rik Kabel wrote:

...

The lack of either an author or an editor is currently flagged in ConTeXt as an error for books and perhaps other bibtex entry types as well. Or do you mean to apply this recommendation to only the electronic type or some other limited subset of types? This will be corrected for types other than electronic when I look into a consistent set.

...

Perhaps it is better to use the association name as an author and protect it with a layer of curlies or quotation marks, as {{Apple, Inc.}}, "{Apple, Inc.}", or '{Apple, Inc.}', any one of which will do the job and also serve to prevent what would surely be unwanted abbreviation for styles that abbreviate what are parsed as given names. This won't happen. We made a design choice not to follow such sloppy bibtex/LaTeX use and to require clean datasets. Apple Inc. is NOT a named author, it is an organization, and the APA specification is clear about this (it even has screwy rules about the first citation and then the following when one should abbreviate names [such as APA]). Of course, the specifications have to be fixed to handle this correctly and consistently, also trying to be consistent with the fields that are defined by the original bibtex documentation and followed by many bibtex manipulating tools (such as jabref). The problem is that the use of bibtex in the real world is a big mess!

ALan

So organization will simply become a stand-in for author but with different parsing rules. A book will require an author or editor or organization. The first two will be parsed for surname, given name, and so on, while the last will not, and precedence rules will apply when more than one is present, as they do already.

But until that point, as Hans said, using the author field and protecting it with curlies will work.

How will other screwy rules be handled? Will there be an override mechanism, or is it your belief that a compliant subsystem can be developed? (Yes, I know that is a false dichotomy.)

On 8/13/2017 5:13 AM, Rik Kabel wrote: there is actually a concept of field sets and a lookup order concerning authors, there are many issues there: upto 6 snippets and the number determines what is expected (mostly inherited from the mess but we added some in order to deal with complex combinations of names) also, keep in mind that there's more than english names all revealed in the manual (and we wil make some demos) as one can export one can also easily generate one's one variant of the database for whatever purpose (another nightmare is embedded tex: absolutely not standardized and a pain when trying to collapse and sort) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------