My issues with graph-based RDF Star

Hi group,

Thomas asked me to clarify how I use graphs. I employ them in various 
ways, but let me illustrate with two examples:

## Open Data Endpoint with Multiple Stakeholders & Named Graphs

For the Swiss government, we operate a large Stardog instance. Multiple 
ETL pipelines from diverse stakeholders update graphs in this single 
endpoint, running at different frequencies. Access is managed via ACLs 
on the named graphs [1], utilizing Stardog's security layer based on 
Apache Shiro and role-based access control [2]. Pipelines have the 
flexibility to choose their methods of writing into the triplestore, but 
most utilize the SPARQL Graph Store Protocol, typically writing to 
specific graphs through PUT operations, as the primary data source is 
often external.

Each stakeholder is allocated one or more named graphs with write 
permissions. While most graphs are public and accessible via a generic 
read-user, either as named graphs or through the union default graph, 
some are restricted for staging purposes and are not visible in the 
public default graph.

Graph names follow a defined scheme, and user, role, and permission 
management is automated.

I don't see how I could use a graph based RDF-Star model here. We never 
write quads, if I would want to do an RDF Star statement, I would expect 
it to be part of a triple-representation. If this would not be the case, 
it would IMO break the design of this use-case.

In that regard, would a quad based model not by definition break SPARQL 
Graph Store protocol?

## Named Graphs as "Documents"

Another scenario, not directly mine but observed in two companies we 
collaborated with, involves treating RDF data as "documents". These 
companies do not use SPARQL directly. Instead, they load data into an 
Elastic/Opensearch index for efficient reads, as the data is relatively 
static. Occasional writes are handled by middleware that updates the 
triplestore.

In this model, the triplestore essentially functions as an RDF document 
store, with each document represented as a graph. These graphs group 
"key-values," which are then indexed as documents in Elastic, 
transforming each graph into an elastic document.

In both cases, I was restricted from creating additional graphs, as each 
graph was treated as a separate document.

One could argue that using RDF Star in such a scenario might not make 
sense in the first place. But the same challenges as mentioned above 
would still apply IMO.


[1]: 
https://docs.stardog.com/operating-stardog/security/named-graph-security
[2]: https://docs.stardog.com/operating-stardog/security/security-model

regards

Adrian

-- 
Adrian Gschwend
CEO Zazuko GmbH, Biel, Switzerland

Phone +41 32 510 60 31
Email adrian.gschwend@zazuko.com

Received on Friday, 8 December 2023 10:57:18 UTC