Expose information about the LDES and their views

[pietercolpaert]

Some data that should be exposed about the LDES IRI that has been identified by the client:

1. Properties based on the dcat:Dataset class (an ldes:EventStream is a subClassOf a dcat:Dataset): https://www.w3.org/TR/vocab-dcat-3/#Class:Dataset
2. Properties based on the tree:Collection (an ldes:EventStream is a subClassOf a tree:Collection), mainly being the tree:shape, and point to the tree:viewDescription.
3. Properties based on ldes:EventStream itself, mainly timestampPath, versionOfPath

Then we should also extract view specific information:

1. Wrt DCAT, see properties on dcat:Distribution https://www.w3.org/TR/vocab-dcat-3/#Class:Distribution
2. LDES based properties on the view: which mainly will be the retention policy today

In the future we also need to be able to understand an LDES is a derived version of an existing LDES and a way to indicate that.

Any suggestions on method signatures or events to emit?

[kkostov]

The current signature to obtain members of a stream is client.stream({ some config }).getReader() and iterate over the reader.

Perhaps we can imagine a method client.getCollectionInfo(). The method returns a promise which resolves to an object (dictionary) combining the above properties:

{
    "dataset": {
        "identifier": "", <-- required
        "description": "", <-- not required in DCAT v3 so this value is nilable (may not be present)
       ... additional nilable fields from DCAT
    },
    "stream": {
        "timestampPath": "Path to timestamp property", <-- required
        "versionOfPath": "Path to versionOf property (if applicable)" <-- required
    },
   "collection": {
        "shape": "path to shape", <-- required?
        "viewDescription": "...", <-- nilable
    }
}

This can be JSON-LD as long as retrieving or parsing a context linked properties is not immediately required by the consumer.

This is what we'd need to satisfy the use-case for the ldes-registry visualization as it allows us knowledge of fields (the non-nilable ones) and we can optionally check for presense for known fields like descriptions to render the endpoint card.