schemaSpec: affiliation has to affiliate person with organization

[matyaskopp]

Element <affiliation> should affiliate a person with an organization with a role. I don't want to discuss here @role, it should be done in a separate issue. I want to discuss the relationship between person and organization. I believe there are three ways how it can be implemented:

1. Best solution is using an affiliation/@ref attribute to refer org/@xml:id, which can be supported by affiliation/@ana (@corresp would be better, but it is for another discussion improper usage of ana attibute #80) that points to the event related to such org.
2. Another solution can use affiliation/@key where the value should be some well-known name of an organization such as "OSN". This can be used when we don't want to introduce this organization in listOrg, but the name is quite determinate.
3. The organization is stored in the text value of the affiliation element. This should be admitted when other options fail.

With respect to above observations, I have discovered the following bugs (the list is not definitely complete)

• BG missing affiliation reference:
  

  ParlaMint/Data/ParlaMint-BG/ParlaMint-BG.xml

  Line 8456 in 4c61c8d

  <affiliation role="member"/>

  
  @ref contains URL:
  

  ParlaMint/Data/ParlaMint-BG/ParlaMint-BG.xml

  Lines 8129 to 8131 in 4c61c8d

  	<affiliation from="2014"
  	ref="https://www.europarl.europa.eu/portal/en"
  	role="MP">Евродепутат</affiliation>

• CZ (sorry for that, we changed the organization that represented the term onto the event and I did not think about the consequences enough.)

<affiliation ref="#parliament.PSP9" role="MP" from="2021-10-09T14:00:00"/>

where the @ref target is event:

<event xml:id="parliament.PSP9" from="2021-10-09">
  <label xml:lang="cs">9. volební období</label>
  <label xml:lang="en">term 9</label>
 </event>

and should be organization, the correct solution is:

<affiliation  ref="#parliament" ana="#parliament.PSP9" role="MP" from="2021-10-09T14:00:00"/> <!-- ana or corresp -->

• DK missing affiliation reference
  

  ParlaMint/Data/ParlaMint-DK/ParlaMint-DK.xml

  Line 5344 in 4c61c8d

  <affiliation role="minister"/>

• GB affiliation with category:

             <affiliation from="2018-04-10" ref="#parla.lower" role="MP"/>

• HR missing affiliation reference
  

  ParlaMint/Data/ParlaMint-HR/ParlaMint-HR.xml

  Line 535 in 4c61c8d

  <affiliation role="MP"/>

• HU missing affiliation reference
  

  ParlaMint/Data/ParlaMint-HU/ParlaMint-HU.xml

  Line 503 in 4c61c8d

  <affiliation role="MP"/>

• IS affiliation with government event (related to CZ case above)
  

  ParlaMint/Data/ParlaMint-IS/ParlaMint-IS.xml

  Lines 11593 to 11597 in bc6257e

  	<affiliation role="minister"
  	ref="#GOV_LV.44"
  	from="2017-01-11"
  	to="2017-11-30"
  	ana="#mstr.landbunadur #mstr.sjavarutvegur"/>

• IT affiliation with government event (see IS)
  

  ParlaMint/Data/ParlaMint-IT/ParlaMint-IT.xml

  Lines 903 to 906 in bc6257e

  	<affiliation from="2018-06-01"
  	ref="#GOV.CONTE.1"
  	role="minister"
  	to="2019-09-04"/>

• LT missing @ref="#S"
  https://github.com/clarin-eric/ParlaMint/blob/4c61c8d78c76929aac85140efce080ca86e39754/Data/ParlaMint-LT/ParlaMint-LT.xml#L3928

<affiliation ana="#S.8" from="2016-12-13" role="chairperson" to="2017-03-10"/>

• NL missing affiliation reference
  

  ParlaMint/Data/ParlaMint-NL/ParlaMint-NL.xml

  Line 572 in 4c61c8d

  <affiliation role="chairperson" from="2013-07-02" to="2019-06-11"/>

• PL missing affiliation reference
  

  ParlaMint/Data/ParlaMint-PL/ParlaMint-PL.xml

  Line 470 in 4c61c8d

  <affiliation role="MP"/>

@TomazErjavec, do we want to fix these issues? I wanted to make @ref obligatory, but I am not sure about that - as it would break most of the corpora.

[TomazErjavec]

Quite a mess, thanks for spotting it. I would say:

• I would definetely not use option 2, i.e. affiliation/@key, for many reasons: we introduce a new mechanism, as t is still kindof pointing, but not in any specified way, and you can't even specify the language of the value (as it is an attribute). I am less sure whether to have both options 1 and 3, i.e. have affiliation/@ref or, for cases where we can't be bothered to make an org, have affiliation/text(). But am leaning towards having just 1, because the whole point of the ParlaMint encoding is to have one way of encoding a certain piece of information and because it is easy to make a script that changes 3 to 1.

• For the affiliations currently without @ref, there is no simple answer, because having <affiliation role="member"/> is completely useless, and should be corrected or the whole affiliation removed. Others are semi-useful, like 'minister', 'chairperson', i.e. you know what they were, which can be useful, but not exactly of what. And for 'MP' the @ref is more or less redundant, i.e. it is obvious of what they are an MP of, and this could be even automatically inserted.

In general, I would propose - and this is most likely another issue - to have per-corpus "fix" scripts, so we can change encodings for the better, without breaking validity. And then, when the ParlaMint I partners start making their new corpora, tell them to either fix their scripts, or simply use the fix-XX.xsl script for V3.

[matyaskopp]

I would definetely not use option 2, i.e. affiliation/@key, for many reasons: we introduce a new mechanism, as t is still kindof pointing, but not in any specified way, and you can't even specify the language of the value (as it is an attribute).

Ok, I have carried away due to my future ideas about attribute @key. I will (in future, not sure that I will be able to deliver it in ParlaMint 3 data) use the attribute @key in named entity normalization for NER (it is a small step towards named entity linking). It can solve the situation of namesakes, i.e. Václav Klaus in CZ data - we can't be sure if it is a name of father or son without a bigger analysing of context.

In the case of organizations in teiHeader: If we assume that if the name of the organization is similar, the organizations are identical, then we can merge all organizations to solution 1.
Great observation about the language -> it makes @key in affiliation context strange.

In general, I would propose - and this is most likely another issue - to have per-corpus "fix" scripts, so we can change encodings for the better, without breaking validity. And then, when the ParlaMint I partners start making their new corpora, tell them to either fix their scripts, or simply use the fix-XX.xsl script for V3.

Ok, creating an issue on v2tov3 fixings #183

[TomazErjavec]

The way affiliations refer to organisations is now fixed, so nothing more to do here, closing.