cyocum / irish-gen

Traditional Irish genealogies represented as TRiG RDF named graphs.
33 stars 4 forks source link

Conflicts Between Stated and Actual Numbers of Offspring #62

Closed Eystein-Thanisch closed 8 years ago

Eystein-Thanisch commented 8 years ago

As I am sure you have noticed, the genealogies sometimes give the number of sons a person has as well as listing their names.

e.g. (Sil_Birn.ttl) "Cóic mc Fhindchada mc Dega .i. Oengus. Mc Cuilind. Dúnlang a quo .h. Dega Draignech. Eichen. Barrfhind."

Occasionally, this ennumeration is contradicted, either by the number of sons then listed or by the addition of extra sons elsewhere in the genealogies. In relation to the example just given, we later encounter "Scellán & Cummin dá mc Dimma m Fhindchada mc Dega."

This kind of discrepency has the potential to reveal important faultlines in the text, which is a key objective of this project. However, at present, we do not seem to have an efficient way of recording that the text put a number on someone's offspring, only that the offspring are listed. Is there any way this could be included?

cyocum commented 8 years ago

I have noticed this and I agree that it does need improvement.

There are a couple of ways to handle this and I will propose one and see what you think.

There is a way of indicating these using "Nested Unlabelled Blank Nodes" (https://www.w3.org/TR/turtle/#unlabeled-bnodes). I use this, for instance, when there are people who are unnamed but exist, which often happens to women. So we could something like:

<#Person> a foaf:Person; foaf:name "Person Name"; rel:parentOf [ a foaf:Person; ].

This would indicate that there is "a person" missing from the enumeration of the children of that person.

Let me know what you think.

Eystein-Thanisch commented 8 years ago

That certainly looks like a useful tool for some situations.

However, the extra person might not always be "missing" from the original enumeration. The original enumeration might be exactly as its author intended it, with the extra person being added by a later redactor/compiler.

If, in the example above, we simply include six people in the database who are "rel:childOf" Findchad, will anyone using the database know that the LL genealogies state that Findchad only has five sons but that the sixth appears elsewhere? Surely all it will present is Findchad's six sons, without any clue as to the suspicious textual situation. Or will using "Nested Unlabelled Blank Nodes" somehow flag up that five sons are listed in one place and the sixth somewhere else?

I still feel we need to find a way of including the text's statements of numbers of offspring, not just the names. Is that at all possible?

cyocum commented 8 years ago

If the person is not missing from the original and can be linked from another file, the answer is to provide the link which is straight forward. If a human is looking at the file, yes, this could be a problem for the human but, as long as the link is provided, the computer will have no trouble linking the extra child to the node.

EDIT:

Having a second thought, we could have a irishRel:numChild property which matches the text. That is also straight forward and not too onerous.

Eystein-Thanisch commented 8 years ago

But we are adding the extra child silently, with no indication of the divergent provenance of the information. The genealogies make two separate statements:

Statement A: "Findchad has five sons, Oengus, Mac Cuilind, Dúnlang, Eichen, and Barrfhind".

Statement B: "Dimma is Findchad's son".

If we simply add all six people as sons of Findchad, we are making Statement C:

Statement C: "Findchad has six sons, Oengus, Mac Cuilind, Dúnlang, Eichen, Barrfhind, and Dimma".

All 'the human' will see is Statement C, which is not directly supported by either statement in the LL genealogies and is arguably contradicted by Statement A. Isn't this quite misleading, as a representation of the text?

This is, of course, the perennial problem with editing: harmonisation obscures variants and contraditions and misrepresents the tradition, while preserving variants and contradictions is an abdication of editorial responsibility and of questionable utility to the user. I just thought that the framework we are using might offer sufficiently greater flexibility to navigate through this problem successfully. As I say, my preferred solution would be to record the genealogies' statement of the number of a person's offspring somehow, if only in an rdfs:comment.

cyocum commented 8 years ago

Having another think about it, what I generally do in these situations is use owl:sameAs. Record statement B in its entirety but create a new node for Findchad which is then marked as owl:sameAs the Findchad in statement A (using uuid if necessary). This keeps the distinction in the text but if someone does a search Dimma will show up as a son Finchad in both instances. In fact, I have done this pretty consistently already.

Does that help?

Eystein-Thanisch commented 8 years ago

That sounds promising. In situations like the above, I too have created a new node for each occurrence of the name. So the user will see each node linked by owl:sameAs as separate but related? That seems to solve the problem and irishRel:numChild would make it even more foolproof (not sure who the fool is, in this instance).

cyocum commented 8 years ago

Yes, basically. But during search operations, they are merged for the purposes of the search so you will never miss out on a node.

If you are happy with the irishRel:numChild and the owl:sameAs as above, I will add the numChild to the ontology and you can close close the issue once I have done that. Is that OK?

Eystein-Thanisch commented 8 years ago

Yup, that's fine. But make sure to state somewhere for future reference that irishRel:numChild relates to the stated number of children, not the number that actually appear. The latter should be apparent from the actual rel:childOf relationships we input. Thanks for this discussion :-)

cyocum commented 8 years ago

I have added the numChild property. Please have a look and let me know what you think.