Advanced relation semantics: a relation as a role-player in another relation?


#1

Let me pose a situation: a graph includes a claim of the form

A causes B

.In RDF, in order to refute that claim, one might perform one of:
a) reify the “A causes B” claim as its own entity and use that as an actor, say, in “disagrees with” relation with another entity.
b) simply create A does not cause B assertion
c) something else

In topic maps, it is possible that the arc “causes” is also its own entity (topic) with the semantics of precisely the claim. As such, that relation node can, itself, be an actor in, say, a some refutation relation(s).

Adding to that, many relations have biographies, which can be either individual topics (entities) or structures. In another post here, I saw mention of a “because” relation.

What are the modeling options in Grakn?


#2

Hi @jackpark,

We are closer to the Topics Map approach. In that the causes part is a relation which can have other relations attached to it.

For example, lets say you want to model a relationship. You could do the following:

define

husband sub role;
wife sub role;
person sub entity 
    plays husband
    plays wife;
marriage sub relationship
    relates husband
    relates wife;

Now create the marriage:

insert

$x isa person;
$y isa person;
(husband: $x, wife: $y) isa marriage;

Now lets say you want want to attach a date to the marriage.
(for the sake of being brief I am omitting some schema mutations which need to occur)
You could add another roleplayer to the relation like so:

insert

$x isa person;
$y isa person;
$z isa date;
(husband: $x, wife: $y, date-of-marriage: $z) isa marriage;

or you could treat the relation itself as a roleplayer:

insert

$x isa person;
$y isa person;
$z isa date;
$r (husband: $x, wife: $y) isa marriage;
(event: $r, date-of-event: $z) isa has-date;

So these are some of the modelling options you have at your disposal with Grakn.


#3

Hi @filipe
That’s useful!
Let me probe a bit more.

Your example makes sense while you are creating the situation. My new question is this:

How does one take the “causes” relation in my example and, later, use it as an event for which it can then be an actor in the new relation I want to start?

My scenario is this:

I am surfing a Grakn graph, say, online. I spot that A causes B claim and I want to start a debate. In my model, I click on the “causes” node and “reply” to it with a question, say, “what is your evidence?”

That question would then model to a “question” relation between that relation node and a new entity, say, “evidence” (this is a really naive sketch of a possibly complex situation I’d like to model in Grakn…I know how to do it with topic maps, just not (yet) with Grakn).


#4

So there are a multitude of ways to model that depending on what A and B actually are. For simplicities sake lets say that A and B are both entities (in the grakn world). If one of them were resources the process would be slightly different.

So with A and B both being entities lets start by modelling the causes relation. First we define the schema:

define
id sub resource datatype string;
causer sub role;
causee sub role;
alphabet-letter sub entity
    plays causer
    plays causee
    has id;  //Using this just to more explicitly identify A and B
causes sub relation
    relates causer
    relates causee;

So the above simply defines the schema of the causes relation. In the Grakn world you have to define the roles being played. That is why I defined causee and causer. Also every entity must belong to a type, which is why I created alphabet-letter. With resources these roles get defined implicitly, but that is for another discussion.

Next let’s state that A causes B:

insert 
$a isa alphabet-letter has id "A";
$b isa alphabet-letter has id "B";
(causer: $a, causee: $b) isa causes;

Right so now we have modelled A causes B.

Now lets get to the next part of your question:

That question would then model to a “question” relation between that relation node and a new entity, say, “evidence”

So now we want to say that the causes can have some evidence to it. So first thing, we have to modify our schema to allow any instance of the causes relation (like the one above) to have evidence. We do that like so:

define
question-evidence sub role;
questioned-item sub role;

evidence sub entity
    plays question-evidence;

//Notice here how we are now allowing causes to be question
causes sub relation
   plays questioned-item;

//Now we define the question relation:
question sub relation
    relates question-evidence
    relates questioned-item;

So the above expands on our already existing schema to allow causes to be questioned. Now lets attach a question to our existing relation:

//First lets get the relation back
//this is just a query to find the relation we have already created
match 

//This is why we created the ids. Makes it easier to get these things back.
$a isa alphabet-letter has id "A";
$b isa alphabet-letter has id "B";

$r (causer: $a, causee: $b) isa causes;

//Now in the same query lets question the cause $r
insert

$e isa evidence;
(questioned-item: $r, questioned-evidence: $e) isa question;

And the above it one of the ways in which you could define A causes B and then later say A causes B because etc . . . .