The 9th TREE CG Meeting

2023-11-08 (Teams)

​

TO DO log

1. Issue #88: Extend the member extraction algorithm for named graphs
• Adapt the reference implementation and put it into the TREECG github org
• Do a PR to the spec for this: https://github.com/TREEcg/specification/pull/91
2. 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
3. Plan a separate read-through session with everyone to raise the UX of the spec
• 2 iterations: one with our internal group, second time with a larger audience once initial review is done
• If something needs to functionally change in the spec, that means it should become an issue
4. Attracting more people:
• Sander to remind Redpencil → ACTION for Pieter now
• Pieter to remind Wouter Beek → To be done
• point the W3C CG page to github →
• Contact semweb mailing lists from the moment we reach a decent maturity

Decisions

1. #88 Still time for reviewing needed → TBD on the 29th
2. #89 → Pieter to do a first pull request → TBD on the 29th
3. #86 → PR to be proposed
4. Dates:
1. 22d the first read-through
2. 29th the 10th CG meeting

Roadmap: advancing the spec

1. Smaller issues:
1. More specific spec for redirecting nodes #86
1. PR can be proposed
2. 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

• Issue #76: Adding the not operator as a Relation class
• Issue #85: graph vs. search tree

Roadmap: standardized test suite

Existing work:

• LDES conformance test suite of Xueying
• Tests of the member extraction algorithm
• …

​

Slides and report from last time 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

1. Flag a relation as a subset relation in case we only have one root node
2. Flag a relation as a subset relation from multiple root nodes
3. 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.

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?