--- a/rdf-dataset/index.html Tue Sep 17 09:30:31 2013 +0200
+++ b/rdf-dataset/index.html Tue Sep 17 10:00:27 2013 +0200
@@ -147,7 +147,7 @@
<li>the triples of the named graphs are considered part of the knowledge of the default graph;</li>
<li>different named graphs indicate different "contexts", or different "worlds", and the triples inside a named graph are assumed to be true in the associated context only; in this case, the default graph can be interpreted as yet another context, or be considered as a "global context" which must hold in all contexts;</li>
<li>the named graphs are considered as "hypothetical graphs" which bear the same consequences as their RDF graphs, but they do not participate in the truth of the dataset; this is similar to the "context" option above but it allows a graph to contain contradictions without making the dataset contradictory;</li>
- <li>the triples are merely quoted without any indication of what they mean; they do not participate in the truth of a dataset;</li>
+ <li>the triples are merely quoted without any indication of what they mean; they do not participate in the truth of a dataset.</li>
</ul>
<p>Depending on the assumptions taken with respect to these two issues, the formalization of the semantics of RDF datasets can vary very much.</p>
@@ -167,9 +167,9 @@
<section id="rdf-semantics">
<h3>The RDF semantics</h3>
- <p class="issue">Part of what follows is somewhat subjective.</p>
+ <!--<p class="issue">Part of what follows is somewhat subjective.</p>-->
- <p>The first version of RDF semantics defined the meaning of a set of RDF graphs: <q cite="http://www.w3.org/TR/rdf-mt/#entail">a set of graphs can be treated as equivalent to its merge, that is, a single graph, as far as the model theory is concerned</q>.</p>
+ <p>The first version of RDF semantics defined the meaning of a set of RDF graphs: <q cite="http://www.w3.org/TR/rdf-mt/#entail">a set of graphs can be treated as equivalent to its merge, that is, a single graph, as far as the model theory is concerned</q>. The new version indicates that a set of RDF graphs can be either interpreted as its union or as its merge.</p>
<p>So, a first intuition could be that an RDF dataset, being presented as a collection of graph, should mean exactly what the set of its named graphs and default graph means. However, this completely leaves out the meaning of graph names, which could be valuable indicators for the truth of a dataset.</p>
<p>Formally, the semantics of RDF defines a notion of interpretation for a set of triples (i.e., an RDF graph), which then can extend to a set of RDF graphs. A dataset is neither a set of triples nor a set of RDF graphs. It is a set of <em>pairs</em> (name,graph) together with a distinguished RDF graph. Consequently, defining interpretation and entailement for RDF datasets would require at least an extension of the RDF semantics.</p>
<p>Conceptually, it is problematic since one of the reasons for separating triples into distinct (named) graphs is to avoid propagating the knowledge of one graph to the entire triple base. Sometimes, contradicting graphs need to coexist in a store. Sometimes named graphs are not endorsed by the system as a whole, they are merely quoted.</p>
@@ -177,15 +177,15 @@
<section id="named-graph-paper">
<h3>The Named Graphs paper</h3>
-
- <p>In Carrol et al., a named graph is simply defined as a pair comprising an IRI and an RDF graph. The notion of RDF interpretation is extended to named graphs by saying that the graph IRI in the pair must denote the pair itself. This non-ambiguously answers the question of what the graph IRI denotes. This can then be used to define a proper dataset semantics, as shown in Section ?.</p>
+
+ <p>In Carrol et al., a named graph is simply defined as a pair comprising an IRI and an RDF graph. The notion of RDF interpretation is extended to named graphs by saying that the graph IRI in the pair must denote the pair itself. This non-ambiguously answers the question of what the graph IRI denotes. This can then be used to define a proper dataset semantics, as shown in Section 3.3.</p>
</section>
<section id="sparql">
<h3>The SPARQL specification</h3>
<p>RDF 1.1 defines the notion of RDF dataset identically to SPARQL, which introduced it first. So, in order to understand the semantics of dataset, it is worth looking at how SPARQL uses datasets. SPARQL defines what are answers to queries posed against a dataset, but it never defines the notions that are key to a model theoretic formal semantics: it neither presents interpretations nor entailment. Still, it is worth noticing that a ASK query that only contains a basic graph pattern without variables yields the same result as asking whether the RDF graph in the query is entailed by the default graph. Based on this observation, one may extrapolate that a ASK query containing no variables and only GRAPH graph patterns would yield the same result as dataset entailment.</p>
- <p>This can be used as a guide for formalizing the semantics of datasets, as can be seen in Section ?.</p>
+ <p>This can be used as a guide for formalizing the semantics of datasets, as can be seen in Section 3.7.</p>
</section>
</section>
@@ -203,7 +203,7 @@
<li>they define notions of interpretation and entailment in function of the corresponding notions in RDF Semantics.</li>
</ul>
- <p>In fact, the dependency on RDF semantics is such that most of the dataset semantics below reuse RDF semantics as a black box. The purpose of a formal semantics for datasets is to determine under what circumstances a dataset can be said to be true or false. The formalisation below indicates that the truth of an RDF dataset can be determined in function of the truth of an RDF graph, no matter how the latter is determined. Therefore, instead of defining a precise definition of RDF graph interpretations and entailment, we use the more abstract notion of <a>entailment regime</a>. In fact, RDF Semantics does not define a single formal semantics, but multiple ones, depending on what standard vocabularies are endorsed by an application. Consequently, we will parameterize most of the definitions below with an unspecified entailment regime <var>E</var>. RDF 1.1 defines the following entailment regimes: simple entailment, D-entailment, RDF-entailment, RDFS-entailment. Additionally, OWL defines two other entailment regimes, based on the OWL 2 direct semantics [[OWL2-Direct-Semantics]] and the OWL 2 RDF-based semantics [[OWL2-RDF-based-Semantics]].</p>
+ <p>In fact, the dependency on RDF semantics is such that most of the dataset semantics below reuse RDF semantics as a black box. The purpose of a formal semantics for datasets is to determine under what circumstances a dataset can be said to be true or false. The formalisation below indicates that the truth of an RDF dataset can be determined in function of the truth of an RDF graph, no matter how the latter is determined. Therefore, instead of defining a precise definition of RDF graph interpretations and entailment, we use the more abstract notion of <a>entailment regime</a>. In fact, RDF Semantics does not define a single formal semantics, but multiple ones, depending on what standard vocabularies are endorsed by an application. Consequently, we will parameterize most of the definitions below with an unspecified entailment regime <var>E</var>. RDF 1.1 defines the following entailment regimes: simple entailment, D-entailment, RDF-entailment, RDFS-entailment. Additionally, OWL defines two other entailment regimes, based on the OWL 2 direct semantics [[OWL2-DIRECT-SEMANTICS]] and the OWL 2 RDF-based semantics [[OWL2-RDF-BASED-SEMANTICS]].</p>
<p>For an entailment regime <var>E</var>, we will say <var>E</var>-interpretation, <var>E</var>-entailment, <var>E</var>-equivalence, <var>E</var>-consistency to describe the notions of interpretations, entailment, equivalence and consistency associated with the regime <var>E</var>. Similarly, we will use the terms dataset-interpretation, dataset-entailment, dataset-equivalence, dataset-consistency for the corresponding notions in dataset semantics.</p>
<section>
@@ -270,7 +270,7 @@
<section>
<h3>The graph name denotes the named graph or the graph</h3>
<p>It is common to use the graph name as a way to identify the RDF graph inside the named graphs, or rather, to identify a particular occurence of the graph. This allows one to describe the graph or the graph source in triples. For instance, one may want to say who is the creator of a particular occurence of a graph. Assuming this semantics for graph names amounts to say that each named graph pair is an assertion that sets the <a>referent</a> of the graph name to be the associated graph.</p>
- <p>Intutively, this semantics can be seen as quoting the RDF graphs inside the named graphs. In this sense, <code>:alice {:bob :is :smart}</code> has to be understood as <q>Alice said: "Bob is smart"</q> which does not entail <q>Alice said: "Bob is intelligent"</q> even though "smart" and "intelligent" can be understood as equivalent.</p>
+ <p>Intutively, this semantics can be seen as quoting the RDF graphs inside the named graphs. In this sense, <code>:alice {:bob :is :smart}</code> has to be understood as <q>Alice said: "Bob is smart"</q> which does not entail <q>Alice said: "Bob is intelligent"</q> because Alice did not use the word "intelligent", even though "smart" and "intelligent" can be understood as equivalent.</p>
<h4 class="formal">Formalization</h4>
<p>We reuse the notation presented in [[RDF11-MT]]:</p>
@@ -318,6 +318,7 @@
<p>Intutively, this semantics can be seen as interpreting the RDF graphs inside the named graphs. In this sense, <code>:alice {:bob :is :smart}</code> has to be understood as <q>Alice said that Bob is smart</q> which entails <q>Alice said that Bob is intelligent</q> because the two sentences mean the same thing. Neither sentences mean that Alice used these actual words.</p>
<h4 class="formal">Formalization</h4>
+ <p class="issue">This does not take into account blank nodes as graph names.</p>
<p>There are several possible formalization of this. One way is to interpret the graph name as denoting a graph that represents all that is true in the context of the named graph. In this case, a dataset-interpretation with respect to an entailment regime <var>E</var> is an <var>E</var>-interpretation such that:</p>
<ul>
<li>for each named graph pair <var>ng</var> = <var>(n,G)</var>, <var>I(ng)</var> is true if <var>I(n)</var> is an RDF graph and <var>E</var>-entails <var>G</var>;</li>
@@ -409,13 +410,13 @@
<pre class="example">{ :g :quotes ":a :b []"^^:turtle . }
:g { :b rdf:type rdf:Property .
:a :b _:x . }</pre>
- <p>This technique allows one to assume a dataset semantics of contexts (as in Section ?) and still preserve an initial version of a graph. However, quoting big graphs may be combursome and would require a custom datatype to be recognized.</p>
+ <p>This technique allows one to assume a dataset semantics of contexts (as in Section 3.4) and still preserve an initial version of a graph. However, quoting big graphs may be combursome and would require a custom datatype to be recognized.</p>
</section>
<section>
<h3>Relationship with SPARQL entailment regime</h3>
- <p>There is a strong relationship between SPARQL ASK queries with an entailment regime [[SPARQL_ER]] and inferences in the regime. If an ASK query does not contain variables and its WHERE clause only contains a basic graph pattern, then the query can be seen as an RDF graph. If such a graph query <var>Q</var> returns <code>true</code> when issued against an RDF graph <var>G</var> with entailment regime <var>E</var>, then <var>G</var> <var>E</var>-entails <var>Q</var>. If it returns <code>false</code>, then <var>G</var> does not <var>E</var>-entail <var>Q</var>.</p>
+ <p>There is a strong relationship between SPARQL ASK queries with an entailment regime [[SPARQL-ENTAILMENT-REGIME]] and inferences in the regime. If an ASK query does not contain variables and its WHERE clause only contains a basic graph pattern, then the query can be seen as an RDF graph. If such a graph query <var>Q</var> returns <code>true</code> when issued against an RDF graph <var>G</var> with entailment regime <var>E</var>, then <var>G</var> <var>E</var>-entails <var>Q</var>. If it returns <code>false</code>, then <var>G</var> does not <var>E</var>-entail <var>Q</var>.</p>
<p>A dataset semantics can also be compared to what ASK queries return when they do not contain variables but may contain basic graph patterns or graph graph patterns. For instance, consider the dataset:</p>
<pre class="example">{ }
:g1 { :x rdf:type :c .
@@ -442,7 +443,7 @@
<p>This was not retained eventually, because of the lack of experience, and potentially the lack of utility, so there is no definite option for this. Nonetheless, for completeness, we describe here possible solutions.</p>
<h3>Using vocabularies</h3>
- <p>A dataset can be described in RDF using vocabularies like voiD [[VOID]] and the SPARQL service description vocabulary. VoiD is used to describe how a collection of RDF triples is organized in a web site or across web sites, giving information about the size of the datasets, the location of the dump files, the IRI of the query endpoints, and so on. The notion of dataset in voiD is used as a more informal and broader concept than RDF dataset. However, an RDF dataset and the graphs in it can be describe as voiD datasets and the information can be completed with SPARQL service description</p>
+ <p>A dataset can be described in RDF using vocabularies like voiD [[VOID]] and the SPARQL service description vocabulary [[SPARQL-SERVICE-DESCRIPTION]]. VoiD is used to describe how a collection of RDF triples is organized in a web site or across web sites, giving information about the size of the datasets, the location of the dump files, the IRI of the query endpoints, and so on. The notion of dataset in voiD is used as a more informal and broader concept than RDF dataset. However, an RDF dataset and the graphs in it can be describe as voiD datasets and the information can be completed with SPARQL service description</p>
<pre class="example">@prefix er: <http://www.w3.org/ns/entailment> .
@prefix sd: <http://www.w3.org/ns/sparql-service-description#> .
[] a sd:Dataset;
@@ -464,7 +465,7 @@
<section class="appendix informative" id="changes">
<h2>Changes</h2>
<ul>
- <li>2013-09-17: All sections revised. Second published editor's draft.</li>
+ <li>2013-09-17: All sections revised. Second published editor's draft.</li>
<li>2013-01-28: Initial editor's draft.</li>
</ul>
</section>