dcat:DataService vs. dcat:Distribution

[pietercolpaert]

At this moment, the TREE specification says a ViewDescription is a dcat:DataService, but the data service always servers exactly 1 dataset (the TREE collection).

We need to open up the discussion whether a dcat:Distribution wouldn’t be more appropriate after all. It would allow us to re-use or extend the forward property dcat:distribution, and use/extend the property dcat:accessURL to point to the root node

[pietercolpaert]

During the 11th TREE CG meeting of 2023-12-20 we discussed a possible resolution to leave DCAT-AP catalog providers the choice:

• A new entity tree:View could be created after all, that is a dcat:Distribution of exactly one tree:Collection. The property tree:hasView could be a sub property of dcat:distribution, linking the tree:Collection to a tree:View.
• tree:ViewDescription remains a sub class of dcat:DataService, but we change the ViewDescription to point at a service configuration that can serve for multiple tree:Views

Another side-effect here, mingling other issues, is that the tree:view property would from then on only be used for traversing nodes, and for linking the tree:Collection to the current page, making #86 not necessary. In order to then know what the root node is, we would explicitly type the tree:Node as tree:RootNode and also create the property tree:rootNode as a sub property of dcat:accessURL. Backwards compatibility could be ensured by moving dcterms:isPartOf and void:subset to the compatibility section, which was the reason they were introduced in the first place. This does however change the semantics of tree:view as it won’t point anymore to a node from which all members can be reached, but I don’t believe that meaning is currently being used in any implementation at this moment. Using tree:view in this way will make it more in line with how Hydra specifies it, and will make e.g., JSON-LD framing and contexts much easier.