Re: Future-Proofing for Transition to Multi-Edge caused by Data Arrival

> It beats me how "more complicated, but possible" can be interpreted as
"better".

For my part I didn't mean it is better. But as you stated: "_everything_
can be represented with n-ary relations in plain RDF", so what's the point
of adding complexity to a model that is already powerful enough? That's
also why I would prefer building quoted triples with reification.

> It has some cons:
>  - it needs fully indexed property columns, which some triple stores omit
for optimization
>  - it adds one more join to queries which is always bad
>  - it messes with vocabulary terms, properties more specifically, which
from a usability perspective is not advisable.

I completely agree that those are some legitimate concerns. If this is a
recurring pattern, you need to be able to optimize it. I think I was
confused because I don't quite see how it is directly related to RDF-star.
For me the solution would come from standardizing Singleton Properties (for
this specific case). If there is an agreed upon way of using Singleton
Properties in this case, then we can build optimizations, and even some
syntactic sugar. Here is how I would do it:

Define, for each property `P` and non negative integer `i` a new IRI <
https://w3c.org/indexed/P/i> such that:
```
<https://w3c.org/indexed/P/i> a rdf:Property;
   rdfs:subPropertyOf P;
   rdfs:propertyIndex i.
```
And for all `S` and `O`, the triple `S P O` entails `S <
https://w3c.org/indexed/P/0> O` (the default index is 0).

Since `S <https://w3c.org/indexed/P/0> O` also entails `S P O` (by
`rdfs:subPropertyOf`) then `<https://w3c.org/indexed/P/0>` is equivalent to
`P`. By construction you can always reason on <https://w3c.org/indexed/P/?>
instead of P. Therefore in practice, if your implementation is aware of
this semantics, for each triple you can just add a single new column in
your database for the `propertyIndex` part of the property and skip the
rest. No fully indexed property needed, no additional join query.

Now we can add syntactic sugar over it. For instance:
  - `S P O [i]` for `S <https://w3c.org/indexed/P/i> O`, and
  - `S P O`     for `S <https://w3c.org/indexed/P/0> O`.

That's different from RDF-star though, maybe some RDF-i or something? But
it could be combined with RDF-star to add annotations for instance:
```
<<S P O [1]>> :label "One".
<<S P O [2]>> :label "Two".
```

Using my related proposition on how to desugar quoted triples we would end
up with:
```
<https://w3c.org/reify/S/https:%2F%2Fw3c.org%2Findexed%2FP%2F1/O> a
rdf:Statement;
  rdf:subject S;
  rdf:predicate <https://w3c.org/indexed/P/1>;
  rdf:object O;
  :label "One".

<https://w3c.org/indexed/P/0> a rdf:Property;
  rdfs:subPropertyOf P;
  rdfs:propertyIndex 1.

<https://w3c.org/reify/S/https:%2F%2Fw3c.org%2Findexed%2FP%2F2/O> a
rdf:Statement;
  rdf:subject S;
  rdf:predicate <https://w3c.org/indexed/P/2>;
  rdf:object O;
  :label "Two";

<https://w3c.org/indexed/P/2> a rdf:Property;
  rdfs:subPropertyOf P;
  rdfs:propertyIndex 2.
```

I'll admit some IRIs are not human friendly. But only if you desugar
everything! The syntactic sugar is powerful, concise, predictable enough to
implement a clever optimization, optional for implementors, and all of that
without the need to touch the core semantics of RDF.

Best,
-- 
Timothée