field name / inheritance properties

[maieul]

Many remarks of @ClintEastwood on #10 made me thinking we should change the field name and the property, and think to a better datamodel.

What are the contrainst for evolution:

• not changing the meaning of the field of standard biblatex type.
• changing as little as possible the field names of biblatex-bookinarticle.

Here is the actually existing model.
biblatex-bookinarticle-crossref.pdf

We need to think to a better datamodel. Here is example with @mvcollection

Contrainst are :

• Going from @mvcollection to @bookinincollection, by the the step of @collection and @incollection.
• Have coherent name, as possible.
• Be able to refers to the editor of:
  -* the @mvcollection
  -* the @collection
  -* the @bookinincollection

So we have to make distinction between two package:

• one for the bottom level : the @book-in-something
• one for adding translator/editor for the @mvcollection when being in @collection.

So what I would do is to write a new datamodel, and submit you. After that, take one week to be sure, and code only next week-end.

So @ClintEastwood, @moewew, @sonator, @Doc73, what do you think of the general idea?

[moewew]

The editor thing seems to be a constant source of displeasure for people in the humanities: TeX.SX: Why is the biblatex option “useeditor=true” ignored for book articles?.

The general idea sounds great.

@bookinincollection will be quite a thing with potentially four title-like fields. One each for mvcollection, collection, incollection, bookinincollection. Maybe one could at least cut out the middle man incollection and make the type a @bookincollection or are there cases where we really have a @bookinincollection?

[maieul]

@moewew yes, I have a real case. See the "Passio Sancti Titi Apostoli" in biblatex-bookinarticle handbook. It is a real example from my thesis...

[moewew]

Uhh, that is quite something ...
I guess all the four levels are needed then.

(I'm referring to what you mentioned in #11 now) I'm not exactly familiar with how your other packages work, but going from a .sty to a .dbx/.bbx approach might make it harder for people to actually use your package. (If you force people to use a particular bibstyle= they cannot use they favourite bibliography style like numeric or authoryear any more, I have reason to believe that with a .sty package that would probably work fairly smoothly.)

[maieul]

@moewew I agree perfectly with you. I have asked to the biblatex team to allow feature of .dbx in a .sty file. They didn't want. Cf plk/biblatex#220 (comment) and https://tex.stackexchange.com/questions/154450/datamodel-distribution-with-biblatex.

So I have created biblatex-multiple-dm (https://github.com/maieul/biblatex-multiple-dm) which allows to use multiple .dbx/.bbx file. So it solve this problem.

[moewew]

Yes, I remember. Forgive me my ignorance, but does your package allow for multiple .bbx files as well? I thought it was for .dbxs only. Though I think one could probably still put the contents of the .bbx into a .sty.

[maieul]

Here my proposal for new model.

Good news :no need to change the meaning of the fields from standardbiblatex, and no need to change the field of bookinarticle
Bad news : need .dbx file

In this example, any "normal field" inherited by a @ininXX from any @inxx is prefixed by BOOK. It is not very elegant, but it's avoid breaking compatibility with the past.

[maieul]

here the file, I don't know why, but there was previously a mistake

issue11-collection.pdf

[maieul]

@moewew yes, biblatex-multiple-dm allow for multiple bbx. For example

\usepackage[tools={realauthor,manuscripts},bibstyle=verbose]{biblatex-multiple-dm}
\usepackage[bibstyle=multiple-dm,citestyle=verbose-trad2]{biblatex}

will load the bbx and .dbx files of biblatex-realauthor and biblatex-manuscripts, and the verbose.bbx file.

Loading .bbx file and .dbx file in the same time, instead of adding a .sty file, make shorter the preamble.
With you solution, we should do:

\usepackage[tools={realauthor,manuscripts},bibstyle=verbose]{biblatex-multiple-dm}
\usepackage[bibstyle=multiple-dm,citestyle=verbose-trad2]{biblatex}
\usepackage{biblatex-realauthor}
\usepackage{biblatex-manuscripts}

[maieul]

in the previous graphs : the green field of @incollection and higher will be add in new package (biblatex-morepeople ?) and the field in bookinincollection will be added in the successor of biblatex-bookinarticle (biblatex-bookinother)

[maieul]

so, now, I wait you reaction. Especially @ClintEastwood

[moewew]

Ahh, again I didn't realise how smart your packages actually are ;-).

The new model looks very sensible to me. The four levels accumulate a pretty large number of fields that need intuitive names so people don't get lost.

[maieul]

Ok. let other people tell what they think.

[maieul]

oh @moewew what do you think for the name of the new package ? biblatex-morename ? (as editor, translator etc. are name)

[maieul]

hi @ClintEastwood, some opinion on the new fields ?

[ClintEastwood]

@maieul
With the limited knowledge I have of the technical side, it sounds fine to me. I have to say that I understand the model "biblatex-bookinarticle-crossref.pdf" from your first post better than the "issue11-collection.pdf" model you posted later, because I don't know about mvcollection.

About the new fields, I agree with you that we basically need all of them. And if you want to make my solution of using (or misusing) the Titleaddon field with information such as \bibstring{byeditortrin} no longer necessary, I would be fine with that. However, this may make things very complicated for you and my solution of using (or misusing) the Titleaddon field for this is actually perfect. I do not share your concerns about the fact that such a field hould not contain any commands such as \bibstring{xyz} because the thesis-type requires to user to specify what kind of thesis it is precisely by using a localisation command e.g. \bibstring{phdthesis} to add that information. But if you want to implement all possibilities for editor, translator, annotator, introduction, commentator, and so on, please go ahead. I just suspect that it's going to be complicated, no?

Other than that, I am impressed by your enthusiasm and how you thought things through. Keep it up!

(Sorry for having not responded earlier; I was both sick and busy -- not a good combination.)

[maieul]

@ClintEastwood @mvcollection is for a @collection in multiple volume.
Don't be worry about thing complicated. I prefer things better thought to thing which seem easier but are not good thought.

For use of \bibstring in a field:

• first, @thesis entry don't use \bibstring in a field, but use a key value which, IN THE STYLE, and not in the field, is wrapped in a \bibstring
• suppose, finaly, you want to print only the first letter of the first name of the editor ? You have to change every "titleaddon" field you have done. With a dedicated field, you have only to change your style (or better, some preamble option).
• with your solution, you must be careful to reproduce everytime the same formatting for your titleaddon field. With my solution, you let the style do it.

In general, it is not because a solution is faster that it is better. In general, solution with specific tools for specific needs are better, even if we can share some tools.

In a case of a bibliographical system, using field for what they have to be used is better.

[ClintEastwood]

Yes sure. You're right. My solution is from a time when I did not even know that your bookinarticle-package existed -- and it will provide the perfect output for my dissertation which I have to hand in in a few days. Since no new solution will be around in time, I'll stick to it =)

but in general, all the points you just made are certainly right.

A note about @thesis: it does not use \bibstring, but the documentation say that one should use it if one wanted to specify which kind of thesis it is.

[maieul]

About @thesis � 4.9.2.13 Types of the biblatex handbook don't speak about using \bibstring, but about using some key word.

[maieul]

I have written biblatex-morename, which, for no, provides only the maineditor and the ineditor field. https://git.framasoft.org/maieul/biblatex-morename

Here the proto-handbook.
biblatex-morename.pdf

I will add crossref schemas in next time, and then I could add this feature to the new biblatex-bookinother package, and also solve the #10 problem.

[Doc73]

In handbook correct "mainditor" :-D

[maieul]

done
https://git.framasoft.org/maieul/biblatex-morename/commit/0437f42f8b19d6c14b63e30bb18e76b4377f6707

[maieul]

and now, with the graph

biblatex-morename.pdf

[maieul]

it should be biblatex-morenames and not biblatex-morename. So, as it was not officialy published, it is now moved to https://git.framasoft.org/maieul/biblatex-morenames.

[maieul]

Personnal notes:
Todo :

• declarer la validité des nouveaux champs de morename pour les nouveaux types (moreditor; ineditor -> pas valide)
• incorporer les nouveaux champs pour les nouveaux types (maineditor, pas ineditor)
• declarer bookineditor, bookeditor et les héritages
• patcher pour incorporer les nouveaux champs dans les styles standards : inbookeditor
• ajouter les nouveaux champs dans les nouveaux types : inbookeditor, bookeditor
• verifier l'emploi de bookineditor pour un @bookinbook