Como citar documentos tipo relatório que não possuem/precisam de instituição?

Question

dr.: Como citar um Working Paper que não tem/não deveria ter institution?

---

Otipo de entrada biblatexreportdeve ser usado para:

Um relatório técnico, relatório de pesquisa ou white paper publicado por uma universidade ou alguma outra instituição.

Os campos obrigatórios para a reportsão author, title, type, institution, year/ date.

De acordo comesta recomendaçãoEu costumo usar o reporttipo para Working Papers. Contudo, para certas séries de Documentos de Trabalho, adicionar uma instituição parece redundante e produz entradas bibliográficas desnecessariamente desordenadas. Este é o caso de todas as séries de Working Papers em que o nome da instituição faz parte do nome da série. Por exemplo, "NBER Working Papers" são (obviamente) publicados pelo NBER.

Para ilustrar a questão, considere o seguinte exemplo:

\documentclass{scrartcl}
\usepackage[backend=biber,bibstyle=authoryear,dashed=false]{biblatex}
\addbibresource{mwe.bib}
\begin{filecontents}{mwe.bib}
@Report{Example1,
  author      = {Author, Sample},
  date        = {2020},
  title       = {A Report},
  type        = {The Institution's Working Paper Series},
  number      = {42}
}
@Report{Example2,
  author      = {Author, Sample},
  date        = {2020},
  title       = {A Report with Redundant Institution},
  type        = {The Institution's Working Paper Series},
  number      = {42},
  institution = {The Institution}
}
\end{filecontents}
\begin{document}
\nocite{*}
\printbibliography
\end{document}

• Problema: Prefiro o exemplo 1 (sem instituição), mas o institutioncampo é obrigatório.
• Soluções alternativas/O que eu tentei:
  1. Apenas ignore o que institutioné obrigatório e deixe-o vazio. Isso funciona (veja acima), mas viola a especificação do modelo de dados. Mas: Isso gera muitos avisos irritantes ao validar o modelo de dados e, além disso, não tenho certeza se as versões futuras do biber/biblatex permanecerão tão tolerantes com a falta de campos obrigatórios.
  2. Forneceralgunsinstituição de espaço reservado e, em seguida, limpar o campo nos moldes de \AtEveryBibitem{\ifentrytype{report}{\clearfield{institution}…mas como não quero limpar institutionparatodosrelatórios, eu precisaria de algum "espaço reservado mágico" constante (ou palavra-chave) e limpo institutionapenas com a condição de observar esse espaço reservado mágico que é... confuso, propenso a erros e desorganiza meu arquivo BIB.
  3. Basta usar outro tipo de entrada que não exija instituição. Um candidato natural poderia ser misc– mas não tem numbercampo. Como alternativa, eu poderia (ab-) usar manual, mas isso imprime numberantes de type, enquanto preciso da ordem oposta:

     Autor, Amostra (2020c). Um relatório com instituição redundante. 42. Série de documentos de trabalho da instituição.

  4. Basta usar outro tipo de entrada que não exija instituição,de novo: Uso o manualtipo with series={The Institution's Working Paper Series}, mas não gosto de usar o tipo de entrada errado ( manual) e usar serieswhere typefor mais apropriado (IMO).
• Pergunta: Como citar um Working Paper que não tem/não deveria ter institution? Não tenho certeza de qual das minhas abordagens acima é a mais promissora, mas definitivamente prefiro uma solução com um modelo de dados válido (ao contrário de (1)), semântica sensata (ao contrário de (4)) e um mínimo de coisas que podem acontecer errado (ao contrário de (2)). Então, talvez (3) e alterar a ordem de typee numberpara miscseja melhor... mas estou aberto e grato por qualquer sugestão.

Answer 1

dr.Escolha a opção 1. Se o aviso de validação do modelo de dados o incomoda tanto, defina um novo modelo de dados que não exija institution(veja abaixo).

---

A distinção entre campos “obrigatórios” e “opcionais” biblatexé um pouco menos rígida do que pode parecer à primeira vista.

Além do código de validação do modelo de dados, não há nada no biblatexcódigo que conheça os campos obrigatórios ou obrigatórios.A biblatexdocumentaçãodiz

Observe que os campos 'obrigatórios' não são estritamente obrigatórios em todos os casos; consulte §2.3.2 para obter detalhes. Os campos marcados como 'opcionais' são opcionais no sentido técnico. As regras de formatação bibliográfica geralmente exigem mais do que apenas os campos “obrigatórios”.

sobre campos 'obrigatórios' e 'opcionais'. E §2.3.2 explica melhor

§2.3.2Dados ausentes e omissos

Os campos marcados como 'obrigatórios' em §2.1.1 não são estritamente obrigatórios em todos os casos. Os estilos de bibliografia que acompanham este pacote podem funcionar com apenas um title campo para a maioria dos tipos de entrada. Um livro publicado anonimamente, um periódico sem editor explícito ou um manual de software sem autor explícito não devem representar problemas no que diz respeito à bibliografia. Os estilos de citação, entretanto, podem ter requisitos diferentes. Por exemplo, um esquema de citação autor-ano obviamente requer um author/ editore um yearcampo.

Para mim, os campos 'obrigatórios' e 'opcionais' são mais uma dica para os desenvolvedores de estilo sobre o que eles podem esperar do que um requisito rígido para usuários e seus .bibbancos de dados. De modo geral, eu diria que se suas entradas tiverem todos os campos listados como 'obrigatórios' na documentação, você pode esperar que a saída pareça razoável. Se você não tiver todos os campos obrigatórios, o resultado ainda poderá estar OK (e em muitos casos estará), mas se você reclamar caso não esteja satisfeito com o resultado, você pode não ter uma perna para se apoiar . Sua bibliografia não será automaticamente ruim se você não tiver todos os campos obrigatórios, mas não há garantia implícita de que ela terá uma boa aparência.

Penso que é importante ter em mente o conselho debtxdoc

2. Os treze tipos de entrada do estilo padrão funcionam razoavelmente bem na formatação da maioria das entradas, mas nenhum esquema com apenas treze formatos pode fazer tudo perfeitamente. Portanto, você deve se sentir à vontade para ser criativo ao usar esses tipos de entrada (mas se precisar ser muito criativo, há uma boa chance de estar usando o tipo de entrada errado).
3. Não leve os nomes dos campos muito a sério. Às vezes, por exemplo, pode ser necessário incluir o endereço do editor junto com o nome do editor no publishercampo, em vez de colocá-lo no addresscampo. Ou, às vezes, entradas difíceis funcionam melhor quando você faz uso criterioso do notecampo.
4. Não leve as mensagens de aviso muito a sério. Às vezes, por exemplo, o ano aparece no título, como emO Almanaque Mundial Gnus de 1966. Neste caso é melhor omitir o yearcampo e ignorar a mensagem de aviso do BibTeX.

Não creio que concorde totalmente com o exemplo do último ponto, mas a ideia geral é algo com que concordo definitivamente. De qualquer forma, o resultado final é: não use o modelo de dadostambémseriamente. No final, o resultado impresso é provavelmente o que mais lhe interessa.

Não posso dizer com certeza, mas certamente parece que alguns dos campos obrigatórios/opcionais são retirados diretamente doDocumentação BibTeXbtxdoc. Portanto, neste caso, institutioné provavelmente um campo “obrigatório” por razões históricas e não técnicas.

---

Qual é a pior coisa que pode acontecer se você não incluir um campo 'obrigatório'? Falando livremente, eu diria que o pior que pode acontecer é que seu estilo espera que o campo esteja presente e coloca algumas coisas dentro ou ao redor do institutioncampo que parecem deslocadas se o campo não estiver presente.

Vejamos isso de um ângulo mais técnico. Conforme mencionado acima, na verdade existe apenas uma parte do biblatexcódigo que sabe quais campos são obrigatórios e quais são opcionais: as declarações de restrição do modelo de dados. Essas declarações de restrição são repassadas ao Biber para verificação do modelo de dados e não são usadas em nenhum outro lugar biblatex. Portanto, do ponto de vista técnico, biblatexabsolutamente não se importa com as restrições do modelo de dados. Eles são usados ​​apenas para emitir dicas/avisos aos usuários.

O aspecto muito mais importante de toda essa questão de 'obrigatório'/'opcional' são as suposições implícitas que ela permite que os desenvolvedores de estilo façam. Geralmente, espera-se que os desenvolvedores de estilos escrevam seus estilos de forma que deixar de fora os campos opcionais não faça com que a saída pareça ruim. Pode-se argumentar que não existe tal expectativa para campos obrigatórios. Se faltarem campos obrigatórios, a responsabilidade é do usuário. Essas suposições implícitas não são codificadas e cabe inteiramente aos desenvolvedores o quanto eles desejam confiar nessas suposições.

O funcionamento geral biblatexe biblatexos estilos tornam extremamente fácil a proteção contra campos ausentes na maioria das situações, sem qualquer esforço adicional. Precauções explícitas contra campos ausentes só precisam ser tomadas em uma minoria muito pequena de casos extremos.

Eu esperaria que, na grande maioria dos estilos, @reportas entradas ainda parecessem boas, mesmo que não houvesse institution.

---

Vamos discutir um pouco as soluções alternativas sugeridas.

1. Só não preencha o institutioncampo se não quiser.

   Para mim, isso parece o melhor e mais simples curso de ação. Claro, você não está fornecendo um requiredcampo, mas se o resultado parecer melhor assim, quem vai culpar você? A validação do modelo de dados precisa ser ativada explicitamente e os avisos são de natureza um tanto artificial (como mencionado acima), então você deve estar perfeitamente no seu direito de ignorá-los. É extremamente improvável que os biblatexestilos padrão mudem de uma forma que significaria que as entradas sem institutionessa aparência OK agora deveriam parecer piores no futuro.

2. Use um espaço reservado (mágico ou não).

   Isso apenas enganaria a verificação do modelo de dados. Se mais tarde você se livrar do valor do campo com \clearfield, o campo ainda desaparecerá no que diz respeito ao estilo. Portanto, se você está preocupado com o fato de as coisas parecerem ruins na saída, você ainda não está do lado seguro.

3. (e 4.) Use um tipo de entrada diferente

   Isso certamente é possível, mas não parece muito melhor do que as outras opções. Você estaria desistindo da conexão semântica real pelo objetivo muito mais artificial de acertar os campos obrigatórios.

Provavelmente não será uma surpresa que eu seja a favor da opção 1.

Se você estiver incomodado com o aviso que recebe da verificação do modelo de dados, você pode reescrever as restrições do modelo de dados para removê-las institutionda lista de campos obrigatórios (as restrições originais podem ser encontradas emblx-dm.def).

\documentclass{article}

\begin{filecontents}{report-wo-institution.bib}
\ResetDatamodelConstraints

\DeclareDatamodelConstraints[
  article,
  book,
  inbook,
  bookinbook,
  suppbook,
  booklet,
  collection,
  incollection,
  suppcollection,
  manual,
  misc,
  mvbook,
  mvcollection,
  online,
  patent,
  periodical,
  suppperiodical,
  proceedings,
  inproceedings,
  reference,
  inreference,
  report,
  set,
  thesis,
  unpublished]{
    \constraint[type=mandatory]{
      \constraintfieldsxor{
        \constraintfield{date}
        \constraintfield{year}
      }
    }
  }

\DeclareDatamodelConstraints[set]{
  \constraint[type=mandatory]{
    \constraintfield{entryset}
  }
}

\DeclareDatamodelConstraints[article]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{journaltitle}
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[book,mvbook,mvcollection,mvreference]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[inbook,bookinbook,suppbook]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
    \constraintfield{booktitle}
  }
}

\DeclareDatamodelConstraints[booklet]{
  \constraint[type=mandatory]{
    \constraintfieldsor{
      \constraintfield{author}
      \constraintfield{editor}
    }
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[collection,reference]{
  \constraint[type=mandatory]{
    \constraintfield{editor}
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[incollection,suppcollection,inreference]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{editor}
    \constraintfield{title}
    \constraintfield{booktitle}
  }
}

\DeclareDatamodelConstraints[dataset]{
  \constraint[type=mandatory]{
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[manual]{
  \constraint[type=mandatory]{
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[misc,software]{
  \constraint[type=mandatory]{
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[online]{
  \constraint[type=mandatory]{
    \constraintfield{title}
    \constraintfieldsor{
      \constraintfield{url}
      \constraintfield{doi}
      \constraintfield{eprint}
    }
  }
}

\DeclareDatamodelConstraints[patent]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
    \constraintfield{number}
  }
}

\DeclareDatamodelConstraints[periodical]{
  \constraint[type=mandatory]{
    \constraintfield{editor}
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[proceedings,mvproceedings]{
  \constraint[type=mandatory]{
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[inproceedings]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
    \constraintfield{booktitle}
  }
}

\DeclareDatamodelConstraints[report]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
    \constraintfield{type}
  }
}

\DeclareDatamodelConstraints[thesis]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
    \constraintfield{type}
    \constraintfield{institution}
  }
}

\DeclareDatamodelConstraints[unpublished]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints{
  \constraint[type=data, datatype=isbn]{
    \constraintfield{isbn}
  }
  \constraint[type=data, datatype=issn]{
    \constraintfield{issn}
  }
  \constraint[type=data, datatype=ismn]{
    \constraintfield{ismn}
  }
  \constraint[type=data, datatype=date]{
    \constraintfield{date}
    \constraintfield{eventdate}
    \constraintfield{origdate}
    \constraintfield{urldate}
  }
  \constraint[type=data, datatype=pattern, pattern=\regexp{(?:sf|sm|sn|pf|pm|pn|pp)}]{
    \constraintfield{gender}
  }
}
\end{filecontents}

\usepackage[backend=biber,bibstyle=authoryear,dashed=false]{biblatex}

\begin{filecontents}{\jobname.bib}
@Report{Example1,
  author      = {Author, Sample},
  date        = {2020},
  title       = {A Report},
  type        = {The Institution's Working Paper Series},
  number      = {42},
}
@Report{Example2,
  author      = {Author, Sample},
  date        = {2020},
  title       = {A Report with Redundant Institution},
  type        = {The Institution's Working Paper Series},
  number      = {42},
  institution = {The Institution},
}
\end{filecontents}
\addbibresource{\jobname.bib}

\begin{document}
\nocite{*}
\printbibliography
\end{document}

A saída do documento ainda é a mesma, mas biber -Vserá silenciosa sobre a falta de institutions.

Claro que o institutioncampo ainda não foi fornecido. Mas acho que tudo se resume ase você não quiser dar um, institutionterá que conviver com as consequências de não dar esse campo.Nos estilos padrão (e espero que a maioria dos estilos contribuídos) basicamente não haja consequências em não fornecer o arquivo institution. Se você acha que possíveis consequências futuras são um risco muito grande, sua única opção é preencher o institutioncampo com um valor (que é impresso) ou escolher um tipo de entrada diferente. Se a primeira opção estiver fora de questão, então seu único caminho é um tipo diferente. Mas um tipo diferente é semanticamente menos satisfatório e pode não ser capaz de representar adequadamente todos os aspectos com @reporta maior precisão possível.