7a12
< 1 Both the loader of files and SPARUL internals are flexible enough so it may be more convenient to change different tables depending on parameters:
< * The loader can call arbitrary callback functions for each parsed triple and SPARUL manipulations are configurable via <b>"define output:route" pragma</b> at the beginning of the query.
< 1 Usually there is no need in writing special SQL to "triplify" data from that "wide" tables, because RDF Views will do that
< automatically. Moreover, it's possible to automatically create triggers by RDF Views that will materialize changes in "wide" tables in RDF_QUAD (say, if you need inference).
< 1 So instead of editing <nowiki>RDF_QUAD</nowiki> and let triggers on <nowiki>RDF_QUAD</nowiki> reproduce the changes in wide tables, you may edit wide tables and let triggers reproduce the changes in <nowiki>RDF_QUAD</nowiki>.
< 1 The second approach is much more flexible and it promises better performance due to much smaller activity in triggers. For cluster the second variant is the only possible thing, because fast manipulations with <nowiki>RDF_QUAD</nowiki> are really complicated there.
6d7
> 1. Both the loader of files and SPARUL internals are flexible enough so it may be more convenient to change different tables depending on parameters:
> * The loader can call arbitrary callback functions for each parsed triple and SPARUL manipulations are configurable via <b>"<code>define output:route</code>" pragma</b> at the beginning of the query.
> 1. Usually there is no need in writing special SQL to "triplify" data from that "wide" tables, because RDF Views will do that
> automatically. Moreover, it's possible to automatically create triggers by RDF Views that will materialize changes in "wide" tables in <code><nowiki>RDF_QUAD</nowiki></code> (say, if you need inference).
> 1. So instead of editing <nowiki><code>RDF_QUAD</code></nowiki> and let triggers on <nowiki><code>RDF_QUAD</code></nowiki> reproduce the changes in wide tables, you may edit wide tables and let triggers reproduce the changes in <nowiki><code>RDF_QUAD</code></nowiki>.
> 1. The second approach is much more flexible and it promises better performance due to much smaller activity in triggers. For cluster the second variant is the only possible thing, because fast manipulations with <nowiki><code>RDF_QUAD</code></nowiki> are really complicated there.
5a5
< 1. Our recommendation is to keep <nowiki>RDF_QUAD</nowiki> unchanged and use RDF Views to keep n-ary things in separate tables. The reason is that the access to <nowiki>RDF_QUAD</nowiki> is heavily optimized, and any changes may result in severe penalties in scalability.
4d5
> 1. Our recommendation is to keep <nowiki><code>RDF_QUAD</code></nowiki> unchanged and use RDF Views to keep n-ary things in separate tables. The reason is that the access to <nowiki><code>RDF_QUAD</code></nowiki> is heavily optimized, and any changes may result in severe penalties in scalability.
3a3
< ---++Alternatives for reification for Linked Data publishing usage
2d3
> ---+ Reification Options for Linked Data Publication