The 10th TREE CG Meeting

2023-11-29 (Teams)

​

Agenda

0. Special point: the member extraction paper

• TODO log�⇒ Getting agreed upon work done and assign work
• On-going discussions�⇒ Discussing normative text
• Roadmapping�⇒ planning the work on test cases: #97

TO DO log

• Issue #88: Extend the member extraction algorithm for named graphs
• Reference implementation now at TREEcg/extract-cbd-shape
• PR was adapted slightly still: specification/#91
• Issue #89: README.md
• Add a changelog based on the date of the new publishing and apply semantic versioning
• Adapt the goal of the CG to sprint towards a stable and easy to read 1.0 spec
• on Github, put some more information on how the TREE CG reaches a consensus, and on the calls
• TODO: PR needs to be finished
• Decided on the 29th of November 2024: Sander will have a first go at a PR!
• Issue #86: Redirections
• PR needs to be started
• PC will do this
• Read-through sessions: report
• Abstract changes were done.
• Questions on DCAT-AP were discussed
• Next read-through session next week

​

On-going discussions

• Minor: Issue #76 – Adding the not operator as a Relation class → resolution proposed

​

Bonus issue: #77 ⇒ resolution proposed

​

Side note: Qualified values were at some point part of the spec - not sure anymore why they were removed, but still seems like an interesting idea to Pieter: https://github.com/TREEcg/specification/commit/d5836991b2450ac4129e0f51c2b036dd405976be

​

• Issue #85: graph vs. search tree

​

• Issue #90: conditional imports and importing streams
• Replacing conditional imports: Probably we need something instead to indicate datasets are interlinked (cfr. foreign key relations)

E.g., the stations vs. departures cases – Sensors vs. Observations

​

ON-GOING

Slides and report on issue 85

Search trees have one root node and no cycles

N1

N2

N3

R1.1

R1.2

R2.1

N5

R2.2

N4

It’s generally a good idea to keep the depth is small as possible, as this represents the number of HTTP requests to reach a leaf node

Although we don’t disallow backlinks

N1

N2

N3

R3.1

R3.2

R1.1

R1.2

R2.1

N4

R2.2

R3.3

The actual search tree then depends on where you start

N1

N2

N3

R3.1

R3.2

R1.1

R1.2

R2.1

N4

R2.2

R3.3

The actual search tree then depends on where you start

N1

N2

N3

R3.1

R3.2

R1.1

R1.2

R2.1

N4

R2.2

R3.3

You could for example start from N2 based on the result of filling out a search form

The actual search tree then depends on where you start

N1

N2

N3

R3.1

R3.2

R1.1

R1.2

R2.1

N4

R2.2

R3.3

A client prunes relations that wouldn’t narrow down (or equal) their search space.�When a client wants to broaden their search space, it needs to go back, or even start over.

Summary of #85

Context�tree:Nodes and their tree:Relations can form a graph and not just a search tree

Why? Optional feature of search forms to select the best starting point

Consequence? All clients need to always keep full history of visited nodes

�Challenge�Can we ensure clients don’t need to keep full history part of the cases?

�Proposals

• Flag a relation as a subset relation in case we only have one root node
• Flag a relation as a subset relation from multiple root nodes
• tree:viewBranch relation to annotating this node starts a new disjoint branch in the graph. If all nodes (except for the rootnode) indicate this, it’s a tree

Proposed solution 1

Flag a relation as a subset relation

​

Annotates every relation individually,

​

but multiple entry points are not possible as a subset relation only works starting from 1 specific node

→ There is thus not a need anymore for being able to describe parent or sibling relations. Instead of annotating a subset relation we should probably just annotate all relations in this node are pointing to a disjoint sub-graph

​

​

The SubsetRelation type

As proposed in the initial issue

​

But what would then be the purpose of the sibling relations? I would then just like to be able for a node to indicate it only has red links.

N1

N2

N3

R1.1

R1.2

R2.1

N5

R2.2

N4

tree:SearchTree

= a rootNode + a set of relations

Requirements

• Backwards compatible
• Design: being able to do simple stuff quickly, and raise complexity as you go
• Allowing clients to keep state by not storing the full history, but somehow just keep where they left off

Comments

Sander:

​

It’s not true that you always have to start from the root node, in this case, you just have to understand that you didn’t start from the root node, but you still have a way to reach it by following non-subset-relations.

Proposed solution 2: extension of 1

Flag each relation with from which root node it originates

Annotates every relation individually,

multiple entry points become possible because it annotates the specific values for which is holds true

​

Every relation then keeps a list of their origin root node… and maybe their full path to reach it then?

N1

N2

N3

R3.1

R3.2

R1.1

R1.2

R2.1

N4

R2.2

R3.3

N2, N3

N3

N3

N1, N2

N2

N1

N1

Comments

• Would make sense to link it to the view instead of the first node
• This is a solution though for having 2 views in a pagination: starting from the end of starting from the beginning

Proposed solution 3

Don’t introduce an annotation of the relation,

but introduce a new way of saying what a node is wrt the collection

​

• tree:viewBranch property can introduce the fact that this node is a view in a branch
• This becomes a more specific property than using void:subset or dcterms:isPartOf that were awfully unspecific and outside the TREE spec

​

tree:viewBranch

<C1> tree:view <N1>

<C1> tree:viewBranch <N2>

<C1> tree:viewBranch <N3>

R3

R1.1

R1.2

<C1> tree:viewBranch <N4>

A new tree-specific property to link a collection to a node

<C1> tree:view <Node1> �From this node all members can be reached. This is a rootnode in the search tree (if it is a tree). This is only mentioned when entering the tree.

​

<C1> void:subset | ^dcterms:isPartOf <GraphNode1>

→ properties cfr. Triple Pattern Fragments: subset of

→ a part of all members can be viewed from here, but on this node, you will need to check whether the relations point to something that was already visited or not

​

<C1> tree:viewBranch <ChildNode1> .

→you don’t need to bother about things that happened before this node.

NEW

Possible future feature: composite collections and views?

Thomas’ user story:

​

I want to define a collection as an aggregation of multiple collections, and still use the individual existing views as a way to query over the composite collection

​

Julián: but shouldn’t that be moved to simply source selection?

ON-GOING

issue 90 on conditional imports

TODO

PLANNED

Standardized test cases

​

issues/97