Add qualified pattern for geospatial or period based look-ups

[pietercolpaert]

Example and motivation

<first.ttl> a tree:Node ;
            tree:relation  [
                 a tree:GeospatiallyContainsRelation ;
                 tree:node <second.ttl> ;
                 tree:path (lc:departureStop geosparql:asWKT) ;
         tree:import <stops.ttl> ;
                 tree:qualifiedValue [
                a tree:Value ;
                tree:value <https://cityshapes.com/#City1> ;
                    tree:path (geosparql:geometry geosparql:asWKT);
                                tree:import <https://cityshapes.com/>
                 ]
            ].

In this example, instead of using a tree:value right away, we add a tree:qualifiedValue that has the predicate tree:value to an entity instead of a literal value. The literal value can be found in the entity itself with tree:value. The tree:path used, refers to how an existing boundary can be used and interpreted from the tree:import file on the value’s subject.

This is interesting for very complex and computationally more expensive tasks. When a client encounters <https://cityshapes.com/#City1>, it may reuse the shape from a previous calculation. Furthermore, when it geospatial Linked Data descriptions are precalculated, a client may reason over these without having to calculate the relation at all. For example: when I’m looking for entities in Belgium, and the client already knows Ghent is in Belgium, it doesn’t need to compare the boundaries of Ghent and Belgium again.

Mutatis mutandis for named periods in time.

Terms to be introduced and spec changes proposed

• [x] tree:qualifiedValue
• [x] tree:import
• [x] tree:Value

Non-normative remark: while this is possible, using literal values with (simple) geometries are prefered.

[pietercolpaert]

Possibly this involved having to change the range of tree:value as well? https://github.com/TREEcg/specification/blob/master/tree.ttl#L112