Jesse Weaver RDF Management Approaches Joshua Taylor 1

From Semantic Portal Wiki

• Question is for the Presentation: Jesse Weaver RDF Management Approaches
• Question is asked by: Joshua Taylor
• The Question is: In the penultimate paragraph of 2 The SP²Bench Scenario we read, "The table also lists the number #prop. of distinct properties. This value x+y splits into x "standard" attribute properties and y bag membership properties rdf:_1, …, rdf:_y, where y depends on the maximum-sized reference list in the data." The authors also make the point that difficulties are introduced as this number increases. In 3.3 The Purely Relational Scheme it becomes clear that they are capable of representing the references without using containers. It seems that using a container for a reference list rather than relating the paper to the referenced work with dcterms:references (as is done for authors with dc:creator) introduces unnecessary difficulties. Have you any thoughts about why they did this, and whether it alters performance and evaluation?

The Answer from Michael Schmidt

The SP2Bench benchmark was developed to test SPARQL engines with respect to a variety of RDF constructs and SPARQL expressions, among them RDF containers. In fact, the development of this benchmark framework was independent from the analysis presented in the paper. In RS, we might easily represent the reference "position" by an additional position column in the Reference table, but - since it did not play a role in any of the queries - we decided to ignore this attribute. Of course, we could model these reference lists in RDF with multi-valued dcterms:reference attributes instead, but as said before, in the SP2Bench design process it was our intention to create a data set that is rich of interesting RDF constructs.

After all, the experiments show that the VP approach might run into trouble when large lists are present in the data set, which is an insight by its own and would not have been possible with a container-free data set. Imho, this fully justifies our decision.

In case you are interested in benchmark design decisions, you will find more information in the benchmark description TR at http://arxiv.org/abs/0806.4627v1. This work has recently been accepted for publication at ICDE'09.