Internet Alchemy » bio

Refactoring BIO with Einstein Part 5: Updated Vocabulary

Ian Davis — Sun, 06 Jun 2010 12:24:24 +0000

It’s been four years since the last instalment of this series. Over the past couple of months I have revised the BIO vocabulary and have incorporated many of the changes I’ve been discussing over the course of this series of posts. Now I am going to revisit some of the examples from my earlier posts and bring them up to date with the new vocabulary.

The BIO Vocabulary models the biography of a person as a series of interrelated events. There are now classes for many different kinds of life event and the beginnings of a series of properties that link these events to people, places, times and other events. The vocabulary can be found at its usual location: http://vocab.org/bio/0.1/

Back in part 1 I set about trying to model this paragraph from Wikipedia:

Einstein was born at Ulm in Württemberg, Germany; about 100 km east of Stuttgart. His parents were Hermann Einstein, a featherbed salesman who later ran an electrochemical works, and Pauline, whose maiden name was Koch. They were married in Stuttgart-Bad Cannstatt. The family was Jewish (and non-observant); Albert attended a Catholic elementary school and, at the insistence of his mother, was given violin lessons.

My first attempt looked something like this (see this RDF file)


  Albert Einstein
  
    
      The birth of Albert Einstein
      1879-03-14
      Ulm, Württemberg, Germany
      
    
  
  
    
      The event of Albert attending elementary school
      
    
  
  
    
      The event of Albert taking violin lessons
      
    
  



  Hermann Einstein
  
    
      The marriage of Hermman Einstein and Pauline Koch
      Stuttgart-Bad Cannstatt
      
    
  
  



  Pauline Einstein
  
  



  The time during which Hermann and Pauline were married

The first thing that strikes me now is how primitive and unlinked the RDF is, something that the past 3 years of the Linked Data project has really hammered home. Those blank nodes are useful in the example, but quite poor for wide scale integration. Today, I would be using dbpedia URIs for the people and places mentioned in the data, especially since it is based on Wikipedia information in the first place.

What changes does the revised BIO Vocabulary make to this example? Actually there are quite a few. There are some new properties that relate events to the people playing particular roles in those events. These are:

bio:agent — a person, organization or group that plays a role in an event.
bio:employer — an agent that is involved in an event as an employer.
bio:officiator — a person that officiates at a ceremonial event.
bio:organization — an organization that plays a role in an event.
bio:parent — a person that takes the parent role in an event.
bio:partner — a person that is involved in a event as a partner in a relationship.
bio:principal — a person that takes the primary and most important role in an event.
bio:spectator — a person that is present at and observes the occurrence of at least part of an event.
bio:witness — a person that witnesses and can bear testimony to the occurrence of an event.

These are not designed to be comprehensive, but to cover the most common cases and provide building blocks for other types of role. The most important is bio:principal which relates an event to the most important person in the event. In the case of the birth of Albert Einstein, Albert is the bio:principal. We can rewrite the birth event like this:


  The birth of Albert Einstein
  1879-03-14

Some events, such as marriages, have no principal (this is my egalatarian viewpoint, some cultures will view marriage differently). We can rewrite Hermann and Pauline’s marriage like this:


  The marriage of Hermman Einstein and Pauline Koch

I can now also explicitly say that Pauline and Hermann were the mother and father of Albert using the new bio:mother and bio:father properties:


  Albert Einstein

One of the areas that was confusing in my original example was the use of the Event class for representing time periods. Although an event such as a marriage may extend for a period of time, it isn’t strictly correct to say it is a time period. Rather it has a time period. The BIO Vocabulary now has a bio:Interval class to model intervals of time and a pair of properties bio:initiatingEvent and bio:concludingEvent to mark the start and end of time intervals. That means we can model the period of time during which Pauline and Hermann were married as a bio:Interval like this:


  The time during which Hermann and Pauline were married
  
  
    
      The death of Hermann Einstein

Because bio:Events are not time intervals it’s not appropriate to use the OWL-Time properties with them. Instead, the intervals associated with each event need to be explicitly drawn out. The bio:eventInterval property relates an event to the equivalent interval over which the event takes place. We can use this property to move the OWL-Time properties onto the relevant intervals like this:

Finally, putting it all together, this is what the original example from part 1 of this series now looks like:


  Albert Einstein
  
  

  
    
      The birth of Albert Einstein
      1879-03-14
      
      
      
      
      
    
  



  Hermann Einstein
  
    
      The marriage of Hermman Einstein and Pauline Koch
      
      
      
    
  



  Pauline Einstein
  



  The time during which Albert was born
  



  The time during which Hermann and Pauline were married
  
  
    
      The death of Hermann Einstein
      
    
  



  The period of time during which Albert attended elementary school
  



  The period of time during which Albert took violin lessons

I hope you'll agree that this has many advantages over the original, with better connections between people, their life events and others who take part in those events. If you want more like this the BIO Vocabulary contains an extensive worked example of Henry VIII and his six wives.

Other posts in the “Refactoring Bio” series:

Refactoring Bio With Einstein Part 4: Employment and Families

Ian Davis — Thu, 16 Mar 2006 02:01:35 +0000

I’m sure regular readers of this series read part three and thought “nice, but do I have to wait five months for the next part again?”. Well I thought I’d buck the trend and just get on with part four :)

I thought I’d go back to the original paragraph about Einstein from Wikipedia:

Einstein was born at Ulm in WÃ¼rttemberg, Germany; about 100 km east of Stuttgart. His parents were Hermann Einstein, a featherbed salesman who later ran an electrochemical works, and Pauline, whose maiden name was Koch. They were married in Stuttgart-Bad Cannstatt. The family was Jewish (and non-observant); Albert attended a Catholic elementary school and, at the insistence of his mother, was given violin lessons.

I just rechecked Wikipedia this paragraph has hardly changed which is encouraging. Presumably wiki-consensus has been reached on that aspect of Einstein’s life. Here’s what I have so far, expressed in Turtle rather than RDF/XML.


# People

_:albert
  a foaf:Person ;
  foaf:name "Albert Einstein" ;
  bio:father _:hermann ;
  bio:mother _:pauline ;
  bio:event _:albert-birth ;
  bio:event _:albert-taking-violin-lessons ;
  bio:event _:albert-attending-elementary-school .

_:hermann
  a foaf:Person ;
  foaf:name "Hermann Einstein" ;
  bio:event _:hermann-and-pauline-marriage ;
  bio:event _:hermann-and-pauline-being-married .

_:pauline
  a foaf:Person ;
  foaf:name "Pauline Einstein" ;
  bio:event _:hermann-and-pauline-marriage ;
  bio:event _:hermann-and-pauline-being-married ;
  bio:condition _:pauline-married-name ;
  bio:condition _:pauline-maiden-name .

# Events

_:albert-birth
  a bio:Birth ;
  rdfs:label "The birth of Albert Einstein" ;
  bio:date "1879-03-14" ;
  bio:place "Ulm, WÃ¼rttemberg, Germany" ;
  time:intDuring _:hermann-and-pauline-being-married .

_:albert-attending-elementary-school
  a bio:Event ;
  rdfs:label "The event of Albert attending elementary school" ;
  time:intAfter _:albert-birth .

_:albert-taking-violin-lessons
  a bio:Event ;
  rdfs:label "The event of Albert taking violin lessons" ;
  time:intAfter _:albert-birth .

_:hermann-and-pauline-marriage
  a bio:Marriage ;
  rdfs:label "The marriage of Hermman Einstein and Pauline Koch";
  bio:place "Stuttgart-Bad Cannstatt" ;
  time:intMeets _:hermann-and-pauline-being-married .

_:hermann-and-pauline-being-married
  a bio:Event ;
  rdfs:label "The time during which Hermann and Pauline were married" ;
  time:intContains _:albert-birth .

# Conditions

_:pauline-maiden-name
  a bio:Condition ;
  time:intMetBy _:pauline-birth ;
  time:intMeets _:pauline-married-name ;
  foaf:name "Pauline Koch" .

_:pauline-married-name
  a bio:Condition ;
  time:intMetBy _:hermann-and-pauline-being-married ;
  foaf:name "Pauline Einstein" .

There are some anomalies such as foaf:name still being applied to the foaf:Person and some of those events perhaps should be replaced by or enhanced with conditions. But I want to examine the rest of the paragraph for what I haven’t expressed yet. I can see:

Ulm is about 100km east of Stuttgart
Hermann was a featherbed salesman
Hermann later ran an electrochemical works
The family was Jewish
Albert’s elementary school was Catholic
Albert’s violin lessons were at the insistence of his mother

I’m going to dismiss 1, 5 and 6 as out of scope for Bio and move straight onto 2. Bearing in mind my earlier characterisation of an Event as something that brings about a change in condition of an individual I can model it is as a Condition and two Events. The Condition is that Hermann is employed:

_:hermann-as-featherbed-salesman
  a bio:Condition ;
  rdfs:label "Working as a featherbed salesman" .

Then there is the event of Hermann starting this period of employment:

_:hermann-starts-working-as-featherbed-salesman
  a bio:Event ;
  rdfs:label "Starts work as featherbed salesman" .

and the event of him finishing this employment:

_:hermann-stops-working-as-featherbed-salesman
  a bio:Event ;
  rdfs:label "Starts work as featherbed salesman" .

I can relate the three things together like this:

_:hermann-as-featherbed-salesman
  time:intMetBy _:hermann-starts-working-as-featherbed-salesman ;
  time:intMeets _:hermann-stops-working-as-featherbed-salesman .

_:hermann-starts-working-as-featherbed-salesman
  time:intMeets _:hermann-as-featherbed-salesman ;
  time:intBefore _:hermann-stops-working-as-featherbed-salesman .

_:hermann-stops-working-as-featherbed-salesman
  time:intMetBy _:hermann-as-featherbed-salesman ;
  time:intAfter _:hermann-starts-working-as-featherbed-salesman .

I can use the same model for item 3 on my list

_:herman-as-electro-works-manager
  a bio:Condition ;
  rdfs:label "Running an electrochemical works" ;

_:hermann-starts-running-electro-works
  a bio:Event ;
  rdfs:label "Starts running an electrochemical works" ;
  time:intMeets _:herman-as-electro-works-runner ;
  time:intBefore _:hermann-stops-running-electro-works ;

_:hermann-stops-running-electro-works
  a bio:Event ;
  rdfs:label "Stops running an electrochemical works" ;
  time:intMetBy _:herman-as-electro-works-manager;
  time:intAfter _:hermann-starts-running-electro-works ;

I know that Hermann was running an electrochemical works after he was a featherbed salesman, but the description doesn’t give me any more than that:

_:herman-as-electro-works-manager
  time:intAfter _:herman-as-featherbed-salesman .

Since employment is a very common condition for a person to be in, it’s probably appropriate to define a class for it:

_:herman-as-featherbed-salesman
  a bio:Employment .

_:herman-as-electro-works-manager
  a bio:Employment .

I’d also like to be more explicit about the actual job Herman was doing during those periods of employment. I’ve used rdfs:label to describe the events and conditions but I’d like to structure this information in some way. My first guess is simply to introduce a bio:jobTitle like this:


_:herman-as-featherbed-salesman
  bio:jobTitle "Featherbed Salesman" .

_:herman-as-electro-works-manager
  bio:jobTitle "Electrochemical Works Manager" .

Now, these events and conditions are related temporally by the OWL-Time properties I’m using but I think it would be useful to relate them causally too. Doing this modelling is helping me understand the relationshops between the concepts I’m using. If a Condition is the state of being for an individual at a particular period of time and an Event is something that brings about a change in condition of an individual then there’s a causal relationship between the two concepts. An event brings about a new condition and a condition is a consequence of an event. Here’s how I could express that latter idea:

_:hermann-starts-working-as-featherbed-salesman
  bio:consequence _:herman-as-featherbed-salesman .

_:hermann-starts-running-electro-works
  bio:consequence _:herman-as-electro-works-manager .

Clearly events can have multiple consequences:

_:hermann-and-pauline-marriage
  a bio:Marriage ;
  bio:consequence _:hermann-married-to-pauline ;
  bio:consequence _:pauline-married-to-hermann .

_:hermann-married-to-pauline
  a bio:Condition ;
  rdfs:label "Being married to Pauline" .

_:pauline-married-to-hermann
  a bio:Condition ;
  rdfs:label "Being married to Hermann" .

But can conditions be the consequent of multiple events? I’m not sure. A literal reading of my definition of event suggests than every event brings about a change in condition of an individual without regard to any other events. I think I’m going to wait until I have more experience before deciding on this one.

So that’s items 2 and 3 described, so onto 4 which is the family’s faith. I could apply a new bio:faith property to a condition for each person but the paragraph clearly says that the family’s faith was Jewish (non-observant). It makes no mention of the individual family members’ beliefs. Clearly people can be born into families of one faith without necessarily subscribing to it themselves. So perhaps I have to model a family unit. I could invent a bio:Family class and make the Albert and his parents members of it. I don’t want to assume any particular social structure but a family seems to be a universal unit of social organisation. The extent of it and the degree of involvement does vary consideraby between cultures but the definition of bio:Family can be kept as unconstrained as possible.

It just so happens that another schema I’ve been involved with has a class that could be useful here. The Relationship schema, with which I had a minor and mostly editorial role, defines a Relationship class which is described as A particular type of connection existing between people related to or having dealings with each other. I added that class hoping to use it for things like family units, marriages and partnerships. It was kept very open to enable use across all kinds of social situations. Here’s my definition of a bio:Family class with a definition drawn from the Wikipedia page on Family:

bio:Family
  a owl:Class ;
  rdfs:subClassOf rel:Relationship ;
  rdfs:label "Family"@en ;
  rdfs:comment "a domestic group of people" .

The Relationship vocabulary provides the rel:participant property to declare involvement in a Relationship class. It can be used like this:

_:einstein-family
  a bio:Family ;
  rel:participant _:albert ;
  rel:participant _:hermann ;
  rel:participant _:pauline .

Now here’s an interesting thing: there was a time when this Einstein family consisted only of Hermann and Pauline. Then Albert was born and he became a member too. So families have a state of being too which changes over time and those changes are triggered by events such as the birth of Albert. So perhaps I should be modelling the family in terms of Conditions too. Here’s how it could work:

_:einstein-family
  a bio:Family ;
  bio:condition _:family-with-hermann-and-pauline ;
  bio:condition _:family-with-hermann-and-pauline-and-albert .

_:family-with-hermann-and-pauline
  a bio:Condition ;
  rel:participant _:hermann ;
  rel:participant _:pauline ;
  time:intMetBy _:hermann-and-pauline-marriage ;
  time:intMeets _:family-with-hermann-and-pauline-and-albert .

_:family-with-hermann-and-pauline-and-albert
  a bio:Condition ;
  rel:participant _:albert ;
  rel:participant _:hermann ;
  rel:participant _:pauline ;
  time:intMetBy _:albert-birth ;
  time:intMetBy _:family-with-hermann-and-pauline .

_:hermann-and-pauline-marriage
  time:intMeets _:family-with-hermann-and-pauline ;
  bio:consequence _:family-with-hermann-and-pauline .

_:albert-birth
  time:intMeets _:family-with-hermann-and-pauline-and-albert ;
  bio:consequence _:family-with-hermann-and-pauline-and-albert .

Here I’m saying that there is a family that has two conditons (states of being): one when it consisted of Hermann and Pauline and another when it included Albert too. Of course there may be others but I’m not considering those yet. The first condition started as soon as the marriage of Hermann and Pauline was complete and in fact was a consequence of that marriage (I’m simplifying here because they were a type of family before marriage too). This condition existed until the birth of Albert whereupon a new condition arises. This new condition is a family consisting of Hermann, Pauline and Albert and is a consequence of Albert’s birth. I think that makes sense.

Now what about that faith property I wanted to use, how do I do that? Well it seems obvious now that it has to be part of a condition. All I want to say is that at some point, and certainly when Albert was born, the family was of the Jewish faith:

_:einstein-family
  bio:condition _:family-faith .

_:family-faith
  bio:faith "Jewish (non-observant)" ;
  time:intContains _:albert-birth .

It doesn’t give me a great deal of information about ordering of events. It would be good to anchor that to some event that defines the formation of the family:

_:einstein-family-forms
  a bio:Event ;
  time:intBefore _:family-faith ;
  time:intBefore _:family-with-hermann-and-pauline .

But I have no way of saying that the family didn’t exist before this event. I have the same problem with people. There could be some small value in having properties that represent the start and end events of a family or a person and adding constraints so that entities can have only a maximum of one of each type. For a start event like a birth, I’d like then to be able to say that there can be no events or conditions that start before that event – another area I believe is not supported by OWL yet.

But that’s the end of the list and I think I’ve managed to model the entire paragrah of biographical information. It remains to be seen how useful this information really is and what holes there are in the sequencing of event. That’s the end of this posting, but I already have plans for several more. Now I’m worried that I’ve jinxed them by mentioning them in public :) Remember also that all of the development I’m doing here is experimental. I haven’t made any changes to the Bio schema as yet and I may choose not to. I’m still thinking this through and trying to understand where the limits of this all-in-the-rdf-model approach lie. I’m actually pretty pleased with it so far and I’m gaining confidence that it’s going to end up expressive enough to answer the kinds of genealogical questions I have in mind.

P.S. While writing this it occurred to me that I forgot to mention another candidate for a temporal invariant in the previous post and it’s one that already exists in the Bio schema – bio:olb. This property was the whole reason why Dave and I created Bio in the first place. It’s a simple enough concept – a one line biography of the person. It’s a potted history, a summary of that person’s life achievements. Now, it may change over the lifetime of the person but it does so in a specialway. It’s a cumulative record of that person’s life. It doesn’t depend on a particular state of being of a person, but on all of them up to that point in time. It’s not strictly invariant but it’s not something that gets replaced over time – it simply grows.

See also: posts in the “Refactoring Bio” series: Part 1: First Steps, Part 2: Conditions, Part 3: Temporal Invariants, Part 4: Employment and Families

Refactoring Bio With Einstein Part 3: Temporal Invariants

Ian Davis — Tue, 14 Mar 2006 21:17:45 +0000

In the previous part of this series I explored how we can represent people as they change over time. At the end of the post I touched on attributes of a person that don’t change: temporal invariants. Two of these are the person’s biological mother and father. Obviously with modern scientific techniques the absolute requirement for two distinct parents is becoming weakened – but for now I’m going to ignore that.

Here’s how we could define these properties in OWL:

bio:mother
  a owl:ObjectProperty ;
  rdfs:label "mother"@en ;
  rdfs:label "The biological mother of the person"@en ;
  rdfs:domain foaf:Person ;
  rdfs:range foaf:Person .

bio:father
  a owl:ObjectProperty ;
  rdfs:label "father"@en ;
  rdfs:label "The biological father of the person"@en .
  rdfs:domain foaf:Person ;
  rdfs:range  foaf:Person .

I want to be able to say that a person has only one father property and one mother property. I can do this with an owl:Restriction like this:

[]
 a owl:Restriction ;
 owl:onProperty bio:mother ;
 owl:cardinality 1^^xsd:nonNegativeInteger .

[]
 a owl:Restriction ;
 owl:onProperty bio:father ;
 owl:cardinality 1^^xsd:nonNegativeInteger .

Those statements define two anonymous classes requiring members of each class to have exactly one value for the relevant property. Another way to do this would be to make bio:mother and bio:father functional properties. The difference is that the functional property assertion is a global constraint, it applies no matter what class the property is used with whereas the cardinality restriction applies on a per-class basis. It would probably be valid in the context of the bio schema to make the functional property assertion which would probably exclude using bio for genealogies of some mythical figures and deities. I’m not sure if that’s at all important at the moment so I’m going to stick with the weaker cardinality restictions.

But how can I best apply those restrictions to the people being deescribed? One way is to modify foaf:Person like this:

foaf:Person
  rdfs:subClassOf [
    a owl:Restriction ;
    owl:onProperty bio:mother ;
    owl:cardinality 1^^xsd:nonNegativeInteger .
  ]

Here I’m saying that foaf:Person is a subclass of a class of things with exactly one mother. I can also add in the father restriction:

foaf:Person
  rdfs:subClassOf [
    a owl:Restriction ;
    owl:onProperty bio:mother ;
    owl:cardinality 1 .
  ]
  rdfs:subClassOf [
    a owl:Restriction ;
    owl:onProperty bio:father ;
    owl:cardinality 1 .
  ]

Which is saying that foaf:Person is also a subclass of a class of things with exactly one father. So a paraphrase would be: foaf:Person is the class of individuals that, amongst other things, have exactly one bio:mother and exactly one bio:father. Note that this very different from using owl:equivalentClass, e.g.

foaf:Person
  owl:equivalentClass [
    a owl:Restriction ;
    owl:onProperty bio:mother ;
    owl:cardinality 1 .
  ]
  owl:equivalentClass [
    a owl:Restriction ;
    owl:onProperty bio:father ;
    owl:cardinality 1 .
  ]

Using owl:equivalentClass in this way is saying that foaf:Person has the same set of individuals as the class of things with exactly one father and the class of things with exactly one mother. Now that sounds very similar to my earlier paraphrase but it’s subtly different. The distinction lies in the concepts of necessary and sufficient conditions. The earlier subclass form provides necessary conditions for an individual to be a member of the foaf:Person class: it must have a bio:mother property and a bio:father property. Crucially those are necessary conditions but they’re not sufficient to determine that the individual is a foaf:Person because there may be other restrictions not expressed here that are also necessary. That is the purpose of the amongst other things phrase in the paraphrase above and is a direct consequence of the open world assumption. owl:equivalentClass, on the other hand, makes a much stronger assertion: it’s saying that to be a member of foaf:Person an individual needs a bio:mother property and that’s enough. In other words it defines necessary and sufficient conditions for membership. More formally the foaf:Person class has exactly the same members as the class of individuals with exactly one mother, no more and no less. If you want also to say that a foaf:Person must be human, then you’re out of luck.

But is it ok to modify foaf:Person like this? I guess I could ask Dan and Libby to modify the FOAF specification but that would mean asking FOAF to depend on bio’s deliberately pedantic view of the world. Also bio is much less mature than FOAF and has a different change cycle and tying something that is quite stable to something in flux can’t be a good idea. I think it’s perfectly acceptable to make those assertions about foaf:Person in the bio schema. The interpretation is that if you subscribe to the bio schema’s view of the world then you have to accept the restrictions on the foaf:Person class.

That statement is stronger than it first appears because subscribing to bio’s worldview happens as soon as you use any of its properties in your RDF. It doesn’t matter if you, or your authoring tool, can’t understand the schema because RDF licenses the consumer to dereference any URIs in the content to discover more information. When you derereference http://purl.org/bio/0.1/father you will eventually get the axioms that the bio schema deems necessary for consistency. In theory the document referenced by that URI could simple include the assertions that directly involve bio:father but in practice you’ll get the whole bio schema including assertions about bio:mother. Is this a problem? Probably not, but I think the schema author has to be responsible about the granularity that schemas are written to. For example, vocab.org hosts several RDF schemas and in theory I could combine them all into a single document and contrive that all property and class URIs return that document when dereferenced. That would mean you’d get axioms about all the schemas even if the content uses only a single property or class from one of them. That sounds like a bad idea which is why schema documents tend to reflect a single namespace URI.

Returning to our definitions of bio:mother and bio:father is it possible to say that no father is also a mother (in the strict biological sense, not the social sense). It’s not possible to use a restriction in OWL to say that the values of two different properties must be different but it is possible to define two classes to have different members using owl:disjointWith. So, I can define a class of mothers and a class of fathers and say that they never have the same members:

bio:Mother
  a owl:Class ;
  rdfs:subClassOf foaf:Person .

bio:Father
  a owl:Class ;
  rdfs:subClassOf foaf:Person ;
  owl:disjointWith bio:Mother .

Then I can relate these to the bio:mother and bio:father properties:

bio:mother
  rdfs:range bio:Mother .

bio:father
  rdfs:range bio:Father .

But now I have a dilemma: membership of the bio:Mother class isn’t temporally invariant. A person becomes a member of that class at a particular point in time, i.e. when they have a child. All along I’ve been modelling bio:mother as an invariant property but of course it is time bounded. A person doesn’t have a mother until they are born and in many cultures motherhood begins at conception, or somewhere between the two! Potentially, there’s an even worse problem waiting in the wings: the child doesn’t exist until conception or some short time after depending on your definition.

I think there are several ways to resolve this dilemma.

One way would be to model bio:mother in terms of bio:Condition in the same way I did for people’s names in the previous refactoring bio post.

_:child
  a foaf:Person ;
  bio:condition [
    a bio:Condition ;
    bio:mother _:mother .
  ] .

This says that at some point in the person’s life they had a mother. Perhaps I can bound it by the time of their birth, but I would want to leave the upper bound undefined or specify forever. But now, of course, the domain assertions apply to the bio:Condition which I defined as the state of being for an individual at a particular period of time. I can envisage motherhood as a state of being that some people have for part of their life and having a biological mother is a state of being that every person has for the duration of their existence. So what’s the range of bio:mother here? Is it a foaf:Person, bio:Mother or bio:Condition? It would be convenient to reference a person but I think it’s going to destroy any chance of asserting that mothers and fathers are different people.

Another way is to redefine what I mean by bio:Mother and bio:Father. These could be better named bio:MotherAtSomeTime and bio:FatherAtSomeTime indicating that members of these classes are mothers or fathers at some time in their lives but not necessarily all of it. This approach would still let me express my disjoint class axiom:

bio:MotherAtSomeTime
  a owl:Class ;
  rdfs:subClassOf foaf:Person .

bio:FatherAtSomeTime
  a owl:Class ;
  rdfs:subClassOf foaf:Person ;
  owl:disjointWith bio:MotherAtSomeTime.

and the range axioms for the properties:

bio:mother
  rdfs:range bio:MotherAtSomeTime .

bio:father
  rdfs:range bio:FatherAtSomeTime .

Is this a hack? I don’t think so, I think it’s just a different perspective on the same information. It can even work in conjunction with the condition approach

There is a third way and that is to step outside of the RDF model entirely. I could annotate each triple with the date range for which it is valid. Any query then would have to specify the date which would be used to select the correct triples. This is the approach taken by the researchers in this Temporal RDF paper. I’m sure it could even be supported with Sparql and named graphs, but I think the number of graphs would rapidly grow vast, probably converging in the limit with the number of triples. Also it requires a notion of absolute time which doesn’t exist, and if it did would preclude the kind of broad notions of temporal sequencing that are common in biographical and genealogical records.

As an aside, this raises the whole issue of contexts and in particular the differing notions of what constitutes context. Most people discussing context in RDF are really talking about provenance, they want to know where each triple came from and who asserted it. However, for bio, the context would be what time period the triple was true for. There are many other notions of context I’m sure, such as why a triple was asserted.

So, what is the best approach? My feeling is that solution two with the bio:MotherAtSomeTime and bio:FatherAtSomeTime classes is a pragmatic and reasonable approach that doesn’t preclude a more formal approach using bio:Condition so I’ll probably move forward with it.

There are some other restrictions I’d like to be able to express but that I don’t think are possible in OWL. For example, I’d like to say that no person is their own father or mother. I may have to fall back to the use of rules for these kinds of constraints, but for now I think I have the foundations set to actually work on the other parts of Einstein’s biography that I promised last time!

Update: I removed the datatyping from the cardinality values in response to a comment by Dan Connolly below.

See also: posts in the “Refactoring Bio” series: Part 1: First Steps, Part 2: Conditions, Part 3: Temporal Invariants, Part 4: Employment and Families

Refactoring Bio With Einstein Part 2: Conditions

Ian Davis — Mon, 17 Oct 2005 17:55:32 +0000

Genealogy is mostly a detective game dealing with partial knowledge. Given a few facts and dates, the researcher makes informed estimates for related events. For example if you know that someone was born in 1905 you might start searching for their marriage around 1925-1935 because most people marry in their twenties. If you don’t find it you might first look earlier, back to around 1920 and onward from 1935. The genealogist mentally assigns a probability of success to the search and focusses on the highest probability ranges first. Lots of factors affect this estimate. Fashions of the period might affect average marriage ages as can family traditions.

Working the other way is important too. Often the genealogist has a marriage certificate with an age. It’s natural to subtract the age from the date of marriage to look for the birth of the indivudual. However, this is skewed you allow for people adjusting their ages upwards because they’re under the legal age of marriage, or downwards to close up a scandalous age difference with their partner! It’s not unknown for people just to forget or not know how old they are, especially if they had little or no contact with their birth parents.

It is often useful to know the whereabouts of an individual to narrow down a search for information. For example, if it was known that a person was in the army and stationed in a particular country for an extended period of time then that would restrict the range of a search for the person’s marriage certificate.

With these points in mind, I set about trying to understand how I can better model the time-related information used in genealogy. One of the outstanding problems I mentioned at the end of the previous part of this series was that I hadn’t represented Einstein’s mother’s maiden name. Currently I have this description of Pauline:

  
    Pauline Einstein

I could simply add her maiden name:

  
    Pauline Koch

    Pauline Einstein

But that isn’t very useful since there’s no way to tell which name to use at which time. To get around this I could introduce a maidenName property to explicitly note her former name:

  
    Pauline Koch
    Pauline Einstein

This works for this simple example but what about people who remarried more than once or people who changed their legal names? It seems that name is an example of a mutable property that takes different values depending on when you ask. How could I represent it? Here’s one way, by modelling the condition of the person at a point in time:

  
    
      

        Pauline Koch
      
    

    
      

        Pauline Einstein

Here I’ve introduced a new class Condition which I think of as the state of being for an individual at a particular period of time. I can ground those conditions in time by relating them to other events:

  
    

      
        
        
        Pauline Koch
      

    

    
      
        
        Pauline Einstein

The condition of pauline having her maiden name starts as soon as she is born (referred to here by a new blank node ‘pauline-birth’) right up until the condition of her being known as Pauline Einstein which starts at the same time as her being married. There’s no end to this latter condition. As far as I know she kept her name until her death and that is how she is known today.

The concept of Condition may be quite useful. It looks to me as though most conditions will be bounded by events, e.g marriage and divorce events bound the condition of being married. This suggests that a better definition of event is something that brings about a change in condition of an individual

There is a domain issue around the usage of FOAF properties with Conditions. The domains of most of the relevant properties in FOAF are either foaf:Person or foaf:Agent. I’m not sure that I can reconcile the notion of a Condition being a Person or vice-versa. This might mean that I have to create parallel properties for some of the more interesting FOAF ones such as foaf:name and its ilk.

How far do we go with this? I think that most properties relating to a person are temporal in nature. Many of the properties used by FOAF to identify people are mutable over time: foaf:mbox, foaf:weblog, foaf:homepage. For FOAF that doesn’t cause a problem. FOAF is intended to be a general description of a person, not necessarily at a point in time. However, that approach isn’t appropriate for things like genealogy and biographical writing. In those activities the goal is to create a narrative of an individual’s life. This is what I’m aiming at with BIO. I’d like to be able to generate a timeline of a person’s life from an RDF description. It should also be possible to pick a point in time and produce a FOAF description of that person at that time.

Although most attributes of a person do change, there are a couple of relationship-oriented ones that are immutable throughout throughout the lifetime of a person: father and mother. Here’s how they could be used:



  Albert Einstein
  
  
  ...

This looks to be a useful way to build up simplistic family trees.

So, in conclusion I now have a way to represent the relationship of Einstein to his parents and a way of representing the fact that his mother was known by different names at different points in time. Not quite what I thought I’d be focussing on last time but still progress. What’s remaining? Looking at my list I have still to represent his father’s occupation; the family’s faith; the roles of the participants in events and annotation of events and conditions. More thought for next time…

See also: posts in the “Refactoring Bio” series: Part 1: First Steps, Part 2: Conditions, Part 3: Temporal Invariants, Part 4: Employment and Families

Refactoring Bio With Einstein Part 1: First Steps

Ian Davis — Tue, 05 Apr 2005 21:56:08 +0000

I’m going to try to describe the life of Albert Einstein using the BIO vocabulary. I’m expecting this to be quite difficult but hopefully should understand better where the vocabulary is deficient. I’m keen to examine how ordering of events can be achieved using OWL-Time and I’d like to be able to enhance the BIO vocabulary to make expressing common biographical information easy.

I’m basing this micro-project on the Wikipedia biography of Einstein. That work is licensed under the GNU Free Documentation License and so I’m putting this article and associated RDF data under the same license.

Why Einstein? I chose Einstein because, being a former phycisist, I have an admiration for him and his theories. He is a popular icon, is the subject of dozens of biographies and, having lived in the modern era, there are photographs and movies that could also be relevant.

This exercise will use a combination of the BIO, FOAF and OWL-Time vocabularies. I’ll use the namespace prefixes bio, foaf and time for these.

My approach is to follow the Wikipedia article and translate each distinct event into RDF.

According to the article introduction, Einstein was born on March 14, 1879. A few paragraphs down is the following:

Einstein was born at Ulm in Württemberg, Germany; about 100 km east of Stuttgart. His parents were Hermann Einstein, a featherbed salesman who later ran an electrochemical works, and Pauline, whose maiden name was Koch. They were married in Stuttgart-Bad Cannstatt. The family was Jewish (and non-observant); Albert attended a Catholic elementary school and, at the insistence of his mother, was given violin lessons.

Here’s a skeleton document to start off:


  Albert Einstein

  

    
     The birth of Albert Einstein
     1879-03-14
     Ulm, Württemberg, Germany

That’s a bit dry. I’m not expressing any of the relationship information from the original article. Here’s what it could look like if I used the Relationship vocabulary:


  Albert Einstein

  
    
      Hermann Einstein
      
      

    
  

  
    
      Pauline Einstein

      
      
    
  

  
    

     1879-03-14
     Ulm, WÃ¼rttemberg, Germany

However, the problem is that the relationship vocabulary assumes a fixed point in time, whereas the bio vocabulary attempts to express different states across a period of time. Some relationships are immutable throughout time, e.g. childOf, whereas others apply for definite periods, e.g. spouseOf. One interpretation is to assume that the relationships hold for at least some period of time but it is not safe to use them for analysis of time-sensitive data. In other words you can ask “were these two people ever married” but you cannot ask “were the parents of this person married when he was born?”

It would be possible to use a modified relationship schema where the domain of the properties is some kind of “Person At Point In Time” but that feels unnatural. A better way, in my opinion, is to explicitly represent the marriage as a time interval. I can’t use the bio:Marriage class because that represents the actual marriage ceremony, instead I need to use an general Event instance:


  The event of Hermann and Pauline being married

In the BIO vocabulary Event is defined as “A general event, i.e. something that the person participated in.” – it can be any episode with a duration. I can also relate this event to Hermann and Pauline’s marriage:

  
    Hermann Einstein
    
      

        The marriage of Hermman Einstein and Pauline Koch
        Stuttgart-Bad Cannstatt
        
      
    

    
  

  
    Pauline Einstein

The intMeets property says that the married interval starts directly after the marriage event. I’ve also associated the event of being married with each person so they are explicitly participating in the event.

I can enrich the structure of the biography by asserting that Albert was born during his parent’s marriage. It seems to me that it should be possible to derive this fact, but until I understand more about this I need to state it explicitly can do this on the married interval:


  The time during which Hermann and Pauline were married

or, equivilently, in the Birth event itself:


  
   The birth of Albert Einstein
   1879-03-14

   Ulm, WÃ¼rttemberg, Germany

The Wikipedia article mentioned that Albert attended a Catholic elementary school and took violin lessons. I’m going to express those as events:



  
    The event of Albert attending elementary school
    
  




  
    The event of Albert taking violin lessons

So, what have I been able to represent from that single paragraph of biography? I’ve represented Albert Einstein’s date and place of birth; his parent’s marriage and the fact that Albert was born during the marriage; Albert attending elementary school and taking violin lessons. Each of the events is related to another event to assist with automatic ordering.

What haven’t I represented? His father’s occupation; his mother’s maiden name; the family’s faith. I haven’t explictly stated that Albert is the son of Hermann and Pauline and their participation in the marriage event isn’t strong enough to state that they were actually the couple getting married (other people can participate such as a minister or witnesses). Also the events have no colour – I have dry labels describing the mechanics of the event, but nothing with personality.

I need to be able to annotate events and provide commentary. I need also to be able to resolve the roles of participants in events. I’ll be thinking about those issues for part two.

Here’s an RDF file that collates what I’ve done so far.

See also: posts in the “Refactoring Bio” series: Part 1: First Steps, Part 2: Conditions, Part 3: Temporal Invariants, Part 4: Employment and Families