The second W3C TREE CG meeting
2023-06-07
Agenda
WHO IS WHO?
Member Extraction
What’s a tree:Member?
A tree:Member is a Set of triples.
The triples that are part of the set is defined by “the member extraction algorithm” (see further).
tree:member refers to the primary topic of a member that can be used to extract the member. This is not an ID for the tree:Member itself.
URIs of your entities
tree:Collection
tree:member
...
Member extraction algorithm
The algorithm that extracts all triples of M from a set of triples (such as an RDF1.0 page representing a Node, or a message on a pubsub channel).
Option 1: use CBD
https://www.w3.org/Submission/CBD/
include blank nodes,
don’t include named nodes
Is being used by DESCRIBE in SPARQL
→ people know this logic, but it’s not a MUST
Limitations: only star-shape patterns would be supported
Option 2: use CBD + shapes
If a SHACL shape is given, you may find all the triples of a member by exactracting the SHACL shape from the page (and optionally dereferencing the member)
Limitation: evaluating the SHACL shape for every member is going to be slow
Will it? https://www.bergnet.org/2023/03/2023/shacl-engine/
Option 3: extract all forward triples, but don’t embed
Option 4: A named graph based tree:Collection
This changes the behaviour of the tree:member property as the tree:member property will refer to a named graph identifier the actual tree:Member. The named graph contains in this page a complete set of triples of this member.
The member extraction algorithm is by-passed: the triples relevant here are the ones extracted from this named graph.
<#Collection1> a tree:NamedGraphCollection, ldes:EventStream ;
tree:member <G1>, <G2>, <G3> … .
<G1> a tree:Member ; foaf:primaryTopic <A> .
<G1> { <A> a foaf:Person . }
The dereference members view flag
Influences the member extraction algorithm to also perform a GET HTTP request on the tree:member’s object, and perform the member extraction algorithm from the triples found on that page.
Needs to be set on a view description or a tree:Node:
<#ViewDescription1> tree:dereferenceMembers "true" .
Or should we add a tree:dereferencePath on the view, that also may indicate deeper nested properties to be dereferenced?
<#ViewDescription1> tree:dereferencePath ( loc:geometry ) .�use case: http://marineregions.org/feed.ttl
new
Any other business
Are there… any remarks on running the group?
Any existing implementations you want to mention?
Any other issues that require prioritization?�
When are we going to hold the next call?
⇒ Wednesday 21st of June at 15 CEST