[
https://issues.apache.org/jira/browse/JENA-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17402553#comment-17402553
]
Andy Seaborne commented on JENA-2152:
-------------------------------------
Yes - it can be done.
If it is for security, there is the graph-level access control:
https://jena.apache.org/documentation/fuseki2/fuseki-data-access-control.html#graph-acl
. This also works when the default graph is the union of all named graphs -
only the permitted named graphs are in the union view.
Another way is to use an assembler to describe the setup. Any combination of
named graphs can be combined into a single graph view of the union with a
UnionModel assembler.
Full example attached which sets up a dataset for an endpoint that is a view of
the underlying database. There can also be a Fuseki service with update
endpoints to go directly to the database.
The database setup is:
{noformat}
:dataset rdf:type ja:RDFDataset ;
ja:defaultGraph :graphMyUnion ;
.
:graphMyUnion rdf:type ja:UnionModel ;
ja:rootModel [ rdf:type tdb2:GraphTDB2 ; tdb2:dataset :dataset_tdb2 ; ] ;
ja:subModel :graph1 ;
ja:subModel :graph2 ;
.
## Graphs out of DB2.
:graph1 rdf:type tdb2:GraphTDB2 ;
tdb2:graphName "http://example/ng1"; ;
tdb2:dataset :dataset_tdb2 ;
.
:graph2 rdf:type tdb2:GraphTDB2 ;
tdb2:graphName "http://example/ng2"; ;
tdb2:dataset :dataset_tdb2 ;
.
:dataset_tdb2 rdf:type tdb2:DatasetTDB2 ;
tdb2:location "database area" ;
.
{noformat}
> Persisting constituent named graphs config for default graph of custom
> dataset view.
> ------------------------------------------------------------------------------------
>
> Key: JENA-2152
> URL: https://issues.apache.org/jira/browse/JENA-2152
> Project: Apache Jena
> Issue Type: New Feature
> Components: Fuseki
> Reporter: damodara
> Priority: Major
> Labels: SPARQL, dataset, defaultGraph, fuseki
> Attachments: tdb2-union.ttl
>
>
> Namaste. Thanks for work on jena.
> Presently we can specify custom dataset for a sparql query with {{FROM}} and
> {{FROM NAMED}} declarations, whose default-graph is merge of graphs declared
> with {{FROM}}, and whose named graphs are individual named graphs declared
> with {{FROM NAMED}}.
> This pattern works fine until we have to search among merge of small number
> of named graphs, by enumerating all of them with {{FROM}}. But if we have to
> search across merge of thousands of small named graphs (like those,
> trusted-by-an-authority, extracted-from-specific-resources,
> have-certain-provanence), then it won’t scale to mention all of those
> constituent graphs of custom default graph in every sparql query.
>
> One obvious solution is giving this custom default graph an `IRI`, and
> describe it's component named graphs with minimal vocabulary. BlazeGraph
> follows this pattern, which they call as [Virtual
> Graphs|https://github.com/blazegraph/database/wiki/VirtualGraphs].
>
> And Virtuoso has [Graph
> Groups|http://docs.openlinksw.com/virtuoso/rdfgraphsecuritygroups/] feature
> to address this.
>
> It would be very useful if jena support such virtual default graphs easily
> Thanks again for great work.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
