Dear all
I am a little late with my homework about families in FRAD complex. In
connection wiith that the parents problem poped up again.
The WISSKI (wisski.eu) group encountered the following problem with a
large German authority file "Personennamendatei", see the information
from Georg Hohmann at the end. The problem is: The Personennamendatei
does not neccessarily give information of the gender of parent, just
station that x is parent of y. (I assume that this due to the fact that
the gender can in most(?) cases be deducted form the name). In CRM one
can reject this as bad practice. However, this attitude may be
considered slightly arrogant at least by some.
In CRM parenthood is modelled very biologically: P96 by mother & P97
from father. In the scopenotes of both the biological aspect is
stressed. (I personally have the opinion that the word biological should
be deleted form the scopenote of P97 from father, since this is to put a
somewhat Victorian view on the matter).
IN CRM it is said that all kind of family relations should be modelled
by the use of E74 Group. For example a married couple is modelled as a
E74 Group. The membership relation is typed: "The married couple Queen
Elisabeth and Prince Phillip (E74) has current or former member Prince
Phillip (E21) with P107.1 kind of member husband (E55 Type)".
The group model (E74 Group, P107 has current or former member, P107.1
kind of member, is completely general and very powerful and can be used
to model ALL relationships between actor. The only limitation is in fact
that the specific formation event for a group is a (E66 Formation) is a
subclass of E7 Activity and requires an agens, someone performing the
formation.
With the above tool box:
1) we can model parenthood (father mother child) by the use of P96 by
mother & P97 from father only when the gender of the parent is known.
2) If the gender of the parent is not known we have to introduce a group
say of E55 type 'parenthood' to link the child to the parent. The child
will be connected via P107 has current or former member, P107.1 kind of
member (child) and the parent P107 has current or former member, P107.1
kind of member (parent).
In my opinion this is not according to the idea of CRM as a model for
data integration based on refinement. That is, less information map to a
superclass/superproperty, more information map to a subclass/suproperty.
The issues are:
Add a property "by parent" from E21 Person to E67 Birth. This property
is a superproperty of both P96 by mother & P97 from father but not a
subproperty of anything.
Remove the word biological from the scope notes of P97 from father.
Regards,
Christian-Emil
It's the "Personennamendatei" (Name Authority File, PND) of the
Deutsche Nationalbibliothek (German National Library, DNB
(http://www.d-nb.de/eng/standardisierung/normdateien/pnd.htm). A huge
part of the authority file can be downloaded as RDF/XML from the
Linked Data Services of the DNB at https://wiki.d-nb.de/display/LDS/ .
Additionaly, the RDF-File of each person can be accessed via the OPAC
of the DNB (e.g http://d-nb.info/gnd/100019552/about/rdf).
The PND/RDF uses a relationship-vocabulary
(http://vocab.org/relationship/.html) to express relationships between
persons. This vocabulary offers the relation "parentOf" to express
that someone is a parent of somebody without a gender specific notion.
If you know the gender of the parent, you can easily model the
relation between the parent and the child using CRMs "P96 by mother
(gave birth)" or "P97 from father (was father for)". But if you don't
know the gender of the parent, you are not able to model the
"parentOf" relationship using CRM. The same holds for the "childOf"
relationship.
Example:
http://d-nb.info/gnd/100031307/about/rdf
This dataset about "Beckman, Christian" bears no gender information,
but the relation "parentOf". So one cannot say (automatically) if it
is the father or the mother of "http://d-nb.info/gnd/100031358/";.
