Ne plus utiliser le default graph

Comme l'explique très bien [cet article](https://blog.metaphacts.com/the-default-graph-demystified), la spec actuelle de SPARQL ne permet pas de facilement sélectionner le graph par défaut. L'article recommande au final de ne pas utiliser le default graph:

> Until this is resolved, however, a simple trick to avoid the problem in the first place is this: always use a named graph to add your data. Don’t rely on the default graph.

@nikoPLP confirme que ce serait mieux de n'avoir que des named graph.

Les avantages seraient des requêtes plus lisibles et plus performantes. Pour rechercher à la fois sur le graph principal (graph par défaut) et le graph miroir, il suffirait de faire ça (les lignes importantes sont celles commençant par `FROM`):

```sparql
PREFIX ldp:
PREFIX pair:
CONSTRUCT {
?s1 ?p1 ?o1.
?s1 pair:hasLocation ?se2f1423562035830ba0bc9f64fa5b561.
?se2f1423562035830ba0bc9f64fa5b561 ?pe2f1423562035830ba0bc9f64fa5b561 ?oe2f1423562035830ba0bc9f64fa5b561.
?se2f1423562035830ba0bc9f64fa5b561 pair:hasPostalAddress ?seee8d9476de0ffb03e7f91283ffe6ae8.
?seee8d9476de0ffb03e7f91283ffe6ae8 ?peee8d9476de0ffb03e7f91283ffe6ae8 ?oeee8d9476de0ffb03e7f91283ffe6ae8.
?s1 pair:organizationOfMembership ?s3fc64308af5e2b95c72d7488ef20c980.
?s3fc64308af5e2b95c72d7488ef20c980 ?p3fc64308af5e2b95c72d7488ef20c980 ?o3fc64308af5e2b95c72d7488ef20c980.
}
FROM # Named graph qui remplacerait le default graph
FROM # Seule ligne nécessaire pour ajouter le graph mirror dans la requête
WHERE {
FILTER(?containerUri IN())
?containerUri ldp:contains ?s1.
FILTER(ISIRI(?s1))
{ ?s1 ?p1 ?o1. }
UNION
{
?s1 pair:hasLocation ?se2f1423562035830ba0bc9f64fa5b561.
?se2f1423562035830ba0bc9f64fa5b561 ?pe2f1423562035830ba0bc9f64fa5b561 ?oe2f1423562035830ba0bc9f64fa5b561.
}
UNION
{
?se2f1423562035830ba0bc9f64fa5b561 pair:hasPostalAddress ?seee8d9476de0ffb03e7f91283ffe6ae8.
?seee8d9476de0ffb03e7f91283ffe6ae8 ?peee8d9476de0ffb03e7f91283ffe6ae8 ?oeee8d9476de0ffb03e7f91283ffe6ae8.
?s1 pair:hasLocation ?se2f1423562035830ba0bc9f64fa5b561.
}
UNION
{
?s1 pair:organizationOfMembership ?s3fc64308af5e2b95c72d7488ef20c980.
?s3fc64308af5e2b95c72d7488ef20c980 ?p3fc64308af5e2b95c72d7488ef20c980 ?o3fc64308af5e2b95c72d7488ef20c980.
}
}
```

Alors qu'actuellement une bonne partie de la requête WHERE doit être doublée via un UNION:

```sparql
PREFIX ldp:
PREFIX pair:
CONSTRUCT {
?s1 ?p1 ?o1.
?s1 pair:hasLocation ?se2f1423562035830ba0bc9f64fa5b561.
?se2f1423562035830ba0bc9f64fa5b561 ?pe2f1423562035830ba0bc9f64fa5b561 ?oe2f1423562035830ba0bc9f64fa5b561.
?se2f1423562035830ba0bc9f64fa5b561 pair:hasPostalAddress ?seee8d9476de0ffb03e7f91283ffe6ae8.
?seee8d9476de0ffb03e7f91283ffe6ae8 ?peee8d9476de0ffb03e7f91283ffe6ae8 ?oeee8d9476de0ffb03e7f91283ffe6ae8.
?s1 pair:organizationOfMembership ?s3fc64308af5e2b95c72d7488ef20c980.
?s3fc64308af5e2b95c72d7488ef20c980 ?p3fc64308af5e2b95c72d7488ef20c980 ?o3fc64308af5e2b95c72d7488ef20c980.
}
WHERE {
FILTER(?containerUri IN())
?containerUri ldp:contains ?s1.
FILTER(ISIRI(?s1))
{
{ ?s1 ?p1 ?o1. }
UNION
{
?s1 pair:hasLocation ?se2f1423562035830ba0bc9f64fa5b561.
?se2f1423562035830ba0bc9f64fa5b561 ?pe2f1423562035830ba0bc9f64fa5b561 ?oe2f1423562035830ba0bc9f64fa5b561.
}
UNION
{
?se2f1423562035830ba0bc9f64fa5b561 pair:hasPostalAddress ?seee8d9476de0ffb03e7f91283ffe6ae8.
?seee8d9476de0ffb03e7f91283ffe6ae8 ?peee8d9476de0ffb03e7f91283ffe6ae8 ?oeee8d9476de0ffb03e7f91283ffe6ae8.
?s1 pair:hasLocation ?se2f1423562035830ba0bc9f64fa5b561.
}
UNION
{
?s1 pair:organizationOfMembership ?s3fc64308af5e2b95c72d7488ef20c980.
?s3fc64308af5e2b95c72d7488ef20c980 ?p3fc64308af5e2b95c72d7488ef20c980 ?o3fc64308af5e2b95c72d7488ef20c980.
}
}
UNION
{
GRAPH {
{ ?s1 ?p1 ?o1. }
UNION
{
?s1 pair:hasLocation ?se2f1423562035830ba0bc9f64fa5b561.
?se2f1423562035830ba0bc9f64fa5b561 ?pe2f1423562035830ba0bc9f64fa5b561 ?oe2f1423562035830ba0bc9f64fa5b561.
}
UNION
{
?se2f1423562035830ba0bc9f64fa5b561 pair:hasPostalAddress ?seee8d9476de0ffb03e7f91283ffe6ae8.
?seee8d9476de0ffb03e7f91283ffe6ae8 ?peee8d9476de0ffb03e7f91283ffe6ae8 ?oeee8d9476de0ffb03e7f91283ffe6ae8.
?s1 pair:hasLocation ?se2f1423562035830ba0bc9f64fa5b561.
}
UNION
{
?s1 pair:organizationOfMembership ?s3fc64308af5e2b95c72d7488ef20c980.
?s3fc64308af5e2b95c72d7488ef20c980 ?p3fc64308af5e2b95c72d7488ef20c980 ?o3fc64308af5e2b95c72d7488ef20c980.
}
}
}
}
```

No repository files, tests, or implementation entry points are named; begin by locating the SPARQL query and graph-storage code corresponding to the main and mirror graph URIs. Done would mean consistently using named graphs instead of the default graph and validating that queries covering both graphs still return the intended data.

Written by the indexing model from the issue text.