It makes sense to give the server applications as much responsibility as possible as to avoid having to rewrite logic across different types of clients.

In my case I am developing a data structure that represents human relations (mother, father, sister, brother, etc.) the purpose is to query the data structure and get the chain (if there is one) of relations between two people.

I ultimately want to support types of relations that are not consistent through cultures and languages. In English for example there is only grandmother and grandfather, where as in other languages these can be expressed in terms of which parents side they are on.

I am not sure how to divide the responsibilities of the service on the client and server.

Should the server return a relation chain that is independent of culture? That is only using simple relations like mother, father, son, daughter... to the client and let the client deal with culture specific conversions? In this case I would develop some client conversion libraries in Javascript for the cultures i wish to support. If someone wants to use my service in their xamarin-app they would have to rewrite that conversion logic in C#.

Or should I do everything on the server? Using this option it feels like the server would do to much almost, shouldn't it be enough to return data (culture independent relations) that can represent other data (culture-specific relations) and let the clients do the conversion as they see fit? On the other hand the conversion involves quite a lot of logic...

Or should I have both? That is, on the server provide a relation chain independent of culture on the plus some culture specific relations that i wish to support. This way, if some types of relations are not supported by the API someone can grab the culture independent relation chain and do their own conversion.

If you think of other pros / cons with the different approaches I'd like to hear them.

What is the better approach and why?

  • English uses expressions like maternal grandfather. Commented Sep 7, 2019 at 5:26
  • Note that when 2 people with a child get divorced and both get married again, the child would then have 4 grandparents. Also in some cultures a male can have more than 1 wife in the same time. Add to that a person may adopt a child, this child would then have his original grandparents+the new ones....so many rules.
    – NoChance
    Commented Sep 7, 2019 at 6:08
  • @candied_orange alright, i did not know that
    – Tagor
    Commented Sep 7, 2019 at 10:57
  • @NoChance yep, there are many rules indeed.
    – Tagor
    Commented Sep 7, 2019 at 10:58
  • Humans are complicated. That's why some forms let you choose "other" Commented Sep 7, 2019 at 20:11

2 Answers 2


The case described is ideal for using logic programming and graph-based data structures. You have two parts: Relationships in the most basic form (including basic facts like marriages, divorces, births, etc - I believe there are good standard ontologies for those), and rules on how to "call" those relationships.

I do not know how constrained is your "client", and whether it can perform inferences on it's own, but once the facts and rules are in place, it's quite simple for the inference engine to deduce the facts even in the muddiest cultural cases (provided you have supporting facts).

It is possible also to make your knowledge base into modules, one per culture, if we know that only part of the cultural-specific knowledge will be in use. This means, that the inference may happen faster.

The nice side of using knowledge base approach is that all the knowledge is in the uniform format, it's extendable by just loading more facts to work (for example, in semantic web speak - just adding new triples or graphs with triples), and it requires quite generic inference engine (which you may probably even find in the form of some library).

Accordingly, API will boil down to requesting packages of facts (around specific individuals) and rules (if the whole set of rules does not fit to the client side of the application, which I doubt is the case).

I do not know if you have user queries, but inference engines can easily work in both directions: "Understanding" complex relationship as consisting of smaller ones, and identifying complex relationships given elementary ones: It just depends on what is your goal. Every book on Prolog I've seen uses family relationships as an introductory example.


REST (HTTP) has a concept of content negotiation. The client can ask the server for the content type of a resource and can also tell the server what type of content type it will accept. The client and server can then figure out the best format to return the data in.

So you could support some very specific representations of these relationships resources via a custom content type that you define (see vendor and unregistered content types https://en.wikipedia.org/wiki/Media_type#Vendor_tree)

You could also have a very generic format that clients can fall back on if they don't support the specific representation.

This gives you the best of both worlds, you can support specific representations without having to worry that if you miss one your clients won't work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.