Actually, I have two questions related to the topic. The rationale is that my data-part of the runtime model will be comprised of quite a lot of graphs, and I somehow need to avoid enumerating all the relevant ones in the FROM section. I can imagine two approaches: attaching properties to the graphs, and using that in the query, or managing (a) graph collection(s) from the application.
Is there any way to attach properties to a graph aside from creating a (blank) node inside to host those properties? The goal is to restrict the query to graphs that fulfilling some criteria.
This is my best workaround so far, but looks not too promising in terms of performance:
Is there any way to create a metagraph/alias/graph collection similar to stardog:context:named, but where I can specify the graphs to be included (individually or criteria-based)? The description of the Stardog ALIAS looks promising, but it is a little bit unclear. This statement will allow me to use alias-name whenever I would use ... FROM :concrete-graph-1 FROM :concrete-graph-2 FROM concrete-graph-3 ... for example:
Re: 1, yes you can do that but I don't quite see why you'd need a blank node. You can use the graph IRI as the subject in triples when asserting those properties. So the query would look like (assuming you assert those properties in urn:my-graph-config):
select *
{
graph ?g {?s ?p ?o}
{select ?g from <urn:my-graph-config> { ?g a :PrimaryGraph } }
}
That will have some overhead, of course, because of querying for graphs and then joining, but may work OK.
But you're right that 2., i.e. aliases, is the intended mechanism for this stuff. Yes, you can define an alias as a list of graphs and then use that alias IRI in FROM. The query engine frontend would expand it to multiple FROMs and then optimize/execute the query. You should see that expansion in the query plan.
It's less flexible than 1. because there're no graph "properties", just static lists, but there should be no perf overhead compared to manual enumeration in the query.
I have trouble with the query you have suggested for the first approach. A FROM clause in the subquery seems to be a syntax error (although it executes when on its own):
What am I doing wrong here?
As you might have probably guessed, my intention is to have a somewhat more complex property set for the graphs in question than a simple type assertion. Managing multiple static lists to be in sync with the theoretical result of any subquery like in the first approach might become cumbersome quite quickly. For each complex condition instance, I would need to maintain a separate list, and reevaluate each time any involved property changes. Although this part is not planned to be update-heavy a single property change might affect multiple aliases - resulting in either long-running transactions on this side, or dirty-reads on any concurrent query.
But a static list is better than none, of course - and it is a viable option. The thing is that I currently can't know the actual performance implications of the first approach (with your suggestion or with a bearer node). This definitely is a design decision to take with regards to the whole solution.
