Open pietercolpaert opened 6 months ago
During the 11th TREE CG meeting of 2023-12-20 we discussed a possible resolution to leave DCAT-AP catalog providers the choice:
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:View
sAnother 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.
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