ListRelation as a child of person?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ListRelation as a child of person?

ANTONIO ROJAS CASTRO

​Dear List,

We are currently encoding prosopograhic descriptions and we ​are very interested in representing relations between people and with publications. Here is an example:

<person xmlns="http://www.tei-c.org/ns/1.0" xmlns:xd="http://www.oxygenxml.com/ns/doc/xsl" xml:id="person_00047" role="actor">
   <persName>Barthès de Marmorières, Antoine (1736-1811)</persName>
   <sex value="M"/>
   <socecStatus>Baron</socecStatus>
   <birth>
      <date when="1736"/>
      <placeName ref="place_01022"/>
   </birth>
   <death>
      <date when="1811-08-03"/>
      <placeName ref="place_00432"/>
   </death>
   <occupation type="primary">Militär</occupation>
   <occupation type="other">Schriftsteller</occupation>
   <occupation type="other">Diplomat</occupation>
   <affiliation>
      <ref target="org_00258"/>
      <date when="1763"/>
   </affiliation>
   <bibl>
      <listRelation>
         <relation name="vater" ref="person_01501"/>
         <relation name="bruder" ref="person_00048"/>
         <relation name="freund" ref="person_01241">
            <desc>A. war Sekretär vor 1789 (unter "Comte d'Artois")</desc>
         </relation>
      </listRelation>
   </bibl>
   <listBibl>
      <bibl>
         <relatedItem>
            <ref target="publication_03151">Die Blütezeit der Oekonomischen Gesellschaft in Bern 1759-1766</ref>
         </relatedItem>
      </bibl>
   </listBibl>
</person>

At the moment, <listRelation> can be a child of <listPerson> but not a child of <person>. As you can see in the example, we are not interested in creating a list of people but to describe one person, use a <relation> element to store the name of the relation and provide a reference that points to another person.

In order to this we are nesting <listRelation> within a <bibl> element. However, we are not satisfied with this workaround and we are wondering why <listRelation> cannot be a child of <persons> as <listBibl>. Otherwise, is there any alternative that we may have overlooked?

Thanks in advance.

--
​Antonio Rojas Castro
Postdoctoral Researcher, Cologne Center for eHumanities
Communication coordinator, EADH


Reply | Threaded
Open this post in threaded view
|

Re: ListRelation as a child of person?

Magdalena Turska
Dear Antonio,

faced with a similar task I've used the <listRelation> element placed as a sibling of <person>.

<listPerson>
  <person>
   ...
  </person>
  <listRelation>
      <relation name="child" passive="P4f60049a-e123-44e8-8489-502b483baff4" subtype="natural" type="family" cert="high"/>
  </listRelation>
 </listPerson>

Which is actually invalid without explicitly specifying @active side of relationship (but okay for my purposes since, like you, I always have separate TEI document per person anyway). I do support your view that allowing <listRelation> inside <person> without using rather confusing 'workarounds' would make perfect sense. One side of the relationship would be thus always implicit by the virtue of element nesting and seems more intuitive than a big bag of mixed relationship descriptions.


I would be interested in hearing other views on the subject!

Best,

Magdalena

On 26 September 2017 at 17:46, Antonio Rojas Castro <[hidden email]> wrote:

​Dear List,

We are currently encoding prosopograhic descriptions and we ​are very interested in representing relations between people and with publications. Here is an example:

<person xmlns="http://www.tei-c.org/ns/1.0" xmlns:xd="http://www.oxygenxml.com/ns/doc/xsl" xml:id="person_00047" role="actor">
   <persName>Barthès de Marmorières, Antoine (1736-1811)</persName>
   <sex value="M"/>
   <socecStatus>Baron</socecStatus>
   <birth>
      <date when="1736"/>
      <placeName ref="place_01022"/>
   </birth>
   <death>
      <date when="1811-08-03"/>
      <placeName ref="place_00432"/>
   </death>
   <occupation type="primary">Militär</occupation>
   <occupation type="other">Schriftsteller</occupation>
   <occupation type="other">Diplomat</occupation>
   <affiliation>
      <ref target="org_00258"/>
      <date when="1763"/>
   </affiliation>
   <bibl>
      <listRelation>
         <relation name="vater" ref="person_01501"/>
         <relation name="bruder" ref="person_00048"/>
         <relation name="freund" ref="person_01241">
            <desc>A. war Sekretär vor 1789 (unter "Comte d'Artois")</desc>
         </relation>
      </listRelation>
   </bibl>
   <listBibl>
      <bibl>
         <relatedItem>
            <ref target="publication_03151">Die Blütezeit der Oekonomischen Gesellschaft in Bern 1759-1766</ref>
         </relatedItem>
      </bibl>
   </listBibl>
</person>

At the moment, <listRelation> can be a child of <listPerson> but not a child of <person>. As you can see in the example, we are not interested in creating a list of people but to describe one person, use a <relation> element to store the name of the relation and provide a reference that points to another person.

In order to this we are nesting <listRelation> within a <bibl> element. However, we are not satisfied with this workaround and we are wondering why <listRelation> cannot be a child of <persons> as <listBibl>. Otherwise, is there any alternative that we may have overlooked?

Thanks in advance.

--
​Antonio Rojas Castro
Postdoctoral Researcher, Cologne Center for eHumanities
Communication coordinator, EADH



Reply | Threaded
Open this post in threaded view
|

Re: ListRelation as a child of person?

Paterson, Duncan
Dear all, 

I am in the same situation and have introduced note/@type=“relation” to collect listRelations as (grand-)child of person. Which seems to be more fitting then bibl, but not by much. 

On first sight, a sibling listRelation seems easier to maintain and to prevent duplicates. However, in my experience with large prosopographies (300K person) this is not the case. Having listRelation as a possible child much better matches the way that editors actually discover relations, I would greatly welcome a chance to the specs in this regard. 

Greetings
Duncan
 

P.S: There is already a tickets talking about listRelation here https://github.com/TEIC/TEI/issues/567



On 27. Sep 2017, at 10:49, Magdalena Turska <[hidden email]> wrote:

Dear Antonio,

faced with a similar task I've used the <listRelation> element placed as a sibling of <person>.

<listPerson>
  <person>
   ...
  </person>
  <listRelation>
      <relation name="child" passive="P4f60049a-e123-44e8-8489-502b483baff4" subtype="natural" type="family" cert="high"/>
  </listRelation>
 </listPerson>

Which is actually invalid without explicitly specifying @active side of relationship (but okay for my purposes since, like you, I always have separate TEI document per person anyway). I do support your view that allowing <listRelation> inside <person> without using rather confusing 'workarounds' would make perfect sense. One side of the relationship would be thus always implicit by the virtue of element nesting and seems more intuitive than a big bag of mixed relationship descriptions.


I would be interested in hearing other views on the subject!

Best,

Magdalena

On 26 September 2017 at 17:46, Antonio Rojas Castro <[hidden email]> wrote:

​Dear List,

We are currently encoding prosopograhic descriptions and we ​are very interested in representing relations between people and with publications. Here is an example:

<person xmlns="http://www.tei-c.org/ns/1.0" xmlns:xd="http://www.oxygenxml.com/ns/doc/xsl" xml:id="person_00047" role="actor">
   <persName>Barthès de Marmorières, Antoine (1736-1811)</persName>
   <sex value="M"/>
   <socecStatus>Baron</socecStatus>
   <birth>
      <date when="1736"/>
      <placeName ref="place_01022"/>
   </birth>
   <death>
      <date when="1811-08-03"/>
      <placeName ref="place_00432"/>
   </death>
   <occupation type="primary">Militär</occupation>
   <occupation type="other">Schriftsteller</occupation>
   <occupation type="other">Diplomat</occupation>
   <affiliation>
      <ref target="org_00258"/>
      <date when="1763"/>
   </affiliation>
   <bibl>
      <listRelation>
         <relation name="vater" ref="person_01501"/>
         <relation name="bruder" ref="person_00048"/>
         <relation name="freund" ref="person_01241">
            <desc>A. war Sekretär vor 1789 (unter "Comte d'Artois")</desc>
         </relation>
      </listRelation>
   </bibl>
   <listBibl>
      <bibl>
         <relatedItem>
            <ref target="publication_03151">Die Blütezeit der Oekonomischen Gesellschaft in Bern 1759-1766</ref>
         </relatedItem>
      </bibl>
   </listBibl>
</person>

At the moment, <listRelation> can be a child of <listPerson> but not a child of <person>. As you can see in the example, we are not interested in creating a list of people but to describe one person, use a <relation> element to store the name of the relation and provide a reference that points to another person.

In order to this we are nesting <listRelation> within a <bibl> element. However, we are not satisfied with this workaround and we are wondering why <listRelation> cannot be a child of <persons> as <listBibl>. Otherwise, is there any alternative that we may have overlooked?

Thanks in advance.

--
​Antonio Rojas Castro
Postdoctoral Researcher, Cologne Center for eHumanities
Communication coordinator, EADH




Reply | Threaded
Open this post in threaded view
|

Re: ListRelation as a child of person?

ANTONIO ROJAS CASTRO
Dear all,

I thank you Magdalena and Duncan for your messages. 

I am glad to know that we are not alone with this issue. 

I agree that note/@type=“relation” is more elegant than my solution, so I will implement it. However, I hope the Council will considerer our needs and proposal. 

We are creating comprehensive prosopographic descriptions of many people and we are already using a lot of notes for information that is not covered by the TEI yet. I am very reluctant to use one more note. That is why I would prefer that <listRelation> was a direct child of <person>. 

In any case, I thank you a lot for your feedback.

Best,

-- 
Dr. Antonio Rojas Castro
Researcher, Cologne Center for eHumanities
Communication coordinator, EADH

El 27 de septiembre de 2017 a las 12:10:05, Paterson, Duncan ([hidden email]) escribió:

Dear all, 

I am in the same situation and have introduced note/@type=“relation” to collect listRelations as (grand-)child of person. Which seems to be more fitting then bibl, but not by much. 

On first sight, a sibling listRelation seems easier to maintain and to prevent duplicates. However, in my experience with large prosopographies (300K person) this is not the case. Having listRelation as a possible child much better matches the way that editors actually discover relations, I would greatly welcome a chance to the specs in this regard. 

Greetings
Duncan
 

P.S: There is already a tickets talking about listRelation here https://github.com/TEIC/TEI/issues/567



On 27. Sep 2017, at 10:49, Magdalena Turska <[hidden email]> wrote:

Dear Antonio,

faced with a similar task I've used the <listRelation> element placed as a sibling of <person>.

<listPerson>
  <person>
   ...
  </person>
  <listRelation>
      <relation name="child" passive="P4f60049a-e123-44e8-8489-502b483baff4" subtype="natural" type="family" cert="high"/>
  </listRelation>
 </listPerson>

Which is actually invalid without explicitly specifying @active side of relationship (but okay for my purposes since, like you, I always have separate TEI document per person anyway). I do support your view that allowing <listRelation> inside <person> without using rather confusing 'workarounds' would make perfect sense. One side of the relationship would be thus always implicit by the virtue of element nesting and seems more intuitive than a big bag of mixed relationship descriptions.


I would be interested in hearing other views on the subject!

Best,

Magdalena

On 26 September 2017 at 17:46, Antonio Rojas Castro <[hidden email]> wrote:

​Dear List,

We are currently encoding prosopograhic descriptions and we ​are very interested in representing relations between people and with publications. Here is an example:

<person xmlns="http://www.tei-c.org/ns/1.0" xmlns:xd="http://www.oxygenxml.com/ns/doc/xsl" xml:id="person_00047" role="actor">
   <persName>Barthès de Marmorières, Antoine (1736-1811)</persName>
   <sex value="M"/>
   <socecStatus>Baron</socecStatus>
   <birth>
      <date when="1736"/>
      <placeName ref="place_01022"/>
   </birth>
   <death>
      <date when="1811-08-03"/>
      <placeName ref="place_00432"/>
   </death>
   <occupation type="primary">Militär</occupation>
   <occupation type="other">Schriftsteller</occupation>
   <occupation type="other">Diplomat</occupation>
   <affiliation>
      <ref target="org_00258"/>
      <date when="1763"/>
   </affiliation>
   <bibl>
      <listRelation>
         <relation name="vater" ref="person_01501"/>
         <relation name="bruder" ref="person_00048"/>
         <relation name="freund" ref="person_01241">
            <desc>A. war Sekretär vor 1789 (unter "Comte d'Artois")</desc>
         </relation>
      </listRelation>
   </bibl>
   <listBibl>
      <bibl>
         <relatedItem>
            <ref target="publication_03151">Die Blütezeit der Oekonomischen Gesellschaft in Bern 1759-1766</ref>
         </relatedItem>
      </bibl>
   </listBibl>
</person>

At the moment, <listRelation> can be a child of <listPerson> but not a child of <person>. As you can see in the example, we are not interested in creating a list of people but to describe one person, use a <relation> element to store the name of the relation and provide a reference that points to another person.

In order to this we are nesting <listRelation> within a <bibl> element. However, we are not satisfied with this workaround and we are wondering why <listRelation> cannot be a child of <persons> as <listBibl>. Otherwise, is there any alternative that we may have overlooked?

Thanks in advance.

--
​Antonio Rojas Castro
Postdoctoral Researcher, Cologne Center for eHumanities
Communication coordinator, EADH