You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a little bit out of the blue, but I wanted to share some thoughts on FtM graphiness. This is how we've been thinking about it in the past, and we can change it, but it would almost certainly require adaptation of the FtM model to do cleanly.
The normal case for what an edge is in FtM is a property value. This is a consequence of FtM being a somewhat RDF-inspired data model (until Aleph 2.x, we had a Neo4J-style property graph model, but then @rhiaro talked me out of it). For example, consider the case of a Person and a Passport: the Passport simply has a holder property which contains the Person.id. When turning this construct into a property graph model, both the passport and the person become nodes, and the holder property becomes an edge with no properties attached to it.
Sometimes we want to talk about the inverse of one of these edges. That's why holder has an inverse, passports that is added to the Person schema. This is mostly used to store, for example, the labels that should be used to talk about the passports linked to a person. But it's a stub property that cannot be written (doing Person.add('passports', value) will throw an exception.
The weakness of this model is that edges don't have properties, whereas relationships in society always have metadata :) Many of them, for example, are limited in time (hence Interval). So we added a hacky work-around that allows some schema to sort of contract upon generating a property graph and turn into an edge, rather than a node. For example, Membership, Ownership. But it's important to keep considering this a special shortcut, not the normal case for edges in FtM.
Because this is a hack, it leaves the stub properties in a bit of an awkward place: it's not clear conceptually if they refer to the original edge (e.g. a link between a Person.directorshipsDirector -> Directorship.director) or the contracted edge (Person -> directorOf -> Organization)... It's not hurt us too much in practice since we get the required metadata from the edge annotation of the contracted schema, but it's a sort of weird "place".
The text was updated successfully, but these errors were encountered:
This is a little bit out of the blue, but I wanted to share some thoughts on FtM graphiness. This is how we've been thinking about it in the past, and we can change it, but it would almost certainly require adaptation of the FtM model to do cleanly.
Person
and aPassport
: thePassport
simply has aholder
property which contains thePerson.id
. When turning this construct into a property graph model, both the passport and the person become nodes, and theholder
property becomes an edge with no properties attached to it.holder
has an inverse,passports
that is added to thePerson
schema. This is mostly used to store, for example, the labels that should be used to talk about the passports linked to a person. But it's astub
property that cannot be written (doingPerson.add('passports', value)
will throw an exception.Interval
). So we added a hacky work-around that allows some schema to sort of contract upon generating a property graph and turn into an edge, rather than a node. For example,Membership
,Ownership
. But it's important to keep considering this a special shortcut, not the normal case for edges in FtM.stub
properties in a bit of an awkward place: it's not clear conceptually if they refer to the original edge (e.g. a link between aPerson.directorshipsDirector
->Directorship.director
) or the contracted edge (Person
->directorOf
->Organization
)... It's not hurt us too much in practice since we get the required metadata from the edge annotation of the contracted schema, but it's a sort of weird "place".The text was updated successfully, but these errors were encountered: