The TREE profile spec

[pietercolpaert]

See #118

[pietercolpaert]

During the call of 2025-04-02:

• @smessie proposed to also add support for having relations at the end of the page.

We will not merge this PR just yet, and await merging it until the feature has been added.

[pietercolpaert]

We probably also want to mention it from the MEA section in the spec as well in this PR.

[pietercolpaert]

I also wonder whether we need to allow for a non HTTP header method for discovering the fact the profile was used. E.g., should we allow detecting it from the fact the URL contains .tree.ttl?

[pietercolpaert]

TODO for this PR

• [x] Allow for tree:Relations at the end of the file
• [x] Mention this profile in the section on the Member Extraction Algorithm in the main spec
• [x] Discuss file extension as a fallback to the header option

[smessie]

I also wonder whether we need to allow for a non HTTP header method for discovering the fact the profile was used. E.g., should we allow detecting it from the fact the URL contains .tree.ttl?

I wouldn't make such extension mandatory, but I like the idea to not have to rely on solely an HTTP header. Would again be beneficial in those cases where the publisher has no influence in the headers being set.

[pietercolpaert]

@smessie in order to allow hypermedia relations and ldes:immutable at the end, I would propose that we open a hypermedia block each time after a ex:collection tree:view <> triple. What do you think?

[smessie]

@smessie in order to allow hypermedia relations and ldes:immutable at the end, I would propose that we open a hypermedia block each time after a ex:collection tree:view <> triple. What do you think?

Why did you choose for a tree:view instead of tree:relation? I think tree:view might still be something that you want to define as soon as you create a new Node, resulting it to be at the top. While, a tree:relation is usually added later, if not one of the last changes in the Node, resulting it to be at the end when using append.

[pietercolpaert]

Because it’s more general as a trigger for hypermedia: e.g., if you have no more relations but only an immutable indication, it still works. The tree:view triple is useful in every page and it doesn’t hurt to repeat it

[ajuvercr]

Would it also work to just look for the subject of triples? Triples with the subject <> or the ldes identifier, denote a new section, either member or metadata?

[pietercolpaert]

Would it also work to just look for the subject of triples? Triples with the subject <> or the ldes identifier, denote a new section, either member or metadata?

Triples in which the base IRI is used would work I think, although that makes it of course impossible for members to use the page’s URL in the members. Is it reasonable to assume the base IRI is not going to be used in members? It might be a tedious to debug edge case if someone would run into it. Not allowing the tree:view and tree:member property inside the members seems slightly more safe, but might also not be 100% fool proof of course.

I wouldn’t rely on the collection IRI, because then of course you must know the tree:Collection’s identifier, which is not the case when dereferencing the root node based on its URL.

[smessie]

The collection’s identifier is used as the subject for the tree:member triple. Therefore, if we are certain that we only want to use the base IRI (fragment IRI), this approach won’t work out of the box.

I now understand the advantage of using a triple like tree:view. Since RDF uses set semantics, it shouldn’t be a problem to include it multiple times.

However, it’s not as straightforward for a publisher to adopt this approach (as they’ll now have to add duplicate tree:view triples solely for the purpose of the TREE profile). Explicitly detecting new sections using tree:relation and ldes:immutable is more suitable for publishers, but the tree:view approach is clearer for clients and more future-proof. New metadata properties won’t require explicit support to be implemented.

If we could detect a new section differently, like using the subject of the triples (which I found an interesting suggestion!), it might still be a better alternative. However, regarding the subject of triples idea, I believe it could lead to too many potential complications, as was highlighted.

[pietercolpaert]

I now proposed in the PR a hybrid approach: