Menu

#542 Make occupation part of the content model of author

AMBER
open
None
5(default)
2015-05-28
2015-01-22
No

Whereas occupation can be a child of person by construction it cannot appear within the (very flat) content model of author. Still such information is needed when describing author information in publications when a little biographical description is provided as in:

~~~~~

<author>
<persName>
<forename type="first">Olivier</forename>
<surname>Le Deuff</surname>
</persName>
<email>oledeuff@gmail.com</email>
<occupation>

Docteur en sciences de l’information et de la communication, <hi rend="bold">Olivier Le Deuff</hi> a soutenu en 2009 une thèse sur <hi rend="italic">La culture de l’information en reformation</hi>. Il est chercheur au laboratoire PREFics (Plurilinguismes, Représentations, Expressions Francophones - information, communication, sociolinguistique), une composante du PRES Université européenne de Bretagne, Université Rennes 2. Il est également webmaster du Guide des égarés (<ref target="#www.guidedesegares.info"/>).


</occupation>
</author>

Behind this request there is also the subliminal message that author should be a little more aligned to person, but would not want to delay the decision on this ticket on the basis of a more general debate (unless the council thinks that this alignment is just obvious to have)

Related

Feature Requests: #543

Discussion

  • Martin Holmes

    Martin Holmes - 2015-01-22

    I think <author> is playing the role of <respStmt>, to a large degree. To have it also take on the role of <person> is going to be a bit confusing, I would think.

     
  • Laurent Romary

    Laurent Romary - 2015-01-22

    Well, really no. respStmt is such a very simple construct and if you compare to the variety of things you can already do with author (e.g. precise affiliations), that missing occupation can nearly be seen like a bug.

     
  • Hugh A. Cayless

    Hugh A. Cayless - 2015-02-10
    • assigned_to: Fabio Ciotti
     
  • Syd Bauman

    Syd Bauman - 2015-05-28

    Umm … no. TEI Council subgroup unanimously believes that it is incorrect to put information inside <author> other than the author’s name.

    (Other information, like e-mail address and occupation, should be inside the <bibl> … that is, <author> is not a substitute for <bibl>, it contains only the name(s).)

     
  • Laurent Romary

    Laurent Romary - 2015-05-28

    That's weird, since many application in the domain of scholarly communication do already put things like affiliation there. And it cannot be inside the biblX since you have different descriptions per author, of course. I do not see how this could be something attached to bible in any case...

     
  • James Cummings

    James Cummings - 2015-05-28

    Laurent: But the scholarly communications do not encode that information there. How you present it is up to you. Use <author ref="#abc123">author name</author> and provide all this additional information in a <person xml:id="abc123">...</person>. Embedding this all inside <author> goes against the intention of the <author> element.

     
  • Laurent Romary

    Laurent Romary - 2015-05-28

    Well, in http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/CO.html#COBITY, you have name + idno within an author.
    Do also consider that the perspective is that of structured bibliographic descriptions (biblStruct) of scholarly papers, where you do not map to an external personList, but have full author description in there.

     
  • James Cummings

    James Cummings - 2015-05-28

    Yes. I'm uncomfortable with that. Allowing <idno> was for specific id numbers relating to that author. Any more prosopographical information should be stored in the standard TEI manner. Having a structured bibliographic description of papers you can still link to a separate personography... If you must do this I'd say to use <note>. I would not want to encourage this manner of encoding myself.

     
  • Laurent Romary

    Laurent Romary - 2015-05-28

    But I know you grin when you say "note" encouraging using less semantically loaded elements (a euphemism for note) is not optimal for sure. Reminder there is a whole bunch of (partially) already implemented use cases (especially with regards <affiliation>). Just in my close surrounding: OpenEdition (400 journals in human sciences), Istex (national licence program with all scholarly articles from Elsevier, Springer, etc.),HAL (French national archive) GROBID... Shall we postpone this until we gather concrete examples?

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2015-05-28

    because prescriptive publishing schemas have an <author> element which acts like TEI's <person> element does not mean that the two <author> elements are semantically identical.

     
  • James Cummings

    James Cummings - 2015-05-28

    I understand that there are many examples of documents which present the information in one block. But would still argue that it should not be encoded as a single block. While that is a minor annoyance for large scale legacy data migration, it seems to me only quite minor. Repeating this information encoded on each <author> seems crazy in this day and age, IMHO. This was Council's decision in this instance. I'd say provide us examples of why it is impossible not to encode this properly using <person> or other solutions, long before we'd consider increasing the abuse of <author>. ;-)

     
  • Laurent Romary

    Laurent Romary - 2015-05-28

    Aperitif time here in Berlin... and I wish I would be f2F to discuss the use case. I'll be back ;-)

     
  • Fabio Ciotti

    Fabio Ciotti - 2015-05-28

    I agree with Laurent view that making bibliographic description of documents is not the something than making personagraphy. And I would add that in many cases instead of building an authority from scratch in TEI people would prefer to have some fast way to put some info in the bibliographic description and maybe point to some external authority for details.

    But, I was giving a look at <authors> cm (while others are out for lunch) and I have found it has <affiliation> inside it as much as <date> and all <name> like elements. I think that all the use cases that Laurent is citing can be coped with this not so flat equipment.