search

usaybia / usaybia-data

Data for interreligious interaction in Near Eastern texts
MIT License
2 stars 2 forks source link

Multiple dated relationships (people, places, objects) in event #58

Closed nathangibson closed 3 years ago

nathangibson commented 4 years ago

@dlschwartz @torabik @lunadine We're thinking about how to best model complex exchanges involving non-persons as intermediaries, e.g., Person 1 teaches Book 1 to person 2, or person 1 sends book 1 from place 1 to person 2 at place 2, etc.

Background (clear as mud)

The motivation behind this is network analysis. Everything in the network has to be a property of either a node or an edge. And we expect to be using primarily monopartite networks (all nodes are the same type of thing--all persons, or all places, etc.), since these are better for analysis. But in some cases the nodes will be people, in other cases places or manuscripts/texts. Other things then get flattened in to edge properties (e.g., these two people are connected via a place as an edge property). Our factoid encoding should allow us the flexibility to machine things variously into node properties or edge properties.

For complex events/relations with indirect objects, there are a few problems with what is currently allowed. Relation factoids give us exactly the format we need for network analysis, with clearly defined nodes (person URIs) and edges (relation refs). But then how do we include indirect objects, places, etc.? And how do we include multiple types of relationships for the same event (e.g., Person 1 sends person 2 to person 3)? Also relations don't have as robust date handling as events.

If we use an event factoid, we have the problem of showing what the exact relationship is between the people, places, books, etc. mentioned since we don't have the nice relation/@ref vocab.

It isn't a problem to grab multiple factoids to use as node properties when these are stable traits, e.g., name variants, gender, etc. But if multiple factoids are all part of the same event and are different factoid types (such as relation), we need something to connect them.

We discussed perhaps putting indirect objects in relation/@ana but this doesn't fully solve the problem.

I have two suggestions, both of which involve putting relations inside event factoids.

Main Suggestion: Allow listRelation inside event/desc

This would allow multiple types of relations among people, indirect objects, places, etc. that appear in a single event to be machined into a network.

Example (note: I'm not sure if this is the right way to go about naming relation refs)

<div 
            type="factoid" subtype="event" 
            xml:id="factoid-1" 
            resp="#ngibson">
            <idno type="URI">https://usaybia.net/factoid/14-25-1</idno>
            <listEvent>
               <event>
                  <desc>
                     In 
                     <choice>
                        <reg><date when="1053" calendar="Gregorian">1053</date></reg>
                        <orig><date when-custom="445" datingMethod="Hijri">445</date></orig>
                     </choice>,
                     <persName ref="https://usaybia.net/person/1">Person 1</persName>
                     sent 
                     <persName ref="https://usaybia.net/person/2">Person 2</persName>
                     with 
                     <objectName ref="https://usaybia.net/manuscript/1">a manuscript</objectName> 
                     from 
                     <placeName ref="https://usaybia.net/place/1">Place 1</placeName>
                     to 
                     <persName ref="https://usaybia.net/person/3">Person 3</persName> 
                     at 
                     <placeName ref="https://usaybia.net/place/2">Place 2</placeName>.
                     <listRelation>
                        <relation ref="syriaca:senderOfPersonWithObjectFromPlace" 
                           active="https://usaybia.net/person/1" 
                           passive="https://usaybia.net/person/2"/>
                        <relation ref="syriaca:senderOfPersonWithObjectFromPlace" 
                           active="https://usaybia.net/person/1" 
                           passive="https://usaybia.net/manuscript/1"/>
                        <relation ref="syriaca:senderOfPersonWithObjectFromPlace" 
                           active="https://usaybia.net/person/1" 
                           passive="https://usaybia.net/place/1"/>
                        <relation ref="syriaca:receiverOfObjectFromPersonAtPlace" 
                           active="https://usaybia.net/person/3" 
                           passive="https://usaybia.net/person/2"/>
                        <relation ref="syriaca:receiverOfObjectFromPersonAtPlace" 
                           active="https://usaybia.net/person/3" 
                           passive="https://usaybia.net/manuscript/1"/>
                        <relation ref="syriaca:receiverOfObjectFromPersonAtPlace" 
                           active="https://usaybia.net/person/3" 
                           passive="https://usaybia.net/place/2"/>
                     </listRelation>
                  </desc>
               </event>
            </listEvent>
            <bibl type="urn">
               <ptr target="urn:cts:arabicLit:0668IbnAbiUsaibia.Tabaqatalatibba.lhom-ed-ara1:14.25"/>
               <citedRange unit="part">1</citedRange>
            </bibl>   
         </div>

Here the network could be represented without a problem as person 1 > person 2 > person 3 with places and manuscript as edge attributes. Or it could be place 1 > place 2 or even (combined with other factoids) a network of manuscripts. But fundamentally this remains one event.

There is one additional issue here: What happens when an event involves multiple dates, and the relations should each be connected to a particular one of those dates, as with different dates for when something was sent and when it was received?

Option 1: Use @when|@notBefore|@notAfter|@from|@to on relations

Dating attributes have a little less flexibility than the date element, but I think overall this is a good option. The encoder would have to express the dates in a way that works in attributes, but there's still the human-readable rich description in the date in the desc if needed.

<listEvent>
               <event>
                  <desc>
                     In 
                     <choice>
                        <reg><date when="1053" calendar="Gregorian">1053</date></reg>
                        <orig><date when-custom="445" datingMethod="Hijri">445</date></orig>
                     </choice>,
                     <persName ref="https://usaybia.net/person/1">Person 1</persName>
                     sent 
                     <persName ref="https://usaybia.net/person/2">Person 2</persName>
                     with 
                     <objectName ref="https://usaybia.net/manuscript/1">a manuscript</objectName> 
                     from 
                     <placeName ref="https://usaybia.net/place/1">Place 1</placeName>
                     to 
                     <persName ref="https://usaybia.net/person/3">Person 3</persName>, 
                     arriving in 
                     <choice>
                        <reg><date when="1054" calendar="Gregorian">1054</date></reg>
                        <orig><date when-custom="446" datingMethod="Hijri">446</date></orig>
                     </choice>
                     at 
                     <placeName ref="https://usaybia.net/place/2">Place 2</placeName>.
                     <listRelation>
                        <relation ref="syriaca:senderOfPersonWithObjectFromPlace" 
                           when="1053"
                           active="https://usaybia.net/person/1" 
                           passive="https://usaybia.net/person/2"/>
                        <relation ref="syriaca:senderOfPersonWithObjectFromPlace" 
                           when="1053"
                           active="https://usaybia.net/person/1" 
                           passive="https://usaybia.net/manuscript/1"/>
                        <relation ref="syriaca:senderOfPersonWithObjectFromPlace" 
                           when="1053"
                           active="https://usaybia.net/person/1" 
                           passive="https://usaybia.net/place/1"/>
                        <relation ref="syriaca:receiverOfObjectFromPersonAtPlace" 
                           when="1054"
                           active="https://usaybia.net/person/3" 
                           passive="https://usaybia.net/person/2"/>
                        <relation ref="syriaca:receiverOfObjectFromPersonAtPlace" 
                           when="1054"
                           active="https://usaybia.net/person/3" 
                           passive="https://usaybia.net/manuscript/1"/>
                        <relation ref="syriaca:receiverOfObjectFromPersonAtPlace" 
                           when="1054"
                           active="https://usaybia.net/person/3" 
                           passive="https://usaybia.net/place/2"/>
                     </listRelation>
                  </desc>
               </event>
            </listEvent>

Option 2: Use @datingPoint on relations

This would simply point to the date elements in the event desc (see https://www.tei-c.org/release/doc/tei-p5-doc/de/html/ref-att.datable.custom.html#tei_att.datingPoint)

<listEvent>
               <event>
                  <desc>
                     In 
                     <choice xml:id="date-1-1">
                        <reg><date when="1053" calendar="Gregorian">1053</date></reg>
                        <orig><date when-custom="445" datingMethod="Hijri">445</date></orig>
                     </choice>,
                     <persName ref="https://usaybia.net/person/1">Person 1</persName>
                     sent 
                     <persName ref="https://usaybia.net/person/2">Person 2</persName>
                     with 
                     <objectName ref="https://usaybia.net/manuscript/1">a manuscript</objectName> 
                     from 
                     <placeName ref="https://usaybia.net/place/1">Place 1</placeName>
                     to 
                     <persName ref="https://usaybia.net/person/3">Person 3</persName>, 
                     arriving in 
                     <choice xml:id="date-1-2">
                        <reg><date when="1054" calendar="Gregorian">1054</date></reg>
                        <orig><date when-custom="446" datingMethod="Hijri">446</date></orig>
                     </choice>
                     at 
                     <placeName ref="https://usaybia.net/place/2">Place 2</placeName>.
                     <listRelation>
                        <relation ref="syriaca:senderOfPersonWithObjectFromPlace" 
                           datingPoint="#date-1-1"
                           active="https://usaybia.net/person/1" 
                           passive="https://usaybia.net/person/2"/>
                        <relation ref="syriaca:senderOfPersonWithObjectFromPlace" 
                           datingPoint="#date-1-1"
                           active="https://usaybia.net/person/1" 
                           passive="https://usaybia.net/manuscript/1"/>
                        <relation ref="syriaca:senderOfPersonWithObjectFromPlace" 
                           datingPoint="#date-1-1"
                           active="https://usaybia.net/person/1" 
                           passive="https://usaybia.net/place/1"/>
                        <relation ref="syriaca:receiverOfObjectFromPersonAtPlace" 
                           datingPoint="#date-1-2"
                           active="https://usaybia.net/person/3" 
                           passive="https://usaybia.net/person/2"/>
                        <relation ref="syriaca:receiverOfObjectFromPersonAtPlace" 
                           datingPoint="#date-1-2"
                           active="https://usaybia.net/person/3" 
                           passive="https://usaybia.net/manuscript/1"/>
                        <relation ref="syriaca:receiverOfObjectFromPersonAtPlace" 
                           datingPoint="#date-1-2"
                           active="https://usaybia.net/person/3" 
                           passive="https://usaybia.net/place/2"/>
                     </listRelation>
                  </desc>
               </event>
            </listEvent>

Option 3: Split event into two factoids and relate them using listEvent/listRelation

Similar to the way events can already have a listRelation inside a listEvent to relate them to other events, an event with multiple dates could be split into multiple event factoids which are related. Relations relevant to each date/sub-event would be contained in their respective factoids. E.g., 

<listRelation>
                  <relation name="syriaca:precedes" 
                     active="https://usaybia.net/factoid/1"
                     passive="https://usaybia.net/factoid/2"/>
               </listRelation>

Option 4: Put multiple <event> elements inside a single div/listEvent

Each of these sub-events would contain its own dates and relations. E.g., 

<div>
            <listEvent>
                     <event xml:id="event1">...</event>
                     <event xml:id="event2">...</event>
                  </listEvent>
         </div>

What do you think?

Sorry for the long issue. We can discuss next time we meet.

nathangibson commented 4 years ago

Examples of all the above options here: https://github.com/usaybia/usaybia-data/blob/factoid-relations-experiment/data/factoids/tei/factoid-relations-experiment.xml

nathangibson commented 4 years ago

For notBefore and notAfter on relation/@from and relation/@to a precision element may be the solution, as with state, see https://github.com/srophe/srophe-app-data/wiki/TEI-Encoding-Manual-for-The-Syriac-Gazetteer#duration-of-place-using-state-typeexistence-optional

<state type="existence" from="0270" to="0694">
<precision match="@from" notAfter="0270"/>
<precision match="@to" notBefore="0694" notAfter="1200"/>
</state>
nathangibson commented 4 years ago

See also https://github.com/srophe/srophe-app-data/issues/884

nathangibson commented 4 years ago

For notBefore and notAfter on relation/@from and relation/@to a precision element may be the solution, as with state, see https://github.com/srophe/srophe-app-data/wiki/TEI-Encoding-Manual-for-The-Syriac-Gazetteer#duration-of-place-using-state-typeexistence-optional

<state type="existence" from="0270" to="0694">
<precision match="@from" notAfter="0270"/>
<precision match="@to" notBefore="0694" notAfter="1200"/>
</state>

@dlschwartz Considering this, you can ignore the various "options" in the original post and instead just focus on the main suggestion.

dlschwartz commented 4 years ago

@nathangibson sorry this one slipped by me. There's a lot to think about here, even with just the main suggestion. I think I like the idea of including <relation> elements in event factoids. It's on my to-do list to go through all event factoids currently encoded in SPEAR and put them, whenever possible, into relation factoids. It would be easiest to do that inside the event factoid itself.

A few thoughts:

I'm sure I'll have additional thoughts. I'd like to hear your responses as well.

nathangibson commented 4 years ago

@dlschwartz Thanks for this thorough response!

  • From the perspective of quads, I think this works rather well. As triples, you can't keep the individual relationships as part of the same graph/factoid/event. When we can use quads that's great. But in many instances of sharing RDF, only the triples would be useful to collaborators. You can still share them, but they wouldn't stay connected. They also wouldn't stay connected to the dates. This is just a limitation of triples.

I don't claim to understand quads. But from my pragmatic perspective of trying to model something as a TEI factoid and then get relevant data into a network, I'm operating on the assumption that the TEI will often have dimensions I'll have to flatten when I transform it. Thus I may have several different transformations I use for different purposes -- e.g., for networks of persons, networks of books, networks of places. I think it's cool that factoids can be fully-orbed, and I don't have a problem with the idea that derivative formats are not going to have the full dimensionality.

Perhaps it's a comparable situation for RDF. As much as it's intended to model the entire universe ;-) it might be that the compromises are not really compromises for specific use cases.

  • I'm slightly concerned that this actually moves us away from CIDOC. Have you thought about CIDOC? I'm still working to get my head around it but I know it takes the event as the primary unit of analysis. I actually don't know how compatible this is with the CIDOC ontology. It might be good to understand that better before committing one way or the other.

I have no idea about CIDOC. It's a black box for me. But perhaps I should try to understand it more. For now, I'm happy to leave that to your judgement, whether this would be a large impediment to the direction you want to go with that.

  • Related to the last point, I'm trying to figure out what this does to the nature of this factoid prosopography. Does it prioritize relationships but making the more-machine-readable portion of events the relationship portion? Or, does it prioritize events by removing stand-alone relation factoids and putting them inside events. I'm not sure this matters, I just want to put it down here because I think it's worth thinking through the implications a bit.

I guess I don't see it as prioritizing either one. I just see it as parallel ways of encoding something complicated, but one is more machine-readable and the other is more human-readable. The event desc listRelation and the event desc text each capture different aspects of the same event.

dlschwartz commented 4 years ago

@nathangibson just finished my first day of teaching, it's a wild ride.

Re: quads, the issue there really has to do with the ability of the RDF to stay connected to the factoid. It's easy to make assertions about person data with a triple but without a quad you can't maintain a connection between the triple and the source of the triple. You probably don't lose much by using triples given that Usaybia is encoding one source (that's correct isn't it?). However, in SPEAR we very well may have things like contradictory triples, especially given the fact that SPEAR encodes date from multiple source texts. The fourth element of the quad is the graph that contains the triple. For SPEAR, this is the factoid. The bibl URI, etc. connects the triples in the factoid to the factoid so all the data is then sourced. I might be missing something, but I believe my read on this is correct. For you to produce a graph of triples about your source will likely work fine. I am pretty sure SPEAR needs something more though.

Re: CIDOC, there is a lot of talk in the Ontology world of using only one ontology. I'm not sure I fully understand the implications of the piecemeal thing SPEAR has going, via the taxonomy. However, CIDOC would be one of the main contenders for a unified ontology for factoids. It's a beast though and at the moment I lean in the direction of internal specificity and the ability to link externally to standards.

Still mulling this a bit but I'm hoping to finish paper revisions very shortly. Thanks for thinking with me on this!

dlschwartz commented 4 years ago

@nathangibson going back to the original Main Suggestion, I'm trying to think through the placement of the <relation> element inside of the event factoid. Your suggestion offers way to contain <relation> inside of <event>, which makes sense. For some reason, I'm not sure what I think about having it inside <listRelation> inside <desc> though. Maybe it's that the parent <desc> actually offers a description of both the <event> and the <relation>.

Maybe I'm wrong and the best way to think of this is that the <relation> constitutes part of the description of the event. Can you sell me on this?

The other options allowed by the TEI are pretty limited. It could go inside <listEvent> as a sibling of <event> but that's a bit odd and doesn't sort out the issues mentioned above. 

    <div>
        <listEvent>
            <event>...</event>
            <relation>...</relation>
        </listEvent>
    </div>

I keep coming back to the difference between a relationship stated in a text (x was the parent of y) and a relationship constituted by an event described in a text (x gave birth to y). How do you best encode a relationship constituted by an event?

The following might come close to what's needed by making the description of the relationship an event (but unfortunately not an event factoid). I like that it prioritizes the more machine actionable <relation> over the more prose oriented <event>. 

<div>
   <listRelation>
      <relation>
         <desc>
            <listEvent>
               <event>
                  <desc>...</desc>
               </event>
            </listEvent>
         </desc>
      </relation>
   </listRelation>
</div>

Sorry, I'm really just spit balling here. Not sure whether this helps of further muddies things. Let me know if it helps at all. I'll keep thinking. Thanks.

nathangibson commented 4 years ago

@dlschwartz I'm actually pretty agnostic about whether relation should go inside event/desc/listRelation or whether event should go inside relation/desc/listEvent. Really what I'm going for is an "interaction" factoid, an event that connects people or things. I would tend to see it more fundamentally as an event, because of it referring to something that happens at a point in time, whereas a relationship (as opposed to a single interaction) often has less defined temporal parameters. But I'm comfortable with it being a relation factoid containing an event if you think that works better conceptually or practically.

In the case of relation inside event/desc/listRelation I would see it as a single event being described both in prose and by machine-readable (sometimes dateable) connections between people/things.

lunadine commented 4 years ago

Dear Daniel and Nathan, thanks so much for these insights! There is not much I can contribute, but I was following your discussion. If I take a look at POMS (even though they do not use TEI) it seems to me that they also understand such instances as an event connecting people rather than a relationship between these persons. I think they call it transactions (at least I found "type: transaction" when looking for factoids). Here is an example of one transaction that connects three individuals to the pope: https://www.poms.ac.uk/record/factoid/43365/ On the other hand I was not able to find relationship factoids between the pope and these appointees on the webpage. I guess especially in such instances it would be conveniant if it was possible to treat it as a somewhat subordinate relationship in an event. I hope this makes sense (although it probaby does not even make a difference when we display the relationships in a network?). Thinking about your comment " parent actually offers a description of both the 'event' and the 'relation'", I see the problem, beeing ignorant and creative... can we not make use of 'correspDesc', does this help in any way? The TEI webpage says it is relating to events of a given communicative act and gives flexible opportunities to include all the information about associated people, dates, and places

lunadine commented 4 years ago

ah this would only allow for events linked to correspondence of course, ok forget about it ...

dlschwartz commented 4 years ago

@nathangibson @lunadine thanks to you both. I think you're right that this is an event that creates a relationship and ought to maintain that emphasis in the encoding. I think we should implement this.

The one question I have is about the display of the data in HTML. Winona expressed a preference for putting a <desc> inside <relation> that will display in the HTML for the factoid page. It would be redundant to have //event/desc/listRelation/relation/desc in which the text nodes of the two <desc> elements contained the same information. Hopefully it will work well enough to test for a child <desc> of <relation> and if there isn't one to display the text node of the ancestor <desc>. I should touch base with Winona before committing to this.

dlschwartz commented 4 years ago

But maybe the question for Winona doesn't matter. These won't be relationship factoids, they will be relationships in event factoids. We can display those relationships on event factoid pages the way we currently do on the person aggregation pages. For projects concerned to maintain a connection between the relationship triple and the event factoid, we'll use quads to maintain that connection.

dlschwartz commented 4 years ago

@nathangibson and @lunadine, see the changes in the commit above to Syriaca.org draft-data (not yet implemented in srophe-app-data or in the schema in srophe-eXist-app).

<listRelation> for relationships between event factoids appears after <bibl>, giving it a position analogous to a discursive <note>. See, https://github.com/srophe/draft-data/blob/master/data/spear/SPEAR_updates/tei/8559.xml#L8674 (might take a little while to load).

All <relation> elements require a @type attribute with either "person" or "event". See, https://github.com/srophe/draft-data/blob/master/data/spear/SPEAR_updates/tei/3045.xml#L140

Event factoids can take an optional <listRelation> inside <desc>. See, https://github.com/srophe/draft-data/blob/master/data/spear/SPEAR_updates/tei/3045.xml#L196

Multiple values are allowed, see, https://github.com/srophe/draft-data/blob/master/data/spear/SPEAR_updates/tei/3045.xml#L217

I've also gone ahead and made the change from <div> to <ab>. This means you can plug a SPEAR factoid into a TEI P5 All document and it validates!

Let me know what you think of all this. I'm pretty happy with these changes. Thank you for coming up with an idea for how to turn (many?, most?) events into machine actionable data!

Let me know if you want to meet to discuss any of this. Thanks Nathan and Nadine!

nathangibson commented 4 years ago

@dlschwartz We were just chatting (@lunadine and I) about how to model a book sale in this new format. There's been a lot of discussion back and forth, so let us know if we missed something:

                <listEvent>
                    <event
                    ana="http://syriaca.org/keyword/trade">
                        <desc> 
                            In 
                            <choice>
                                <reg><date when="0850" 
                                    calendar="Gregorian">850</date></reg>
                                <orig><date when="0225" 
                                    calendar="Hijri">225</date></orig>
                            </choice>, 
                            <persName ref="https://usaybia.net/person/1">
                                Person 1
                            </persName>
                            sold 
                            <bibl ref="https://usaybia.net/work/1">Work 1</bibl>
                            to 
                            <persName ref="https://usaybia.net/person/2">
                                Person 2
                            </persName>
                            at <placeName
                                ref="https://usaybia.net/place/1">
                                Place 1
                            </placeName>.
                            <listRelation>
                                <relation type="person" 
                                    ref="http://syriaca.org/keyword/sold-work-to" 
                                    active="https://usaybia.net/person/1" 
                                    passive="https://usaybia.net/person/2 https://usaybia.net/work/1"
                                    when="0850"/>
                            </listRelation>
                        </desc>
                    </event>

Also a couple questions (sorry if we already discussed and I forgot):

  1. Is it okay to have two types of entities in the @passive if the roles are clear, as above, or do we need two different relations here, one for the person-person and one for the person-work?
  2. What should we use for relation @type in a case like this?
  3. We think it's adequate to just have the tagged place in the body of event/desc and not put an additional relation for place. Sound okay?
dlschwartz commented 4 years ago

@nathangibson @lunadine this is an interesting set of problems.

1

There are a couple of competing priorities here. From the perspective of the XML, I don't think I like the multiple value types on @passive. You have to understand the semantic value of the URI in order to parse the meaning. In a way, that's fine but I don't think it's ideal. If you think this through from the perspective of the RDF, I suppose you can parse this XML to get what you want. Have you thought about how will you create triples (or quads) out of the two passive values. I think you can do it but whatever you decide you'll want to have that solution up front.

2

I guess what you're really after here is a person/person/object relationship. I think the biggest challenge is that you want to include the object. In a way, the object really doesn't matter. You can easily capture the relationship created by a commercial exchange without specifying the object sold. I understand why you want that though. Since this is a personal relationship at its core, I think @type="person" is fine. There are two reasons you might want something else though. Will you want to process this relationship different from other personal relationships (visualize it differently or serialize it differently)? Will you want to write Schematron rules into your schema that will require content in this type of <relation> element that differs from other types of <relation> elements? If either of these things is the case, I recommend that you create your own type.

A bigger problem here to my mind is the use of the work URI. Syriaca.org uses the work URI for the conceptual entity of a work and not for an object. In the <desc> you can make a slight change to say that "person x sold a copy of work y." That would cover you in that context. However, in the <relation> element I think you need an mss URI. That opens a whole can of worms though. Have you wrestled with this issue?

3

Here I think it's all about serialization. If you can get the RDF you want out of this arrangement, you're good to go. I'd work backward on this.

nathangibson commented 3 years ago

I think we've pretty much decided how to go on this. See JTEI prepub. Need to document and incorporate into #65 . Reopen if there are further questions.