Research how (and where) to define what data to retrieve

[Simon-Dirks]

Two high-level responsibilities:

1. Defining what data to retrieve from the LD endpoints/graphs. E.g. are there certain extra hops that need to be made to retrieve specific properties? What inverse relationships do we want to retrieve for certain nodes?
2. Querying the required data from the LD endpoints/graphs.

The "original" (fully browser-based) Valeros did both at the presentation layer:

• Configuration files allowed tweaking of what properties to retrieve (responsibility 1).
• Real-time/async SPARQL queries made additional hops or retrieved inverse properties where needed (responsibility 2).
• Data available at the node-level is/was optionally retrieved through an elastic index for fast initial search hits (responsibility 2, through a different route).

Who is responsible for defining what data to retrieve?

With the new (more modular) architecture, I can imagine it makes sense to move the responsibility of defining what data to retrieve to the data layer, so the presentation layer(s) simply receives a "clean" DTO and can take it from there, focused on how to display the data instead of both how + what to display. In this sense, each data layer exposes a "new" dataset of sorts on top of which presentation layers can be built, which I believe matches NDE's envisioned architecture.

Note

Does the presentation layer internally then still need to work with linked data standards? Or can we, at this point, work with simple JSON objects? Sjors was wondering the same thing, will keep this in mind during dev.

How to define what data to retrieve?

We'll need some sort of standard for defining what properties we expect to be of interest to end users and want to query for. In essence, you could consider this a problem of graph querying, so initial thoughts went to SPARQL and GraphQL as existing graph query languages.

Example 1: Details of creator/authors of this node (one hop).

flowchart LR
    Node -->|dc:creator| Person
    Node -->|schema:author| Person
    Person -->|schema:givenName| GName{""Jane""}
    Person -->|schema:familyName| FName{""Doe""}
    Person -->|schema:birthDate| BDate{""1990-05-15""}

Loading

• SPARQL property paths: dc:creator|schema:author/(schema:givenName|schema:familyName|schema:birthDate|schema:deathDate)
• GraphQL: ...

Example 2: Details of authors/creators of documents about this node (two hops, including inverse)

flowchart RL
    Doc -->|schema:about| Node
    Doc -->|schema:mentions| Node
    Person -->|schema:author| Doc
    Person -->|dc:creator| Doc
    Person -->|schema:givenName| GName{""Jane""}
    Person -->|schema:familyName| FName{""Doe""}
    Person -->|schema:birthDate| BDate{""1990-05-15""}

Loading

• SPARQL property paths: ^(schema:about|schema:mentions)^(schema:author|dc:creator)/(schema:givenName|schema:familyName|schema:birthDate|schema:deathDate)
• GraphQL: ...

[Simon-Dirks]

Yesterday, I've gone deeper into if LDkit might be an appropriate toolkit for this use case, creating data schemas for the data layer to define what we want to retrieve. This easily supports hops (nested syntax), inverse properties, etc. Importantly: taking it from LDkit Schema → actual querying becomes very straightforward implementation-wise.

[ddeboer]

Yes, I’ve been using LDKit myself with pleasure, but note that it’s far from feature-complete.

An alternative, more standards-based approach is to define UI elements for RDF with SHACL 1.2 User Interfaces. See e.g. https://ontologist.substack.com/p/creating-forms-and-views-with-shacl for an introduction.