Graphs

[rescribet]

The internal APIs already support querying with graphs, but this isn't exposed to the end-user. A lot of work around graphs has been done already and it's a useful feature when considering data from many different sources.

There are two separate but connected concepts to be distinguished; data fetching and data querying. Currently all fetched data ends up in the default graph,

Manipulation

The use-case of graph manipulation probably arises from the possibility to query multiple graphs

• Creation
• Deletion
• Cloning
• Addition
• Subtraction

Querying

What are the options?

Expansion of current API

The current querying API is essentially default implicit.

graph	method
Default implicit	lrs.getResourceProperty
Default explicit	lrs.default.getResourceProperty
Union	lrs.all.getResourceProperty
Named	lrs.named[graph].getResourceProperty

Adding a querying context

The problem can be abstracted into a query context in which the user can tweak the behaviour of the query resolve mechanism, so that the expansion described above doesn't target a specific graph, but rather a set of behaviour including but not limited to the graph. This would make a unified answer to the current question of how to override certain selection behaviour.

From high to low confidence:

interface QueryContext {
  /** What graph(s) should be queried*/
  graph: IRI | IRI[],
  /** Which language(s) strings should be returned*/
  language: string | string[],
  /** What dictionaries should get priority, how are collections handled */
  collation: Collation,
  /** How to handle data fetching, caching, etc */
  network: NetworkStrategy,
  /** Reasoning */
  schema: Schema,
}

interface NetworkStrategy {
  /** Fetching behaviour; 
   * Never, never fetch data
   * Shallow, only when requesting top-level resources
   * Nested, also when resolving property paths
   */
  fetchStrategy: FetchStrategy
  /** The sources to fetch from (e.g. directly, a [bulk] proxy, sparql endpoint, etc) */
  sources: DataSource[]
  /** Caching behaviour; CacheOnly, CacheFirst, NetworkFirst, NetworkOnly */
  cacheStrategy: CacheStrategy,
}

Fetching

Should request/responses be separate from the graphs? This would allow for instantaneous answering of data requests for a certain graph, but implicates an additional complexity in managing the cache