Indirect collections

[pietercolpaert]

User stories and problems

1. As a publisher of a dcat:Catalog with dcat:Datasets, I want to paginate the catalog in different ways, to find dataset objects without having to redefine a dcat:Catalog as a tree:Collection with tree:members
2. As the creator of the TREE specification, I do not want to specify each possible collection design (AS2, LDP, Hydra, ...) in the spec, but I want a technique to tell a TREE client how to derive TREE semantics from an existing collection design
3. As a data publisher that doesn’t need TREE-specific features just yet, I don’t want to add extra triples just in case I’m going to need it, but I do want the TREE tools to work with my Linked Data file regardless, and also interpret for example LDP/AS2/HTTP Link rel=next/Hydra paging.

Possible solution

In order to cover US1, we’d need a way to merely describe the containment property. The rest can be automatically inferred.

E.g.:

:Catalog a dcat:Catalog;
    dcat:dataset :A, :B, :C .

If we add 1 triple or header saying:

:Catalog tree:containmentPath dcat:dataset .

Then we can infer that :Catalog is a tree:Collection, and the current @base is a dcterms:isPartOf the :Catalog. The <> can then be extended with tree:Relations and the likes.

In order to tackle US2 and US3 we can work with a default value: we can maintain a list of a default containment path that must be checked. This can be for example:

:Collection tree:containmentPath [sh:alternatePath (tree:member as:item hydra:member ldp:contains) ]

ISSUE: for AS2, the items are contained on a view, and not on the collection. How do we deal with that?

[pietercolpaert]

Another use case is where I don’t at all have a collection / membership defined in a file, but I still want to indicate from a previous file how to set the targets of the member extraction algorithm. This could be useful to make regular files or data dumps more easily part of the TREE ecosystem by providing a bit of external context.