This HTML5 document contains 30 embedded RDF statements represented using HTML+Microdata notation.

The embedded RDF content will be recognized by any processor of HTML5 Microdata.

Subject Item

n7:this

foaf:made

n2:VirtTipsAndTricksGuideReificationAltern

Subject Item

n11:this

sioc:creator_of

n2:VirtTipsAndTricksGuideReificationAltern

Subject Item

n17:item

n16:services_of

n2:VirtTipsAndTricksGuideReificationAltern

Subject Item

n15:this

sioc:creator_of

n2:VirtTipsAndTricksGuideReificationAltern

Subject Item

n5:VOS

sioc:container_of

n2:VirtTipsAndTricksGuideReificationAltern

atom:entry

n2:VirtTipsAndTricksGuideReificationAltern

atom:contains

n2:VirtTipsAndTricksGuideReificationAltern

Subject Item

n2:VirtTipsAndTricksGuideReificationAltern

rdf:type

sioct:Comment atom:Entry

dcterms:created

2017-06-13T05:38:47.980611

dcterms:modified

2019-12-05T15:04:46.257270

rdfs:label

VirtTipsAndTricksGuideReificationAltern

foaf:maker

n7:this n14:this

dc:title

VirtTipsAndTricksGuideReificationAltern

opl:isDescribedUsing

n13:rdf

sioc:has_creator

n15:this n11:this

sioc:content

%META:TOPICPARENT{name="VirtTipsAndTricksGuide"}% ---+ Reification Options for Linked Data Publication 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. 1. Triggers should be possible as well, but it is relatively cheap to "redirect" data manipulations to other tables. 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. ---+++Related * [[VirtTipsAndTricksGuide][Virtuoso Tips and Tricks Collection]]

sioc:id

64ebd5bbdcc7a032152c0dd7c233c56c

sioc:link

n2:VirtTipsAndTricksGuideReificationAltern

sioc:has_container

n5:VOS

n16:has_services

n17:item

atom:title

VirtTipsAndTricksGuideReificationAltern

sioc:links_to

n2:VirtTipsAndTricksGuide

atom:source

n5:VOS

atom:author

n7:this

atom:published

2017-06-13T05:38:47Z

atom:updated

2019-12-05T15:04:46Z

sioc:topic

n5:VOS