Consider a graph with four entities A, B, C and J, the relation “_ judges _ to be more important than _”, and the following two instances of that relation:
“J judges A to be more important than B”
“J judges B to be more important than C”
I’d like to specify that those relationships are, if you hold the first member constant, transitive in their second and third members, and then sort the list [A,B,C] based on the partially applied relation “J judges _ more important than _”.
Moreover, given a second judge H, I’d like to be able to say “sort first on J’s preferences, and break ties using H’s preferences.”
(I’m using the concept of “judge” just because it’s easy to explain; in practice I’d use all kinds of different orders – in particular, urgency to a project, being blocked by another project, relevance to a topic, and ease or order of presentation when explaining to someone unfamiliar with the topic.)
Are queries like these possible?
Hi Jeff, I don’t believe queries of this kind are possible in TypeDB 2.x, but will certainly be in TypeDB 3.0. In the meantime, I would suggest writing a query that simply retrieves the roleplayers, and then sort them in your application code.
For transitive preferences
I’d like to specify that those relationships are, if you hold the first member constant, transitive in their second and third members, and then sort the list [A,B,C] based on the partially applied relation “J judges _ more important than _”.
Do you mean “for a given judge, the preferences are transitive”? That should be a straightforward transitive rule.
For sorting the answers on preference:
Short answer: no. Sorting in the application code as James suggested is your best option.
Long answer: likely possible, but very complicated.
I should start by saying I work on the inference engine, so I tend to indulge in overly complex sets of rules. That’s where the rest of the answer is going.
Sorting is harder, because our sort operation works on some value (like a long or double, or even string), rather than on an explicit ordering relation. If your relations were totally ordered, it would have been possible to assign them a preference. So I don’t think we can use the inbuilt sorting for this.
The only remaining option is to explicitly construct the total ordering and assign them a rank. This would be an elaborate solution but restricted to a fixed order of tie-breakers. (i.e., you wouldn’t be able to sort by (urgency, relevance) in one query, and (relevance, ease of presentation) in the next unless you modify the rules between the queries (or resort to hacks).
Both of these should be addressed in 3.0, but it may be a few months before that’s production ready. I’m happy to explain my answer further if you’d like to see what it would look like and evaluate the complexity yourself.