Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Note on FtM graph semantics #1

Open
pudo opened this issue Nov 18, 2020 · 0 comments
Open

Note on FtM graph semantics #1

pudo opened this issue Nov 18, 2020 · 0 comments

Comments

@pudo
Copy link

pudo commented Nov 18, 2020

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant