Talk:Date Model: Event

Looking over the new documentation you put up about this, it seems to muddy and confuse the conceptualization of events. While easy for humans to parse, it seems perhaps a bit inflexible comparend to a concept I was playing around with yesterday, namely the OWL document I've set up over here. It's not complete, but somewhat illustrates a way to document generic events as well as specific events, being based in the concepts of the GENTECH model.

For example, one may create an event of a given type, or a generic event specifying a custom type defined within a document, describe the type as having roles to be played, with appropriate properties for allowing deductions to be made, and then specifying players, the roles they play, and their identity.

Take, for example, the following N3 data model that (roughly) illustrates how it might be used in a 'default' Birth event...

<#a> a x-gene:Birth ;
     x-gene:hasPlayer <#aa> ;
     x-gene:hasPlayer <#ab> ;
     x-gene:hasPlayer <#ac> .

<#ac> a x-gene:Player ;
      x-gene:playsRole x-gene:BirthFather ;
      x-gene:playedBy <#aca> .

<#aca> a x-gene:Person ;
       x-gene:name "John Smith" .

<#ab> a x-gene:Player ;
      x-gene:playsRole x-gene:BirthMother ;
      x-gene:playedBy <#aba> .

<#aba> a x-gene:Person ;
       x-gene:name "Jane Smith" .

<#aa> a x-gene:Player ;
      x-gene:playsRole x-gene:Child ;
      x-gene:playedBy <#aaa> .

<#aaa> a x-gene:Person ;
       x-gene:name "John Smith, Jr." .

Note that, for the Birth Event, x-gene:Child is defined as being related by an x-gene:hasPrimaryRole property (thus marking any such event as 'belonging,' in a sense, to the Child), and x-gene:BirthFather and x-gene:BirthMother are x-gene:hasMajorRole, which implies that the roles must always exist even if unspecified. On the other hand, cardinality may be a better marker on roles so as to indicate that BirthFather and BirthMother have a cardinality of 1. It also allows flexibility in defining any number of further custom roles in any event (such as a midwife who can be referenced as the author of a source affirming the Birth, or a doctor doing something similar.)

Furthermore, this definition opens up the ability to work in tandem with a rule-language (e.g. SWRL) to build further descriptions up. For example, one could define a rule that states that any person playing an x-gene:BirthMother or x-gene:BirthFather role in a Birth event is the x-gene:ancestorOf (a transitive property) the person playing the x-gene:Child role in the Birth event. Building from this, one could then start doing simple error checking with further rules and functional properties (such as the fact that the object of an x-gene:ancestorOf must be born BEFORE the birth date of the subject of such a statement), and perform RDQL or SPARQL queries to find all ancestors of a specific person, etc.

It's certainly a bit more complex for humans to understand off the bat, but further implications (such as the reverse, that a x-gene:hasBirthMother property implies that a Birth event has a player played by the object of the x-gene:hasBirthMother property playing the role of x-gene:BirthMother) might be defined as further rules in the language allowing for the terse forms you propose. -- Pipian 19:23, 3 March 2007 (EST)

I've been mulling this one over in mind the last few days. It is certainly a bit more complex, but I'm not quite sure what the benefit is. I do see value in having this "role" concept, as software which is unfamiliar with some user-defined event will still be able to work with "primary" and "major" roles. However, this could also be expressed by just using gc:primaryRole and gc:majorRole predicates, and have predicates like gc:born and gc:gaveBirth be subproperties of these more generic predicates. I sense that there's greater value in having this "player" concept, but I'm not sure what it is. So what I'm wondering is if you could elaborate a bit more on the benefit of adding that. --Hilton 18:07, 6 March 2007 (EST)

The benefit (in my mind at least) is a generalization of all event types, so that, while birth, death, and marriage (as examples) could have 'shortcuts' defined (via well-established rules), they, and all other events, can all be treated identically internal to the program, thus cutting down on programming and encouraging generic programming, and in the long-term, cutting down on program complexity.

As for the Player concept, it was primarily designed as a more abstract concept to differentiate the concept of a role proper (e.g. Mother as role) from the person who plays the Mother in a Birth event, and also to abstract away complications from just considering Individuals as Players (which would lead to difficulty in establishing their roles in events, as a role is integral to an event, rather than to an individual, and merely saying "#a hasPlayer #b, #b a Individual, #b hasRole #Mother" doesn't strongly link the mother role to the specific event #a, instead stating that #b is a mother at some point (at least from my perspective).

Furthermore, if one were to make #Mother an instance of a Mother class instead, it could complicate descriptions, and the necessary description property (to link the motherhood back to the event) '#Mother inEvent #a' creates a descriptive cycle (birth event #a involves an individual #b who is a mother in the birth event #a) and has no 'logical' inverse (other than the subset 'individual #b is a mother in the birth event #a'). Thus, Player acts as a unique 'instance' of a Role, while a Role itself remains simply a concept. So, a Person may take many Roles in their life's events, but there's still only one individual. Lastly, it helps to differentiate similar roles played in different events (though a 'Mother,' etc., class could do similarly through simply defining the nodes as different) -- Pipian 20:03, 6 March 2007 (EST)

I think the advantage of the role model is the possiblity to use subclasses of "Role". So instead of creating a new (and complete unknown because unlinked) predicate "baptised" for a person we add a role "BaptizedChild" that inherits from a generic role. That way even the most exotic role can at least be read by any program (that would probably be confused by an unknown prediate). -- Jzedlitz 09:32, 9 March 2007 (EST)

Why do we need the class "Player"? Isn't is sufficient to use "x-gene:Child" or "x-gene:BirthFather" as type of the role? I have created three diagrams showing the possibilities. -- Jzedlitz 13:39, 9 March 2007 (EST)

example from above

roles without the x-gene:Player class

previous idea with predicates

Ahh, thanks for the images. I haven't had much luck modelling straight from RDF, and thus hadn't gotten a chance to post any. Anyway, after thinking about it, I suppose players aren't really necessary abstractions, and inverses may make sense even without them (only thing I'd suggest is renaming the property to 'hasRole', which unfortunately then plays two roles, both in EventType definition as well as actual Event definition).

That being said, we can still establish some 'shortcuts' like the predicates model in certain cases through a language like SWRL, where we can say, for the test example:

#a^^Birth gene-x:hasRole #b^^Child gene-x:playedBy #c ⇔ #c born #a

or in a more human-readable syntax that corresponds more closely with SWRL:

rdf:type(?a, x-gene:Birth) ⋀ gene-x:hasRole(?a, ?b) ⋀ rdf:type(?b, gene-x:Child) ⋀ gene-x:playedBy(?b, ?c) ⇔ gc:born(?c, ?a)

We can also build more complex models from this, such as:

(#a^^Birth gene-x:hasRole #b^^Child gene-x:playedBy #c) && (#a^^Birth gene-x:hasRole #d^^BirthFather gene-x:playedBy #e) ⇒ #e ancestorOf #c

or again, in human-readable format...

rdf:type(?a, x-gene:Birth) ⋀ gene-x:hasRole(?a, ?b) ⋀ rdf:type(?b, gene-x:Child) ⋀ gene-x:playedBy(?b, ?c) ⋀ gene-x:hasRole(?a, ?d) ⋀ rdf:type(?d, gene-x:BirthFather) ⋀ gene-x:playedBy(?d, ?e) ⇒ gene-x:ancestorOf(?c, ?e)

In this way, gene-x:ancestorOf could be made transitive to thus be able to 'easily' deduce ancestors of any person. Feel free to refer to the images below.

SWRL implication relating the non-player version to the predicate version (SWRL)

SWRL implication that defines 'ancestry' (SWRL)

In addition, with a somewhat arbitrary test case, several facts should (in theory) be derivable. With the non-player->predicate rule set, one should be able to derive the following facts (with #a as an anonymous node)

#georgeWashington gc:born #a .
#augustineWashington gc:fathered #a .
#maryBall gc:gaveBirth #a .

With the 'ancestry' test rules, the following facts should be able to be derived:

#augustineWashington x-gene:ancestorOf #georgeWashington .
#mildredWarner x-gene:ancestorOf #georgeWashington .

-- Pipian 20:05, 9 March 2007 (EST)

I went ahead and updated the event data model pages to reflect this discussion. I think I got it right. I took the liberty of using the GC namespace, I hope that was your intention, Pipian.

--Hilton 12:33, 14 March 2007 (EDT)

Yup. Seems good and core-element to me! -- Pipian 22:13, 14 March 2007 (EDT)