Discussion Forum

Designing a multi layer hierarchical organisation

Hello, I am newbie with grakn and I need your help to efficiently design my schema so that it fulfills what I want to achieve.

What I want to put in the knowledge graph:
I want to add the whole structure of an university (see image below) inside a graph.

I want to be able to query at multiple level like finding the students that are in a specific faculty or in a specific departement.

How I proceeded so far:

hierarchy sub relation,
                abstract,
                relates parent,
                relates child;
 
unit-hierarchy sub hierarchy,
                relates parent-unit as parent,
                relates child-unit as child;
 

unit sub entity, 
    owns name, 
    owns orgtype, 
    plays unit-hierarchy:parent-unit, 
    plays unit-hierarchy:child-unit;

name and orgtype are strings. orgtype correspond to the layer name (faculty, department,…)

I managed to put the data and relation at each level (defining relation between faculty-departement, departement-section).

Problems I have:
-Problem 1: I would like to retrieve all the Department of a specific Faculty and all the Section of a Faculty.
-Problem 2: Display the whole structure on the Workbase (from faculties to department to section)

For the problem 1, I’ve tried to do on grakn workbase:

match 
	$relation (parent-unit: $faculty, child-unit: $department) isa unit-hierarchy; 
         $faculty isa unit, has orgtype $orgtype; 
	$orgtype "science"; 
	get $departement;

It retrieves nothing.
I don’t know how to proceed to obtain all section for a given faculty.

For the problem 2, I don’t really know if there’s a way to infer the full chain of relation (from faculty to departement to section). For instance, given a section, finding it’s department and faculty. Maybe the design itself isn’t appropriate to do such things.

I’m sorry, there’s a lot of question but I’m stucked at this step and don’t know how to move forward. Please let me know if something is unclear.

I’m going to put down the rough sketch of how i’d translate your Domain model into a schema (it’s far more literal than you’re going for, so it’s easier for the reader, but it may also not be what you’re going for).

Here’s how i’d start the schema (you’re definitely on the right track):

define
  member sub entity,  
    abstract,
    owns name,
    plays membership:group,
    plays membership:member;

  university sub member;
  
  faculty sub member;

  section sub member;
 
  student sub member,
    // you may want to specialise names for students
    owns first-name as name,
    owns last-name as name;

  membership sub relation,
    relates group,
    relates member;

  name sub attribute, value string;
  first-name sub name;
  last-name sub name;

to query for all departments of a faculty:

match $faculty isa faculty, has name "Science"; (group: $faculty, member: $department) isa membership; get $department;

to query for all sections of a faculty follows almost exactly.

If you want to query for the entire thing in Workbase, you might be able to do the following:

match $r ($x, $y) isa relation;

that will show you the structure without attributes… you could then probably run another query to grow the graph with attributes:

match ($x) isa relation; $x has $a;

Speaking of inferring chains of membership (which you don’t really need to show the structure in workbase) you can add the following rule:

define
  rule transitive-membership:  when {
    (group: $upper, member: $middle) isa membership;
    (group: $middle, member: $lower) isa membership;
  } then {
    (group: $upper, lower: $lower) isa membership:
};

now you can do fun stuff like querying for all sections in a univeristy with a one-hope query from the user:

match (group: $university, member: $section) isa membership; $university has name "University of Geneva";

Good steps so far, keep going.

Welcome to the Grakn community :slight_smile:

1 Like

Thanks a lot! It works and it rocks!
I really appreciate that you took time to write all of this!

I just corrected few things (putting them here cause it can be useful for someone else):

  • changing group to organization (as group is a reserved word)
  • put the attribute definition just after the define (in the schema)
  • fixed the typo in the rule transitive-membership (it’s member: $lower and not lower: $lower)

I’ll probably come with additional questions later on :sunglasses:

1 Like

@joshua Thank you for sharing your solution. But there are some issues with that. First of all you brake the rules of inheritance (all properties of child are included in parent). University is in general not a child of “member”, that is more a role of the university, student, … This solution works only for a very small scope of a domain.
I´d like to see a more generic solution for nested lists (e.g. bill of material). A hierarchy with no defined number of levels, the name of each level is just an number (instance), every member can occur on every level.
Many thnk´s for replying, Helmut