[rdfweb-dev] Another relationships proposal

Michael Bauser michael at bauser.com
Sat Mar 20 07:58:09 UTC 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Menendez wrote:

> This is some noodling inspired by Ian Davis's work and Michael Bauser's
> comments.
>
> For kinship relations, I suggest this heirarchy of properties:
>
>   kin
>     ancestor
>       parent
>         mother
>         father
>     sibling
>       sister
>       brother
>     descendent
>       child
>         daughter
>         son

You left out the spouse/husband/wife axis.

But anyway, I've actually had a schema for (almost) this arrangement on
my hard drive since Tuesday night. I realized that I had to put the
general parent/sibling/spouse/child classes back in, in case someone
needs placeholders while working with incomplete data. (For example, if
all know know about Fred Smith and Mary Jones is that they're "first
cousins" in English, you can assume they've got a "parent of a parent"
in common, but you would just be guessing about the genders of their
parents or the grandparent.) In the end, I want a kinship schema that
can be used *while* people are figuring out kinship patterns, not just
after they learn the entire family tree.

Of course, I only bothered to read the OWL recommendations on Tuesday
afternoon, so its almost certain I got *something* wrong when I wrote
the schema.

> The sense of these are the same as in the Dublin Core, e.g., { A P B. }
> is read as "B is a/the P of A" (note that N3 actually has a syntax form
> that lets you write { B is P of A. }).
>
> More specifically, the claim { A P B. } means "B is the P of A according
> to A's cultural norms". This means that, for example, { A parent B }
> does not imply { B child A }, because A and B may see things
> differently.
>
> Similarly, kin, ancestor, and descendent aren't transitive and kin and
> sibling aren't symmetric.

Now see, I'm actually leaning towards giving them those properties,
because I don't know any kinship system where those relationships are
considered entirely voluntary. I would rather have the assumptions built
in, and put in some sort of "negative assertion" property for the
disowned and other network outliers. (kin:repudiated, perhaps?)

But that's also where my newbie's knowledge of OWL gets in the way: If
declared kin:husband as owl:ObjectType, then made it an subType of
kin:spouse, while defining kin:spouse as an owl:SymmetricProperty, have
I accidentally made kin:husband symetric with kin:husband? Clearly,
that's my intent.

> For biological relationships (pedigree), we only need one property like
> "biologicalParent". We can also define two classes:

I still like the idea of using things like kin:affine (relationship by
marriage) and kin:consanguine (relationship by blood), because they can
be used with the other relationship properties as well. For example:

<Person>
<name>Bob</name>
<kin:brother rdf:nodeID="frank"/>
<kin:consanguine rdf:nodeID="frank"/>

<kin:brother rdf:nodeID="harry"/>
<kin:affine rdf:nodeID="harry"/>
</Person>

That way, given a reasonable cultural context, I know that Bob and Harry
are only "brothers" because their parents married, but Bob and Frank are
biological (although, admittedly, I still can't know if they're "half"
or "full" brothers without knowing who their consanguinal parents are,
but the "half/full" distinction is one of those cultural things I'd
rather leave for cultural interpretation.)

Furthermore, doing this way doesn't *force* anyone to make the
distinctions if they don't want to (for personal reasons), or can't
(because they're describing a kin group they don't have complete
information for). They can use the basic roles without having to use the
"biological axis" relationships.

> Marriage is more complicated, because it has a time aspect. People are
> married after a certain date or during a certain period. I suggest
> something like this:
>
>     [ a Marriage
>     ; between A, B
>     ; during
>       [ a Period
>       ; began "2004-01-01"
>       ]
>     ].

Pretty much where I was going, too, although I lean towards the "certain
date" model (if only because that's what the bio vocabulary uses).
Either way would work, in the end, as long as we make sure the event
*can* be entered with only date (like if, for example, you know when
someone died but not their birthdate).

> There's some disagreement about what exactly constitutes a marriage, so
> we can either say that it's according to A and B's cultural norms, or we
> can define subclasses corresponding to particular authorities (e.g.,
> "Marriage according to the state of Massachusetts").

"Marriage", from the anthropological/cross-cultural perspective, is
close to being a "I know it when I see it" thing. The usual definition
is something like "customs/obligations that create a special
relationship between spouses, children of the spouses, and the *kin
groups* of the spouses". (The *kin groups* part is important; it's why
I've been arguing that father/mother and husband/wife have to be
separable from male/female anatomy -- there are instances where someone
can be female, but have the social position of being in the patrilineal
line of ancestry.) I would leave stricter definitions to another
vocabulary: If someone wants to flag gay marriages as a contradiction,
let them make their own schema, look at the data using that, and remove
any contradictary relationships it reveals. (An example of the "learning
from contradictions" philosophy I mentioned somewhere in the previous
thread.)

> What do you think, sirs?

Like I said, it's close to where I was going. At this point I've
decided to put together a kinship vocabulary whether or not anyone here
understands it. Right now, my priority is figuring which relationships
to include; I'm strongly considering putting off the handling of dates
until the FOAF community demonstraties a real preference between the
"foaf:birthday" approach and the bio:event approach.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFAW/mQcpuEJT2bpHsRAhITAJ93aU3OFRwWohV/WuKtmqcAHPFHzwCffn6C
FFrFdeGgICQpmxGusybjvsc=
=k48+
-----END PGP SIGNATURE-----



More information about the foaf-dev mailing list