tree:ChildRelation needs a value field for tree:StringCompletesRelation

The relation tree:StringCompletesRelation poses a small problem.

To know if the node in question has a child that completes its string with a particular letter / string, now we have to go look at every child node to see if this child contains the string value that we are looking for or to conclude that this completion string value we seek does simply not exist.

If the tree:StringCompletesRelation would also save the child value / all child values in a value field, then we can just filter these child values immediately in the ChildRelation, in the same way that the tree:GreaterThanRelation allows you to decide in the Childrelation which child to follow.

In the case of the tree:StringCompletesRelation, probably there will only be a single relation containing an rdf:List as the tree:child parameter since all the child nodes are connected through the same relation, so in this case either we can put every child in a seperate relation with a specific value, or we could save the value of the child node in the child node itself?

Creating a seperate value array to match the children array is a dangerous thing to do i presume?

I’m not sure what you mean exactly, but let me try to explain why we chose to design it this way

Why the ChildRelation

The reason why we chose to “reify” the childRelation is in fact based on a use case you gave: a single node could have multiple parents from different trees. By introducing the childRelation, we decouple the parent-specific information from the node and put it in the branches, and allow everyone to describe this branch with more properties. It may be noted that this also has the side-effect that you even may describe a lattice using this ontology.

We want to prioritize an easy client-side implementation over an easy server-side generation of the data. Thus I would rather always describe all trees in a similar way, that can be processed by an algorithm that doesn’t need to handle too many special cases. We thus decided to add this reification in all cases, not just in the cases that need a more descriptive relation.

How I think a JavaScript client should process this

When fetching a resource, a bag of triples is returned. We need to go through this list of triples once, looking for predicates like tree:childRelation tree:child tree:value ... And keeping these triples in memory in a hierarchy that suites you. If your resulting javascript object then has to do something like this:

for (var branch in node["childRelation"]) {
    if (branch["@type"].contains('tree:StringCompletesRelation')) {
       newString = oldString + branch.child.value;
    } //... other types  
}

Why adding the tree:value in the tree:ChildRelation is a bad idea

I think we should make a decision once how to model this and stick with it. Allowing a tree:value also in the ChildRelation will overcomplicate having the handle all cases in a generic client, while this would not bring any performance or functional gain, unless you can give a good counter-example of where it’s vital to have a tree:value on the ChildRelation?

TREEcg / specification