You might want to consider the start of this tutorial.

Short introductions to other TF datasets:

• Dead Sea Scrolls,
• Old Babylonian Letters,

or the

• Quran

Relationships¶

There are relationship between objects that are about their identities, the way they occupy space, and the way they are connected.

Are two objects the same, do they occupy the same slots, do they overlap, is one embedded in the other, does one come before the other? Is there an edge from one to another?

Although these relationships are easy to define, and even easy to implement, they may be very costly to use. When searching, most of them have to be computed very many times.

Some of them have been precomputed and stored in an index, e.g. the embedding relationships. They can be used without penalty.

Other relations are not suitable for pre-computing: most inequality relations are of that kind. It would require an enormous amount of storage to pre-compute for each node the set of nodes that occupy different slots. This type of relation will not be used in narrowing down the search space, which means that it may take more time to get the results.

We are going to test all of our relationships here.

Let us first see what relationships we have:

The top of the list are identity and spatial relationships. We are going to discuss them. They are documented in relationships

The bottom of the list are relationships defined by the edge features of your dataset. We have discussed them in advanced.

Identity and order¶

= equal as node¶

The = means that both parts are the same node. Left and right are not two things with similar properties, no, they are one and the same thing.

Useful if the thing you search for it part of two wildly different patterns.

We show the results with the first clause in magenta and the second sentence in cyan.

Note that the first and the second sentence may be the same sentence!

And observe that the last clause is the same one as the first one, hence they have the same color.

# unequal as node¶

n # m if n and m are not the same node.

If you write a template, and you know that one node should come before another one, consider using < or >, which will constrain the results better.

We have seen this in action in the search for gapped phrases.

< and > canonical order¶

n < m if n comes before m in the canonical ordering of nodes.

We have seen them in action before.

Space occupation¶

We show that the following relationships also work with custom sets, as introduced in the search Advanced tutorial.

We make two custom sets, common and rare, consisting of nodes whose contained slots have all common lexemes or some rare lexemes, like we did in search Advanced.

Now we can do all kinds of searches within the domain of common and rare things.

We give the names to all the sets and put them in a dictionary.

Expert remark

Note that these sets contain both slot nodes and non-slot nodes. The code that implements the basic relationship is heavily optimized and contains case distinctions as to whether nodes are slot or non-slot. For ordinary node types, it is clear on beforehand whether its nodes are slot or non-slot, but custom sets may contain both.

So our frequent and infrequent sets are good tests whether the basic relationships are correctly implemented.

== same slots¶

Two objects are extensionally equal if they occupy exactly the same slots.

Now a similar query with the custom sets:

As a check we compute manually the maximum rank of the lexemes in the clauses yielded by the query without the custom sets:

&& overlap¶

Two objects overlap if and only if they share at least one slot. This is quite costly to use in some cases.

We are going to find the sentences that overlap with two verses.

Explanation: the query looks for sentences and delivers results that are tuples with only a sentence node.

This is because the stuff within the /with/ quantifier does not contribute to the result tuples.

The /with/ quantifier poses a few restrictions on its parent, the sentence.

From within the quantifier you can refer to the parent by ...

The condition is that there are verses v1 and v2 that have overlap with the sentence, and that v1 comes before v2.

The result is a tuple of exactly the sentences that span multiple verses.

Now with custom sets:

The following query has the same results but is less insightful.

## not the same slots¶

True when the two objects in question do not occupy exactly the same set of slots. This is a very loose relationship.

We look for sentences that start with a sentence atom that is not co-extensive with its sentence.

Now in the common domain.

|| disjoint slots¶

True when the two objects in question do not share any slots. This is a rather loose relationship.

This can be used for locating gaps: a textual object that lies inside a gap of another object. See also gaps.

Here we check whether there are phrases with disjoint subphrases.

Now in the common domain.

We see that Genesis 1:1 has fallen out. Let's check the ranks of the lexemes of its last phrase:

There you have it: the heavens are rare!

[[ and ]] embedding¶

n [[ m if object n embeds m.

n ]] m if object n lies embedded in m.

These relations are used implicitly in templates when there is indentation:

s:sentence
  p:phrase
    w1:word gn=f
    w2:word gn=m

The template above implicitly states the following embeddings:

• s ]] p
• p ]] w1
• p ]] w2

We have seen these relations in action.

Positioning¶

<< and >> before and after (slot-wise)¶

These relations test whether one object comes before or after an other, in the sense that the slots occupied by the one object lie completely before or after the slots occupied by the other object.

In the common domain: