You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jena.apache.org by bu...@apache.org on 2015/07/14 14:52:15 UTC
svn commit: r958279 [3/6] - in /websites/staging/jena/trunk/content: ./
about_jena/ documentation/ documentation/csv/ documentation/hadoop/
documentation/inference/ documentation/io/ documentation/jdbc/
documentation/notes/ documentation/ontology/ docu...
Modified: websites/staging/jena/trunk/content/documentation/notes/sse.html
==============================================================================
--- websites/staging/jena/trunk/content/documentation/notes/sse.html (original)
+++ websites/staging/jena/trunk/content/documentation/notes/sse.html Tue Jul 14 12:52:14 2015
@@ -144,9 +144,20 @@
<div class="col-md-12">
<div id="breadcrumbs"></div>
<h1 class="title">SPARQL S-Expressions (or "SPARQL Syntax Expressions")</h1>
- <p>A way to write down data structures in an RDF-centric syntax.</p>
+ <style type="text/css">
+/* The following code is added by mdx_elementid.py
+ It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+ visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>A way to write down data structures in an RDF-centric syntax.</p>
<p>But not an idea for another RDF serialization format.</p>
-<h2 id="contents">Contents</h2>
+<h2 id="contents">Contents<a class="headerlink" href="#contents" title="Permanent link">¶</a></h2>
<ul>
<li><a href="#need">Need</a></li>
<li><a href="#design-intent">Design Intent</a></li>
@@ -187,7 +198,7 @@
</li>
<li><a href="#sse-grammar">SSE Grammar</a></li>
</ul>
-<h2 id="need">Need</h2>
+<h2 id="need">Need<a class="headerlink" href="#need" title="Permanent link">¶</a></h2>
<p>The <a href="http://www.w3.org/TR/sparql11-query/#sparqlAlgebra">SPARQL algebra</a>
defines the semantics of a SPARQL graph pattern. Every SPARQL query
string (the syntax) is mapped to a SPARQL algebra expression.</p>
@@ -213,7 +224,7 @@ no operations, no <em>push</em>, <em>pop
between cooperating machines. The structures are not completely
self-representing. But we do discuss a way to express in RDF that does
give a self-describing nature through the use of tagged structures.</p>
-<h2 id="design-intent">Design Intent</h2>
+<h2 id="design-intent">Design Intent<a class="headerlink" href="#design-intent" title="Permanent link">¶</a></h2>
<ul>
<li>Concise (=> for people to write conveniently) format for data
structures</li>
@@ -229,24 +240,24 @@ give a self-describing nature through th
<li>Concise syntax for RDF terms</li>
<li>Datastructures</li>
</ul>
-<h2 id="other-approaches">Other Approaches</h2>
-<h3 id="rdf">RDF</h3>
+<h2 id="other-approaches">Other Approaches<a class="headerlink" href="#other-approaches" title="Permanent link">¶</a></h2>
+<h3 id="rdf">RDF<a class="headerlink" href="#rdf" title="Permanent link">¶</a></h3>
<p>RDF is "map-centric" but not all data structures are conveniently
expressible in maps. RDF has lists, and these lists have convenient
syntax in Turtle or N3.</p>
<p>If your data structure fits the RDF paradigm, then RDF is a better
choice that SSE. <a href="#mapping-to-rdf">Below</a> is a possible mapping from SSE
to RDF as Turtle.</p>
-<h3 id="lisp">Lisp</h3>
+<h3 id="lisp">Lisp<a class="headerlink" href="#lisp" title="Permanent link">¶</a></h3>
<p>Lacks convenient syntax for the RDF terms themselves.</p>
<p>SSE syntax is almost valid
<a href="http://www.schemers.org" title="http://www.schemers.org">Scheme</a>; literal
language tags and datatypes get split a separate list symbols but the
information is recoverable. Scheme doesn't use <code>[]</code> lists or
single-quoted strings.</p>
-<h3 id="xml">XML</h3>
+<h3 id="xml">XML<a class="headerlink" href="#xml" title="Permanent link">¶</a></h3>
<p>Too verbose.</p>
-<h3 id="json">JSON</h3>
+<h3 id="json">JSON<a class="headerlink" href="#json" title="Permanent link">¶</a></h3>
<p><a href="http://json.org/" title="http://json.org/">JSON</a> provides values (strings,
numbers, booleans, null), arrays and object (which are maps). <a href="http://www.w3.org/TR/rdf-sparql-json-res/" title="http://www.w3.org/TR/rdf-sparql-json-res/">SPARQL
Query Results in
@@ -256,14 +267,14 @@ into further substructures. Alternativel
strings like "<http://w3.org/>" and have a parser-within-a-parser. But
both these approaches do not make the writing of RDF terms as easy as it
could be.</p>
-<h2 id="design">Design</h2>
+<h2 id="design">Design<a class="headerlink" href="#design" title="Permanent link">¶</a></h2>
<p><a href="http://en.wikipedia.org/wiki/S-expression" title="http://en.wikipedia.org/wiki/S-expression">S-expressions</a>
using RDF terms.</p>
<p>The command <code>arq.qparse --print=op --file queryFile</code> will print the
SPARQL algebra for the query in SSE format.</p>
-<h3 id="tokens">Tokens</h3>
+<h3 id="tokens">Tokens<a class="headerlink" href="#tokens" title="Permanent link">¶</a></h3>
<p>Tokens are the atomic elements of the syntax.</p>
-<table>
+<table class="table">
<thead>
<tr>
<th>Example</th>
@@ -330,16 +341,16 @@ non-distinguished variable.</p>
form.</p>
<p>Almost any sequence of characters which is not an RDF term or variable
is a symbol that can be given special meaning by processing software.</p>
-<h3 id="sse-comments">SSE Comments</h3>
+<h3 id="sse-comments">SSE Comments<a class="headerlink" href="#sse-comments" title="Permanent link">¶</a></h3>
<p><code>#</code> or <code>;</code> introduce comments, which run to the end of line, including
the end-of-line characters.</p>
-<h3 id="sse-escapes">SSE Escapes</h3>
+<h3 id="sse-escapes">SSE Escapes<a class="headerlink" href="#sse-escapes" title="Permanent link">¶</a></h3>
<p><code>\u</code> and <code>\U</code> escape sequences for arbitrary Unicode codepoints. These
apply to the input character stream before parsing. They don't, for
example, permit a space in a symbol.</p>
<p>Strings provide <code>\n</code>, <code>\t</code>, <code>\r</code>, <code>\b</code>, <code>\b</code>, <code>\f</code>, <code>\"</code>, <code>\'</code> and <code>\\</code>
escape sequences as in SPARQL.</p>
-<h3 id="structures">Structures</h3>
+<h3 id="structures">Structures<a class="headerlink" href="#structures" title="Permanent link">¶</a></h3>
<p><code>(?x ns:p "abc")</code> - list of 3 elements: a variable, a prefixed name and
a string</p>
<div class="codehilite"><pre><span class="p">(</span><span class="n">bgp</span>
@@ -350,7 +361,7 @@ a string</p>
<p>A list of 2 elements: a symbol (<code>bgp</code>) and a list of 3 elements. Both
<code>()</code> and <code>[]</code> delimit lists; they must match but otherwise it's a free
choice. Convention is that compact lists use <code>[]</code>; large lists use <code>()</code>.</p>
-<h2 id="tagged-structures">Tagged Structures</h2>
+<h2 id="tagged-structures">Tagged Structures<a class="headerlink" href="#tagged-structures" title="Permanent link">¶</a></h2>
<p>The basic syntax defines tokens and lists. Higher level processing
happens on this basic syntax and can be extended by interpreting the
structure.</p>
@@ -369,7 +380,7 @@ a symbol and the elements of the data ob
<p>is tagged with symbol <code>triple</code></p>
-<h3 id="iri-resolution">IRI resolution</h3>
+<h3 id="iri-resolution">IRI resolution<a class="headerlink" href="#iri-resolution" title="Permanent link">¶</a></h3>
<p>One such layer is IRI and prefix name resolution, using tags <code>base</code> and
<code>prefix</code>.</p>
<p>Basic syntax includes unresolved IRIs, (example <code><abc></code>) and prefixed
@@ -378,7 +389,7 @@ names (example <code>foaf:name</code>).
<p>This is sufficiently important that the SSE library handles this in an
optimized fashion where the IRI processing directly rewrites the
streamed output of the parser.</p>
-<h4 id="base"><code>base</code></h4>
+<h4 id="base"><code>base</code><a class="headerlink" href="#base" title="Permanent link">¶</a></h4>
<div class="codehilite"><pre><span class="p">(</span><span class="n">base</span> <span class="o"><</span><span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">example</span><span class="o">/></span>
<span class="p">(</span><span class="n">triple</span> <span class="o"><</span><span class="n">xyz</span><span class="o">></span> ?<span class="n">p</span> "<span class="n">lex</span>"^^<span class="o"><</span><span class="n">thing</span><span class="o">></span><span class="p">))</span>
</pre></div>
@@ -389,7 +400,7 @@ streamed output of the parser.</p>
</pre></div>
-<h4 id="prefix"><code>prefix</code></h4>
+<h4 id="prefix"><code>prefix</code><a class="headerlink" href="#prefix" title="Permanent link">¶</a></h4>
<div class="codehilite"><pre><span class="p">(</span><span class="n">prefix</span> <span class="p">((:</span> <span class="o"><</span><span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">example</span><span class="o">/></span><span class="p">)</span>
<span class="p">(</span><span class="n">ns</span><span class="p">:</span> <span class="o"><</span><span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">example</span><span class="o">/</span><span class="n">ns</span>#<span class="o">></span><span class="p">))</span>
<span class="p">(</span><span class="n">triple</span> <span class="p">:</span><span class="n">x</span> <span class="n">ns</span><span class="p">:</span><span class="n">p</span> "<span class="n">lex</span>"^^<span class="n">ns</span><span class="p">:</span><span class="n">type</span><span class="p">))</span>
@@ -401,7 +412,7 @@ streamed output of the parser.</p>
</pre></div>
-<h4 id="nesting">Nesting</h4>
+<h4 id="nesting">Nesting<a class="headerlink" href="#nesting" title="Permanent link">¶</a></h4>
<p>The tagged structures can be combined and nested. The base or prefixes
declared only apply to the body of the data object.</p>
<div class="codehilite"><pre> <span class="p">(</span><span class="n">prefix</span> <span class="p">((:</span> <span class="o"><</span><span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">jena</span><span class="p">.</span><span class="n">hpl</span><span class="p">.</span><span class="n">hp</span><span class="p">.</span><span class="n">com</span><span class="o">/</span>2007<span class="o">/></span><span class="p">)</span>
@@ -415,7 +426,7 @@ declared only apply to the body of the d
</pre></div>
-<h3 id="links">Links</h3>
+<h3 id="links">Links<a class="headerlink" href="#links" title="Permanent link">¶</a></h3>
<p><em>Not implemented</em></p>
<p>Not all data structures can be conveniently expressed as nested lists.
Sub-element sharing matters. A structure with shared elements can't be
@@ -425,7 +436,7 @@ serialized as a strict tree and some for
<p>The link layer will produce an SSE structure without these tags, having
replaced all <code>name@</code> and <code>@link</code> with the shared structure <em>X</em>.</p>
<p><em><code>@</code> is a convention for referencing.</em></p>
-<h2 id="building-java-objects">Building Java Objects</h2>
+<h2 id="building-java-objects">Building Java Objects<a class="headerlink" href="#building-java-objects" title="Permanent link">¶</a></h2>
<p>Builders are code classes that process the structure into Java objects.
Writing builders is straight-forward because low-level parsing details
have been taken care of in the basic syntax. A typical builder is a
@@ -456,8 +467,8 @@ on the default graph.</p>
<li>Filter expressions (in prefix notation <code>(+ 1 2)</code>)</li>
<li>Query solutions (Bindings) and tables.</li>
</ul>
-<h3 id="sse-factory">SSE Factory</h3>
-<p>The class <code>SSE</code> in package <code>com.hp.hpl.jena.sparql.sse</code> provides many
+<h3 id="sse-factory">SSE Factory<a class="headerlink" href="#sse-factory" title="Permanent link">¶</a></h3>
+<p>The class <code>SSE</code> in package <code>org.apache.jena.sparql.sse</code> provides many
convenience functions to call builders for RDF and SPARQL structures.</p>
<div class="codehilite"><pre><span class="n">Node</span> <span class="n">n</span> <span class="p">=</span> <span class="n">SSE</span><span class="p">.</span><span class="n">parseNode</span><span class="p">(</span>"<span class="o"><</span><span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">example</span><span class="o">/</span><span class="n">node</span><span class="o">></span>"<span class="p">)</span> <span class="p">;</span>
<span class="n">Triple</span> <span class="n">t</span> <span class="p">=</span> <span class="n">SSE</span><span class="p">.</span><span class="n">parseTriple</span><span class="p">(</span>"<span class="p">(</span>?<span class="n">s</span> ?<span class="n">p</span> ?<span class="n">o</span><span class="p">)</span>"<span class="p">)</span> <span class="p">;</span>
@@ -471,7 +482,7 @@ be used without explicit prefix declarat
<p>There is a default prefix mapping with a few common prefixes: <code>rdf</code>,
<code>rdfs</code>, <code>owl</code>, <code>xsd</code> and <code>fn</code> (the XPath/XQuery functions and operators
namespace).</p>
-<h2 id="mapping-to-rdf">Mapping to RDF</h2>
+<h2 id="mapping-to-rdf">Mapping to RDF<a class="headerlink" href="#mapping-to-rdf" title="Permanent link">¶</a></h2>
<p>The syntax of SSE is very close to Turtle lists because the syntax for
IRIs and literals are the same.: to produce Turtle (outline):</p>
<ol>
@@ -484,7 +495,7 @@ IRIs and literals are the same.: to prod
<p>The result is an RDF model using only the properties <code>rdf:first</code> and
<code>rdf:rest</code> so it records the data structure, but not what hthe data
structure represents.</p>
-<h2 id="sse-files">SSE Files</h2>
+<h2 id="sse-files">SSE Files<a class="headerlink" href="#sse-files" title="Permanent link">¶</a></h2>
<p>The file extension is <code>.sse</code> and all files are UTF-8.</p>
<p>A quick and pragmatic Emacs mode is given by:</p>
<div class="codehilite"><pre><span class="p">;;</span> <span class="o">====</span> <span class="n">SSE</span> <span class="n">mode</span>
@@ -502,8 +513,8 @@ structure represents.</p>
</pre></div>
-<h2 id="longer-examples">Longer Examples</h2>
-<h3 id="query-1">Query 1</h3>
+<h2 id="longer-examples">Longer Examples<a class="headerlink" href="#longer-examples" title="Permanent link">¶</a></h2>
+<h3 id="query-1">Query 1<a class="headerlink" href="#query-1" title="Permanent link">¶</a></h3>
<div class="codehilite"><pre><span class="n">PREFIX</span> <span class="n">foaf</span><span class="p">:</span> <span class="o"><</span><span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">xmlns</span><span class="p">.</span><span class="n">com</span><span class="o">/</span><span class="n">foaf</span><span class="o">/</span>0<span class="p">.</span>1<span class="o">/></span>
<span class="n">SELECT</span> <span class="n">DISTINCT</span> ?<span class="n">name</span> ?<span class="n">nick</span>
<span class="p">{</span>
@@ -525,7 +536,7 @@ structure represents.</p>
</pre></div>
-<h3 id="complete-sparql-execution">Complete SPARQL Execution</h3>
+<h3 id="complete-sparql-execution">Complete SPARQL Execution<a class="headerlink" href="#complete-sparql-execution" title="Permanent link">¶</a></h3>
<p>The following is a complete query execution, data and query. There is an
inline dataset and a query of</p>
<div class="codehilite"><pre> <span class="n">PREFIX</span> <span class="p">:</span> <span class="o"><</span><span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">example</span><span class="o">/></span>
@@ -561,7 +572,7 @@ context sorts out the different usages.<
</pre></div>
-<h2 id="sse-grammar">SSE Grammar</h2>
+<h2 id="sse-grammar">SSE Grammar<a class="headerlink" href="#sse-grammar" title="Permanent link">¶</a></h2>
<p><em>@@ insert grammar here</em></p>
</div>
</div>
Modified: websites/staging/jena/trunk/content/documentation/notes/typed-literals.html
==============================================================================
--- websites/staging/jena/trunk/content/documentation/notes/typed-literals.html (original)
+++ websites/staging/jena/trunk/content/documentation/notes/typed-literals.html Tue Jul 14 12:52:14 2015
@@ -144,7 +144,18 @@
<div class="col-md-12">
<div id="breadcrumbs"></div>
<h1 class="title">Typed literals how-to</h1>
- <h2 id="what-are-typed-literals">What are typed literals?</h2>
+ <style type="text/css">
+/* The following code is added by mdx_elementid.py
+ It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+ visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h2 id="what-are-typed-literals">What are typed literals?<a class="headerlink" href="#what-are-typed-literals" title="Permanent link">¶</a></h2>
<p>In the original RDF specifications there were two types of literal
values defined - plain literals (which are basically strings with
an optional language tag) and XML literals (which are more or less
@@ -192,10 +203,10 @@ ontology definition.</p>
<p>In the new scheme of things well-formed XML literals are treated as
typed literals whose datatype is the special type
<code>rdf:XMLLiteral</code>.</p>
-<h2 id="basic-api-operations">Basic API operations</h2>
+<h2 id="basic-api-operations">Basic API operations<a class="headerlink" href="#basic-api-operations" title="Permanent link">¶</a></h2>
<p>Jena will correctly parse typed literals within RDF/XML, NTriple
and Turtle source files. The same Java object,
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/Literal.html"><code>Literal</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/rdf/model/Literal.html"><code>Literal</code></a>
will represent "plain" and "typed" literals. Literal now supports
some new methods:</p>
<ul>
@@ -252,7 +263,7 @@ attempts to parse the string of the plai
this example). These are for backward compatibility with earlier
versions of Jena and older datasets. In normal circumstances
<code>createTypedLiteral</code> is preferable.</p>
-<h3 id="equality-issues">Equality issues</h3>
+<h3 id="equality-issues">Equality issues<a class="headerlink" href="#equality-issues" title="Permanent link">¶</a></h3>
<p>There is a well defined notion of when two typed literals should be
equal, based on the equality defined for the datatype in question.
Jena2 implements this equality function by using the method
@@ -265,10 +276,10 @@ equality problems would have arisen beca
substitutable in the Java sense (for example they return different
values from a getDatatype() call). This would, for example, have
made it impossible to cache literals in a hash table.</p>
-<h2 id="how-datatypes-are-represented">How datatypes are represented</h2>
+<h2 id="how-datatypes-are-represented">How datatypes are represented<a class="headerlink" href="#how-datatypes-are-represented" title="Permanent link">¶</a></h2>
<p>Datatypes for typed literals are represented by instances of the
interface
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/datatypes/RDFDatatype.html"><code>com.hp.hpl.jena.datatypes.RDFDatatype</code></a>.
+<a href="/documentation/javadoc/jena/org/apache/jena/datatypes/RDFDatatype.html"><code>org.apache.jena.datatypes.RDFDatatype</code></a>.
Instances of this interface can be used to parse and serialized
typed data, test for equality and test if a typed or lexical value
is a legal value for this datatype.</p>
@@ -277,7 +288,7 @@ XSD datatypes (see <a href="#xsd">below<
<p>In addition, it is possible for an application to define new
datatypes and register them against some URI (see
<a href="#userdef">below</a>).</p>
-<h3 id="error-detection">Error detection</h3>
+<h3 id="error-detection">Error detection<a class="headerlink" href="#error-detection" title="Permanent link">¶</a></h3>
<p>When Jena parses a datatype whose lexical value is not legal for
the declared datatype is does not immediately throw an error. This
is because the RDFCore working group has defined that illegal
@@ -297,8 +308,8 @@ errors (such as mis-spelling the xsd nam
untill very late on. To overcome this we have hidden some global
switches that allow you to force Jena to report such syntactic
errors earlier. These are static Boolean parameters:</p>
-<div class="codehilite"><pre><span class="n">com</span><span class="p">.</span><span class="n">hp</span><span class="p">.</span><span class="n">hpl</span><span class="p">.</span><span class="n">jena</span><span class="p">.</span><span class="n">shared</span><span class="p">.</span><span class="n">impl</span><span class="p">.</span><span class="n">JenaParameters</span><span class="p">.</span><span class="n">enableEagerLiteralValidation</span>
-<span class="n">com</span><span class="p">.</span><span class="n">hp</span><span class="p">.</span><span class="n">hpl</span><span class="p">.</span><span class="n">jena</span><span class="p">.</span><span class="n">shared</span><span class="p">.</span><span class="n">impl</span><span class="p">.</span><span class="n">JenaParameters</span><span class="p">.</span><span class="n">enableSilentAcceptanceOfUnknownDatatypes</span>
+<div class="codehilite"><pre><span class="n">org</span><span class="p">.</span><span class="n">apache</span><span class="p">.</span><span class="n">jena</span><span class="p">.</span><span class="n">shared</span><span class="p">.</span><span class="n">impl</span><span class="p">.</span><span class="n">JenaParameters</span><span class="p">.</span><span class="n">enableEagerLiteralValidation</span>
+<span class="n">org</span><span class="p">.</span><span class="n">apache</span><span class="p">.</span><span class="n">jena</span><span class="p">.</span><span class="n">shared</span><span class="p">.</span><span class="n">impl</span><span class="p">.</span><span class="n">JenaParameters</span><span class="p">.</span><span class="n">enableSilentAcceptanceOfUnknownDatatypes</span>
</pre></div>
@@ -307,7 +318,7 @@ the full javadoc, not the API javadoc) b
regarded as stable. We plan to develop a cleaner way of setting
mode switches for Jena and these switches will migrate there in due
course, if they prove to be useful.</p>
-<h2 id="xsd-data-types">XSD data types</h2>
+<h2 id="xsd-data-types">XSD data types<a class="headerlink" href="#xsd-data-types" title="Permanent link">¶</a></h2>
<p>Jena includes prebuilt, and pre-registered, instances of
<code>RDFDatatype</code> for all of the relevant XSD types:</p>
<div class="codehilite"><pre><span class="n">float</span> <span class="n">double</span> <span class="n">int</span> <span class="n">long</span> <span class="n">short</span> <span class="n">byte</span> <span class="n">unsignedByte</span> <span class="n">unsignedShort</span>
@@ -321,10 +332,10 @@ course, if they prove to be useful.</p>
<p>These are all available as static member variables from
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/datatypes/xsd/XSDDatatype.html"><code>com.hp.hpl.jena.datatypes.xsd.XSDDatatype</code></a>.</p>
+<a href="/documentation/javadoc/jena/org/apache/jena/datatypes/xsd/XSDDatatype.html"><code>org.apache.jena.datatypes.xsd.XSDDatatype</code></a>.</p>
<p>Of these types, the following are registered as the default type to
use to represent certain Java classes:</p>
-<table>
+<table class="table">
<thead>
<tr>
<th>Java class</th>
@@ -379,7 +390,7 @@ use to represent certain Java classes:</
When parsing an xsd:integer the Java value object used will be an
Integer, Long or BigInteger depending on the size of the specific
value being represented.</p>
-<h2 id="user-defined-xsd-data-types">User defined XSD data types</h2>
+<h2 id="user-defined-xsd-data-types">User defined XSD data types<a class="headerlink" href="#user-defined-xsd-data-types" title="Permanent link">¶</a></h2>
<p>XML schema allows derived types to be defined in which a base type
is modified through some facet restriction such as limiting the
min/max of an integer or restricting a string to a regular
@@ -420,12 +431,12 @@ then tries to create and use two instanc
</pre></div>
-<h2 id="user-defined-non-xsd-data-types">User defined non-XSD data types</h2>
+<h2 id="user-defined-non-xsd-data-types">User defined non-XSD data types<a class="headerlink" href="#user-defined-non-xsd-data-types" title="Permanent link">¶</a></h2>
<p>RDF allows any URI to be used as a datatype but provides no
standard for how to map the datatype URI to a datatype definition.</p>
<p>Within Jena2 we allow new datatypes to be created and registered by
using the
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/datatypes/TypeMapper.html"><code>TypeMapper</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/datatypes/TypeMapper.html"><code>TypeMapper</code></a>
class.</p>
<p>The easiest way to define a new RDFDatatype is to subclass
BaseDatatype and define implementations for parse, unparse and
@@ -494,7 +505,7 @@ rational numbers:</p>
defined literals will be perfectly legal a client application has
no standard way of looking up the datatype URI you have chosen.
This has to be done "out of band" as they say.</p>
-<h2 id="a-note-on-xmllang">A note on xml:Lang</h2>
+<h2 id="a-note-on-xmllang">A note on xml:Lang<a class="headerlink" href="#a-note-on-xmllang" title="Permanent link">¶</a></h2>
<p>Plain literals have an xml:Lang tag as well as a string value. Two
plain literals with the same string but different Lang tags are not
equal.</p>
Modified: websites/staging/jena/trunk/content/documentation/ontology/index.html
==============================================================================
--- websites/staging/jena/trunk/content/documentation/ontology/index.html (original)
+++ websites/staging/jena/trunk/content/documentation/ontology/index.html Tue Jul 14 12:52:14 2015
@@ -144,13 +144,24 @@
<div class="col-md-12">
<div id="breadcrumbs"></div>
<h1 class="title">Jena Ontology API</h1>
- <p>This section is a general introduction to the Jena2
+ <style type="text/css">
+/* The following code is added by mdx_elementid.py
+ It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+ visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>This section is a general introduction to the Jena2
ontology API, including some of the common tasks you may need
to perform. We
won't go into all of the many details of the API here: you should
expect to refer to the <a href="/documentation/javadoc/jena/">Javadoc</a> to
get full details of the capabilities of the API.</p>
-<h3 id="prerequisites">Prerequisites</h3>
+<h3 id="prerequisites">Prerequisites<a class="headerlink" href="#prerequisites" title="Permanent link">¶</a></h3>
<p>We'll assume that you have a basic familiarity with RDF and with
Jena. If not, there are other
<a href="/getting_started">Jena help documents</a> you can read for background
@@ -166,7 +177,7 @@ example the <a href="http://www.w3.org/2
<p><strong>Note:</strong> Although OWL version 1.1 is now a W3C recommendation,
Jena's support for OWL 1.1 features is limited. We will be addressing
this in future versions Jena.</p>
-<h2 id="overview">Overview</h2>
+<h2 id="overview">Overview<a class="headerlink" href="#overview" title="Permanent link">¶</a></h2>
<p>The section of the manual is broken into a number of sections. You
do not need to read them in sequence, though later sections may
refer to concepts and techniques introduced in earlier sections.
@@ -186,7 +197,7 @@ The sections are:</p>
<li><a href="#working-with-persistent-ontologies">Working with persistent ontologies</a></li>
<li><a href="#experimental-ontology-tools">Experimental ontology tools</a></li>
</ul>
-<h3 id="further-assistance">Further assistance</h3>
+<h3 id="further-assistance">Further assistance<a class="headerlink" href="#further-assistance" title="Permanent link">¶</a></h3>
<p>Hopefully, this document will be sufficient to help most readers
to get started using the Jena ontology API. For further support,
please post questions to the <a href="/help_and_support">Jena support list</a>,
@@ -195,7 +206,7 @@ or <a href="/help_and_support/bugs_and_s
to communicate with the Jena team, rather than send email to the team
members directly. This helps us manage Jena support more effectively,
and facilitates contributions from other Jena community members.</em></p>
-<h2 id="general-concepts">General concepts</h2>
+<h2 id="general-concepts">General concepts<a class="headerlink" href="#general-concepts" title="Permanent link">¶</a></h2>
<p>In a widely-quoted definition, an ontology is</p>
<blockquote>
<p>"a specification of a conceptualization"
@@ -235,7 +246,7 @@ the varieties of
We will provide a very brief introduction to these languages here,
but please refer to the extensive on-line documentation for these
formalisms for complete and authoritative details.</p>
-<h3 id="rdfs">RDFS</h3>
+<h3 id="rdfs">RDFS<a class="headerlink" href="#rdfs" title="Permanent link">¶</a></h3>
<p>RDFS is the weakest ontology language supported by Jena. RDFS
allows the ontologist to build a simple hierarchy of concepts, and
a hierarchy of properties. Consider the following trivial
@@ -288,7 +299,7 @@ has <a href="http://en.wikipedia.org/wik
sense organs, and these only occur in fish. In RDFS, we state that
the <em>domain</em> of the <code>lateralLines</code> property is the <code>Fish</code> class, so
an RDFS reasoner can infer that Freda must be a fish.</p>
-<h3 id="owl">OWL</h3>
+<h3 id="owl">OWL<a class="headerlink" href="#owl" title="Permanent link">¶</a></h3>
<p>In general, OWL allows us to say everything that RDFS allows, and
much more besides. A key part of OWL is the ability to describe
classes in more interesting and complex ways. For example, in OWL
@@ -340,7 +351,7 @@ on an RDF foundation. This view uses RDF
the RDF-centric view treats RDF triples as the core of the OWL
formalism. While both views are valid, in Jena we take the
RDF-centric view.</p>
-<h3 id="ontology-languages-and-the-jena-ontology-api">Ontology languages and the Jena Ontology API</h3>
+<h3 id="ontology-languages-and-the-jena-ontology-api">Ontology languages and the Jena Ontology API<a class="headerlink" href="#ontology-languages-and-the-jena-ontology-api" title="Permanent link">¶</a></h3>
<p>As we outlined above, there are various different ontology languages
available for representing ontology information on the semantic
web. They range from the most expressive, OWL Full, through to the
@@ -359,17 +370,17 @@ permitted constructs and the names of th
profile it is <code>null</code> since RDFS does not define object properties.</p>
<p>The profile is bound to an <em>ontology model</em>, which is an extended
version of Jena's
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/Model.html"><code>Model</code></a> class.
+<a href="/documentation/javadoc/jena/org/apache/jena/rdf/model/Model.html"><code>Model</code></a> class.
The base <code>Model</code> allows access to the statements in a collection of
RDF data.
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/OntModel.html"><code>OntModel</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/OntModel.html"><code>OntModel</code></a>
extends this by adding support for the kinds of constructs expected to
be in an ontology: classes (in a class hierarchy), properties (in a
property hierarchy) and individuals.</p>
<p>When you're working with an
ontology in Jena, all of the state information remains encoded as
RDF triples (accessed as Jena
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/Statement.html"><code>Statement</code>s</a>) stored in the RDF
+<a href="/documentation/javadoc/jena/org/apache/jena/rdf/model/Statement.html"><code>Statement</code>s</a>) stored in the RDF
model. The ontology API
doesn't change the RDF representation of ontologies. What it does
do is add a set of convenience classes and methods that make it
@@ -386,7 +397,7 @@ information from the underlying RDF trip
subclass to an <code>OntClass</code> asserts an additional RDF triple, typically
with predicate <code>rdfs:subClassOf</code> into
the model.</p>
-<h3 id="ontologies-and-reasoning">Ontologies and reasoning</h3>
+<h3 id="ontologies-and-reasoning">Ontologies and reasoning<a class="headerlink" href="#ontologies-and-reasoning" title="Permanent link">¶</a></h3>
<p>One of the key benefits of building an ontology-based application
is using a reasoner to derive additional truths about the concepts
you are modelling. We saw a simple instance of this above: the
@@ -422,7 +433,7 @@ in-memory store, a database-backed persi
storage structure altogether – e.g. an LDAP directory – again without
affecting the operation of the ontology model (but noting that these
different approaches may have very different efficiency profiles).</p>
-<h3 id="rdf-level-polymorphism-and-java">RDF-level polymorphism and Java</h3>
+<h3 id="rdf-level-polymorphism-and-java">RDF-level polymorphism and Java<a class="headerlink" href="#rdf-level-polymorphism-and-java" title="Permanent link">¶</a></h3>
<p>Deciding which Java abstract class to use to represent a given RDF
resource can be surprisingly subtle. Consider the following RDF
sample:</p>
@@ -473,7 +484,7 @@ resource is typed as an <code>owl:Class<
facet; given other types, it can present other facets. Jena
provides the <code>.as()</code> method to efficiently map from an RDF object
to one of its allowable facets. Given a RDF object (i.e. an
-instance of <code>com.hp.hpl.jena.rdf.model.RDFNode</code> or one of its
+instance of <code>org.apache.jena.rdf.model.RDFNode</code> or one of its
sub-types), you can get a facet by invoking <code>as()</code> with an argument
that denotes the facet required. Specifically, the facet is
identified by the Java class object of the desired facet. For
@@ -491,7 +502,7 @@ support the conversion to a given facet,
given facet with <code>canAs()</code>. This RDF-level polymorphism is used
extensively in the Jena ontology API to allow maximum flexibility
in handling ontology data.</p>
-<h2 id="running-example-the-eswc-ontology">Running example: the ESWC ontology</h2>
+<h2 id="running-example-the-eswc-ontology">Running example: the ESWC ontology<a class="headerlink" href="#running-example-the-eswc-ontology" title="Permanent link">¶</a></h2>
<p>To illustrate the principles of using the ontology API, we will use
examples drawn from Tom Heath's
<a href="http://www.schemaweb.info/schema/SchemaDetails.aspx?id=282">ESWC ontology</a>.
@@ -508,11 +519,11 @@ in Figure 3:</p>
<br />Figure 3: Classes and properties from ESWC ontology</p>
<p>We will use elements from this ontology to illustrate the ontology
API throughout the rest of this document.</p>
-<h2 id="creating-ontology-models">Creating ontology models</h2>
+<h2 id="creating-ontology-models">Creating ontology models<a class="headerlink" href="#creating-ontology-models" title="Permanent link">¶</a></h2>
<p>An ontology model is an extension of the Jena RDF model,
providing extra capabilities for handling ontologies. Ontology
models are created through the Jena
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/ModelFactory.html"><code>ModelFactory</code></a>.
+<a href="/documentation/javadoc/jena/org/apache/jena/rdf/model/ModelFactory.html"><code>ModelFactory</code></a>.
The simplest way to create an ontology model is as follows:</p>
<div class="codehilite"><pre><span class="n">OntModel</span> <span class="n">m</span> <span class="p">=</span> <span class="n">ModelFactory</span><span class="p">.</span><span class="n">createOntologyModel</span><span class="p">();</span>
</pre></div>
@@ -545,7 +556,7 @@ no reasoning at all can be created with:
all of the other values as defaults, you should pass the URI of the
ontology language to the model factory. The URI strings for the
various language profiles are:</p>
-<table>
+<table class="table">
<thead>
<tr>
<th>Ontology language</th>
@@ -572,20 +583,20 @@ various language profiles are:</p>
</tbody>
</table>
<p>These URI's are used to look-up the language profile from the
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/ProfileRegistry.html"><code>ProfileRegistry</code></a>.
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/ProfileRegistry.html"><code>ProfileRegistry</code></a>.
The profile registry contains public constant declarations so
that you do not have to remember these URI's. Please note that the
URI's denoting OWL Lite and OWL DL are not officially sanctioned by
the OWL standard.</p>
<p>Beyond these basic choices, the complexities of configuring an
ontology model are wrapped up in a recipe object called
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/OntModelSpec.html"><code>OntModelSpec</code></a>.
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/OntModelSpec.html"><code>OntModelSpec</code></a>.
This specification allows complete control over the configuration
choices for the ontology model, including the language profile in
use, the reasoner, and the means of handling compound documents. A
number of common recipes are pre-declared as constants in
<code>OntModelSpec</code>, and listed below.</p>
-<table>
+<table class="table">
<thead>
<tr>
<th>OntModelSpec</th>
@@ -696,7 +707,7 @@ number of common recipes are pre-declare
<p>For details of reasoner capabilities, please see the
<a href="../inference">inference documentation</a> and the Javadoc
for
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/OntModelSpec.html">OntModelSpec</a>.
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/OntModelSpec.html">OntModelSpec</a>.
See also further discussion <a href="#inference-intro">below</a>.</p>
<p><strong>Note:</strong> it is primarily the choice of reasoner, rather than the
choice of language profile, which determines which entailments are
@@ -723,7 +734,7 @@ and then update the copy as necessary:</
</pre></div>
-<h2 id="compound-ontology-documents-and-imports-processing">Compound ontology documents and imports processing</h2>
+<h2 id="compound-ontology-documents-and-imports-processing">Compound ontology documents and imports processing<a class="headerlink" href="#compound-ontology-documents-and-imports-processing" title="Permanent link">¶</a></h2>
<p>The OWL ontology language includes some facilities for
creating modular ontologies that can be re-used in a similar manner
to software modules. In particular, one ontology can <em>import</em>
@@ -801,7 +812,7 @@ ontology A, and A imports B, we will end
in Figure 4. Note that the imports have been flattened out. A cycle
check is used to prevent the document handler getting stuck if, for
example, A imports B which imports A!</p>
-<h3 id="the-ontology-document-manager">The ontology document manager</h3>
+<h3 id="the-ontology-document-manager">The ontology document manager<a class="headerlink" href="#the-ontology-document-manager" title="Permanent link">¶</a></h3>
<p>Each ontology model has an associated <em>document manager</em> which
assists with the processing and handling of ontology documents and related
concerns. For convenience, there is one global document manager
@@ -828,7 +839,7 @@ example:</p>
was created with. Thus if you change a document manager's
properties, it will affect models that have previously been
constructed with that document manager.</p>
-<h3 id="document-manager-policy">Document manager policy</h3>
+<h3 id="document-manager-policy">Document manager policy<a class="headerlink" href="#document-manager-policy" title="Permanent link">¶</a></h3>
<p>Since the document manager has a large number of configurable
options, there are two ways in which you can customise it to your
application requirements. Firstly, you can set the individual
@@ -859,7 +870,7 @@ that you can use in such an ontology doc
manager will use to initialise itself, you can either pass the new
search path as a string when creating a new document manager
object, or call the method <code>setMetadataSearchPath()</code>.</p>
-<h3 id="the-modelmaker-creating-storage-on-demand">The ModelMaker: creating storage on demand</h3>
+<h3 id="the-modelmaker-creating-storage-on-demand">The ModelMaker: creating storage on demand<a class="headerlink" href="#the-modelmaker-creating-storage-on-demand" title="Permanent link">¶</a></h3>
<p>In order for the document manager to build the union of the
imported documents (which we sometimes refer to as the
<em>imports closure</em>), there must be some means of creating new graphs
@@ -870,7 +881,7 @@ a simple interface that allows different
on demand. For the database case, this may include passing the
database user-name and password and other connection parameters.
New model makers can be created with the
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/ModelFactory.html"><code>ModelFactory</code></a>.</p>
+<a href="/documentation/javadoc/jena/org/apache/jena/rdf/model/ModelFactory.html"><code>ModelFactory</code></a>.</p>
<p>There are two cases in which we may want to create storage for
models on-demand. The first is when creating the <code>OntModel</code> for the
first time. Some variants of <code>createOntologyModel</code> will allocate
@@ -893,12 +904,12 @@ programming interface (<code>Model</code
data structure (<code>Graph</code>). Hence some potential confusion in that
Figure 4, above, refers to a structure containing graphs, but we
use a
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/ModelMaker.html"><code>ModelMaker</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/rdf/model/ModelMaker.html"><code>ModelMaker</code></a>
to generate new stores. The document manager extracts the
appropriate graph from the containing model. Except in cases where
you are extending Jena's internal structures, you should think of
<code>Model</code> as the container of RDF and ontology data.</p>
-<h3 id="controlling-imports-processing">Controlling imports processing</h3>
+<h3 id="controlling-imports-processing">Controlling imports processing<a class="headerlink" href="#controlling-imports-processing" title="Permanent link">¶</a></h3>
<p>By default, loading imports during the <code>read()</code> call is automatic. To
<code>read()</code> an ontology without building the imports closure, call the
method <code>setProcessImports( false )</code> on the document manager object
@@ -908,7 +919,7 @@ selective, and ignore only certain URI's
documents. To selectively skip certain named imports, call the
method <code>addIgnoreImport( String uri )</code> on the document manager
object, or set the <code>ignoreImport</code> property in the policy.</p>
-<h3 id="managing-file-references">Managing file references</h3>
+<h3 id="managing-file-references">Managing file references<a class="headerlink" href="#managing-file-references" title="Permanent link">¶</a></h3>
<p>An advantage of working with ontologies is that we can reuse work
done by other ontologists, by importing their published ontologies
into our own. The <code>OntModel</code> can load such referenced ontologies
@@ -920,7 +931,7 @@ fail just because it temporarily does no
because a previously published ontology has been moved.
To alleviate these commonly
experienced problems, we can use Jena's
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/util/FileManager.html"><code>FileManager</code></a> to
+<a href="/documentation/javadoc/jena/org/apache/jena/util/FileManager.html"><code>FileManager</code></a> to
manage local indirections, so that an attempt to import a
document from a given published URL means that a local copy of the
document is loaded instead. This may be a file on the local disk, or simply a
@@ -970,7 +981,7 @@ initialised to the directory in which Je
</pre></div>
-<h3 id="specifying-prefixes">Specifying prefixes</h3>
+<h3 id="specifying-prefixes">Specifying prefixes<a class="headerlink" href="#specifying-prefixes" title="Permanent link">¶</a></h3>
<p>A model keeps a table of URI prefixes which can be used to present
URI's in the shortened <code>prefix:name</code> form. This is useful in
displaying URI's in a readable way in user interfaces, and is
@@ -979,7 +990,7 @@ The ontology model's table of prefixes c
table kept by the document manager, which contains the standard
prefixes plus any that are declared by in the policy file (or added
to subsequently by method calls).</p>
-<h3 id="caching-of-imported-models">Caching of imported models</h3>
+<h3 id="caching-of-imported-models">Caching of imported models<a class="headerlink" href="#caching-of-imported-models" title="Permanent link">¶</a></h3>
<p>You can use the document manager to assist with loading ontology
documents through its cache. Suppose two ontologies, A and B, both
import ontology C. We would like not to have to read C twice when
@@ -997,22 +1008,22 @@ use the policy property <code>cacheModel
<code>setCacheModels( boolean caching )</code> with <code>caching = false</code>. The
document manager's current model cache can be cleared at any time
by calling <code>clearCache()</code>.</p>
-<h2 id="the-generic-ontology-type-ontresource">The generic ontology type: OntResource</h2>
+<h2 id="the-generic-ontology-type-ontresource">The generic ontology type: OntResource<a class="headerlink" href="#the-generic-ontology-type-ontresource" title="Permanent link">¶</a></h2>
<p>All of the classes in the ontology API that represent ontology
values have
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/OntResource.html"><code>OntResource</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/OntResource.html"><code>OntResource</code></a>
as a common super-class. This makes <code>OntResource</code> a good place to
put shared functionality for all such classes, and makes a handy
common return value for general methods. The Java interface
<code>OntResource</code> extends Jena's RDF
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/Resource.html"><code>Resource</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/rdf/model/Resource.html"><code>Resource</code></a>
interface, so any general method that accepts a resource or an
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/RDFNode.html"><code>RDFNode</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/rdf/model/RDFNode.html"><code>RDFNode</code></a>
will also accept an <code>OntResource</code>, and consequently, any other
ontology value.</p>
<p>Some of the common attributes of ontology resources that are
expressed through methods on OntResource are shown below:</p>
-<table>
+<table class="table">
<thead>
<tr>
<th>Attribute</th>
@@ -1052,7 +1063,7 @@ expressed through methods on OntResource
</table>
<p>For each of these properties, there is a standard pattern of
available methods:</p>
-<table>
+<table class="table">
<thead>
<tr>
<th>Method</th>
@@ -1178,10 +1189,10 @@ form.</p>
<p>Related methods allow the <code>rdf:type</code> to be tested, set and
returned.</p>
-<h2 id="ontology-classes-and-basic-class-expressions">Ontology classes and basic class expressions</h2>
+<h2 id="ontology-classes-and-basic-class-expressions">Ontology classes and basic class expressions<a class="headerlink" href="#ontology-classes-and-basic-class-expressions" title="Permanent link">¶</a></h2>
<p>Classes are the basic building blocks of an ontology. A simple
class is represented in Jena by an
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/OntClass.html">OntClass</a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/OntClass.html">OntClass</a>
object. As <a href="#rdf-polymorphism">mentioned above</a>, an ontology class
is a facet of an RDF resource. One way, therefore, to get an
ontology class is to convert a plain RDF resource into
@@ -1224,7 +1235,7 @@ class are handled in a similar way to th
<code>OntResource</code>, above, with a collection of methods to set, add, get,
test, list and remove values. Properties of classes that are
handled in this way are:</p>
-<table>
+<table class="table">
<thead>
<tr>
<th>Attribute</th>
@@ -1272,7 +1283,7 @@ triples.</p>
<p>Given an <code>OntClass</code> object, you can create or remove members of the
class extension – individuals that are instances of the class –
using the following methods:</p>
-<table>
+<table class="table">
<thead>
<tr>
<th>Method</th>
@@ -1310,7 +1321,7 @@ this class among their domain classes. T
are intended to apply to instances of this class. Using
<code>listDeclaredProperties</code> is explained in detail in the
<a href="/documentation/notes/rdf-frames.html">RDF frames how-to</a>.</p>
-<h2 id="ontology-properties">Ontology properties</h2>
+<h2 id="ontology-properties">Ontology properties<a class="headerlink" href="#ontology-properties" title="Permanent link">¶</a></h2>
<p>In an ontology, a <em>property</em> denotes the name of a relationship
between resources, or between a resource and a data value. It
corresponds to a predicate in logic representations. One
@@ -1323,11 +1334,11 @@ of Java classes that allow you to conven
properties represented in an ontology model.</p>
<p>A property in an ontology model is an extension of the core Jena
API class
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/Property.html"><code>Property</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/rdf/model/Property.html"><code>Property</code></a>
and allows access to the additional information that can be
asserted about properties in an ontology language. The common API
super-class for representing ontology properties in Java is
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/OntProperty.html"><code>OntProperty</code></a>.
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/OntProperty.html"><code>OntProperty</code></a>.
Again, using the pattern of add, set, get, list, has, and remove
methods, we can access the following attributes of an
<code>OntProperty</code>:</p>
@@ -1381,7 +1392,7 @@ the ontology will contain <code>rdfs:sub
the sub-property resources, since this is what the language
defines. Jena will, in general, try to allow symmetric access to
sub-properties and sub-classes from either direction.</p>
-<h3 id="object-and-datatype-properties">Object and Datatype properties</h3>
+<h3 id="object-and-datatype-properties">Object and Datatype properties<a class="headerlink" href="#object-and-datatype-properties" title="Permanent link">¶</a></h3>
<p>OWL refines the basic property type from RDF into two
sub-types: <em>object properties</em> and <em>datatype properties</em> (for more
details see
@@ -1395,10 +1406,10 @@ perform more efficient reasoning over on
entailments, and so is useful when annotating ontology documents,
for example.</p>
<p>In Jena, the Java interfaces
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/ObjectProperty.html"><code>ObjectProperty</code></a>,
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/DatatypeProperty.html"><code>DatatypeProperty</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/ObjectProperty.html"><code>ObjectProperty</code></a>,
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/DatatypeProperty.html"><code>DatatypeProperty</code></a>
and
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/AnnotationProperty.html"><code>AnnotationProperty</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/AnnotationProperty.html"><code>AnnotationProperty</code></a>
are sub-types of <code>OntProperty</code>. However, they do not have any
behaviours (methods) particular to themselves. Their existence
allows the more complex sub-types of ObjectProperty – transitive
@@ -1406,7 +1417,7 @@ properties and so forth – to be ke
hierarchy. However, when you create an object property or datatype
property in a model, it will have the effect of asserting different
<code>rdf:type</code> statements into the underlying triple store.</p>
-<h3 id="functional-properties">Functional properties</h3>
+<h3 id="functional-properties">Functional properties<a class="headerlink" href="#functional-properties" title="Permanent link">¶</a></h3>
<p>OWL permits object and datatype properties to be <em>functional</em> –
that is, for a given individual in the domain, the range value will
always be the same. In particular, if <code>father</code> is a functional
@@ -1416,7 +1427,7 @@ property, and individual <code>:jane</co
equivalent to stating that the property has a maximum cardinality
of one.</p>
<p>Being a functional property is represented through the
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/FunctionalProperty.html"><code>FunctionalProperty</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/FunctionalProperty.html"><code>FunctionalProperty</code></a>
facet of an ontology property object. If a property is declared
functional (test using the <code>isFunctional()</code> method), then the
method <code>asFunctionalProperty()</code> conveniently returns the functional property
@@ -1424,16 +1435,16 @@ facet. A non-functional property can be
<code>convertToFunctionalProperty()</code> method. When you are creating a
property object, you also have the option of passing a Boolean
parameter to the <code>createObjectProperty()</code> method on <code>OntModel</code>.</p>
-<h3 id="other-property-types">Other property types</h3>
+<h3 id="other-property-types">Other property types<a class="headerlink" href="#other-property-types" title="Permanent link">¶</a></h3>
<p>There are several additional sub-types of ObjectProperty that
represent additional capabilities of ontology properties. A
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/TransitiveProperty.html"><code>TransitiveProperty</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/TransitiveProperty.html"><code>TransitiveProperty</code></a>
means that if p is transitive, and we know <code>:a p :b</code> and also
<code>b p :c</code>, we can infer that <code>:a p :c</code>. A
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/SymmetricProperty.html"><code>SymmetricProperty</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/SymmetricProperty.html"><code>SymmetricProperty</code></a>
means that if p is symmetric, and we know <code>:a p :b</code>, we can infer
<code>:b p :a</code>. An
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/InverseFunctionalProperty.html"><code>InverseFunctionalProperty</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/InverseFunctionalProperty.html"><code>InverseFunctionalProperty</code></a>
means that for any given range element, the domain value is unique.</p>
<p>Given that all properties are <code>RDFNode</code> objects, and therefore
support the <code>as()</code> method, you can use <code>as()</code> to change from an
@@ -1472,7 +1483,7 @@ object: <code>myOntModel.setStrictMode(
<p>Finally, methods beginning <code>is...</code> (e.g. <code>isTransitiveProperty</code>)
allow you to test whether a given property would support a given
sub-type facet.</p>
-<h2 id="more-complex-class-expressions">More complex class expressions</h2>
+<h2 id="more-complex-class-expressions">More complex class expressions<a class="headerlink" href="#more-complex-class-expressions" title="Permanent link">¶</a></h2>
<p>We introduced the handling of basic, named classes above. These are
the only kind of class descriptions available in RDFS. In OWL,
however, there are a number of additional types of class
@@ -1480,9 +1491,9 @@ expression, which allow richer and more
concepts. There are two main categories of additional class
expression: <em>restrictions</em> and <em>Boolean expressions</em>. We'll examine
each in turn.</p>
-<h3 id="restriction-class-expressions">Restriction class expressions</h3>
+<h3 id="restriction-class-expressions">Restriction class expressions<a class="headerlink" href="#restriction-class-expressions" title="Permanent link">¶</a></h3>
<p>A
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/Restriction.html">restriction</a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/Restriction.html">restriction</a>
defines a class by reference to one of the properties of the
individuals that comprise the members of the class, and then
placing some constraint on that property. For example, in a simple
@@ -1621,7 +1632,7 @@ restriction. Assume <code>m</code> conta
</pre></div>
-<h3 id="boolean-class-expressions">Boolean class expressions</h3>
+<h3 id="boolean-class-expressions">Boolean class expressions<a class="headerlink" href="#boolean-class-expressions" title="Permanent link">¶</a></h3>
<p>Most developers are familiar with the use of Boolean operators to
construct propositional expressions: conjunction (and), disjunction
(or) and negation (not). OWL provides a means for constructing
@@ -1640,7 +1651,7 @@ constructing class expressions. While co
single argument, union and intersection must necessarily take more
than one argument. Before continuing with constructing and using
Boolean class expressions, let's briefly to discuss lists.</p>
-<h3 id="list-expressions">List expressions</h3>
+<h3 id="list-expressions">List expressions<a class="headerlink" href="#list-expressions" title="Permanent link">¶</a></h3>
<p>RDF originally had three container types: <code>Seq</code>, <code>Alt</code> and <code>Bag</code>.
While useful, these are all open forms: it is not possible to say
that a given container has a fixed number of values.
@@ -1686,9 +1697,9 @@ is even more compact:</p>
<p>Although lists are defined in the generic RDF model in Jena, they
are extensively used by the ontology API so we mention them here.
Full details of the methods defined are in the
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/RDFList.html"><code>RDFList javadoc</code></a>.</p>
+<a href="/documentation/javadoc/jena/org/apache/jena/rdf/model/RDFList.html"><code>RDFList javadoc</code></a>.</p>
<p>Various means of constructing lists are defined in
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/Model.html"><code>Model</code></a>, as
+<a href="/documentation/javadoc/jena/org/apache/jena/rdf/model/Model.html"><code>Model</code></a>, as
variants on <code>createList</code>. For example, we can construct a list of
three classes as follows:</p>
<div class="codehilite"><pre><span class="n">OntModel</span> <span class="n">m</span> <span class="p">=</span> <span class="n">ModelFactory</span><span class="p">.</span><span class="n">createOntModel</span><span class="p">();</span>
@@ -1717,7 +1728,7 @@ in the list is not considered significan
<p>Finally, a resource which is a cell in a list sequence will accept
<code>.as( RDFList.class )</code></p>
<p>Once the list has been created or obtained from the model,
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/RDFList.html"><code>RDFList</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/rdf/model/RDFList.html"><code>RDFList</code></a>
methods may be used to access members of the list, iterate over the
list, and so forth. For example:</p>
<div class="codehilite"><pre><span class="n">System</span><span class="p">.</span><span class="n">out</span><span class="p">.</span><span class="n">println</span><span class="p">(</span> "<span class="n">List</span> <span class="n">has</span> " <span class="o">+</span> <span class="n">myRDFList</span><span class="p">.</span><span class="nb">size</span><span class="p">()</span> <span class="o">+</span> " <span class="n">members</span><span class="p">:</span>" <span class="p">);</span>
@@ -1727,7 +1738,7 @@ list, and so forth. For example:</p>
</pre></div>
-<h3 id="intersection-union-and-complement-class-expressions">Intersection, union and complement class expressions</h3>
+<h3 id="intersection-union-and-complement-class-expressions">Intersection, union and complement class expressions<a class="headerlink" href="#intersection-union-and-complement-class-expressions" title="Permanent link">¶</a></h3>
<p>Given Jena's ability to construct lists, building intersection and
union class expressions is straightforward. The <code>create</code> methods on
OntModel allow us to construct an intersection or union directly.
@@ -1794,7 +1805,7 @@ that <code>m</code> is a model into whic
<p>Union and intersection class expressions are very similar, so
Jena defines a common super-class
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/BooleanClassDescription.html"><code>BooleanClassDescription</code></a>.
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/BooleanClassDescription.html"><code>BooleanClassDescription</code></a>.
This class provides access to the <em>operands</em> to the expression. In
the intersection example above, the operands are the two restrictions. The
<code>BooleanClassDescription</code> class allows us to set the operands
@@ -1803,13 +1814,13 @@ time.</p>
<p>Complement class expressions are very similar. The principal
difference is that they take only a single class as operand, and
therefore do not accept a list of operands.</p>
-<h3 id="enumerated-classes">Enumerated classes</h3>
+<h3 id="enumerated-classes">Enumerated classes<a class="headerlink" href="#enumerated-classes" title="Permanent link">¶</a></h3>
<p>The final type class expression allows by OWL is the enumerated
class. Recall that a class is a set of individuals. Often, we want
to define the members of the <em>implicitly</em>: for example, "the class
of UK conferences". Sometimes it is convenient to define a class
<em>explicitly</em>, by stating the individuals the class contains. An
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/EnumeratedClass.html">enumerated class</a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/EnumeratedClass.html">enumerated class</a>
is exactly the class whose members are the given individuals. For
example, we know that the class of PrimaryColours contains exactly
red, green and blue, and no others.</p>
@@ -1848,9 +1859,9 @@ following:</p>
<p>An OWL <code>DataRange</code> is similar to an enumerated class, except that the members
of the <code>DataRange</code> are literal values, such as integers, dates or strings. See the
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/DataRange.html"><code>DataRange</code> javadoc</a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/DataRange.html"><code>DataRange</code> javadoc</a>
for more details.</p>
-<h3 id="listing-classes">Listing classes</h3>
+<h3 id="listing-classes">Listing classes<a class="headerlink" href="#listing-classes" title="Permanent link">¶</a></h3>
<p>In many applications, we need to inspect the set of classes
in an ontology. The <code>list...</code> methods on <code>OntModel</code> provide a variety
of means of listing types of class. The methods available include:</p>
@@ -1879,7 +1890,7 @@ get a list of named hierarchy root class
that lie closest to the top of the hierarchy (alternatively: the
shallowest fringe of the hierarchy consisting solely of named
classes), use the
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/OntTools.html">OntTools</a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/OntTools.html">OntTools</a>
method <code>namedHierarchyRoots()</code>.</p>
<p>You should also note that it is important to close the iterators
returned from the <code>list...</code> methods, particularly when the underlying
@@ -1898,14 +1909,14 @@ exploited by the programmer: to list cla
separately, perform the <code>listClasses()</code> and <code>listRestictions()</code>
methods on the base model only, or on a model with no reasoner
attached.</p>
-<h2 id="instances-or-individuals">Instances or individuals</h2>
+<h2 id="instances-or-individuals">Instances or individuals<a class="headerlink" href="#instances-or-individuals" title="Permanent link">¶</a></h2>
<p>In OWL Full any value can be an individual – and
thus the subject of triples in the RDF graph other than ontology
declarations. In OWL Lite and DL, the language terms and the
instance data that the application is working with are kept
separate, by definition of the language. Jena therefore supports a
simple notion of an
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/Individual.html"><code>Individual</code></a>,
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/Individual.html"><code>Individual</code></a>,
which is essentially an alias for <code>Resource</code>. While <code>Individual</code>s
are largely synonymous with <code>Resource</code>s, they do provide an
programming interface that is consistent with the other Java
@@ -1938,7 +1949,7 @@ convenience: OWL and RDFS denote class m
<code>rdf:type</code> property, and methods for manipulating and testing
<code>rdf:type</code> are defined on <code>OntResource</code>. You may use either
approach interchangeably.</p>
-<h2 id="ontology-meta-data">Ontology meta-data</h2>
+<h2 id="ontology-meta-data">Ontology meta-data<a class="headerlink" href="#ontology-meta-data" title="Permanent link">¶</a></h2>
<p>In OWL, but not RDFS, meta-data about the ontology
itself is encoded as properties on an individual of class
<code>owl:Ontology</code>. By convention,
@@ -1955,14 +1966,14 @@ the <em>base URI</em> of the document co
URI may be stated in the document through an <code>xml:base</code> declaration
in the XML preamble. The base URI can also be specified when
reading the document via Jena's Model API (see the <code>read()</code> methods
-on <a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/OntModel.html"><code>OntModel</code></a>
+on <a href="/documentation/javadoc/jena/org/apache/jena/ontology/OntModel.html"><code>OntModel</code></a>
for reference).</p>
<p>We can attach various meta-data statements to this object to
indicate attributes of the ontology as a whole. The Java object
<code>Ontology</code> represents this special instance, and uses the standard
add, set, get, list, test and delete pattern to provide access to
the following attributes:</p>
-<table>
+<table class="table">
<thead>
<tr>
<th>Attribute</th>
@@ -1993,7 +2004,7 @@ contains common meta-data properties, su
version information.</p>
<p>In the Jena API, the ontology's metadata properties can be accessed
through the
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/Ontology.html"><code>Ontology</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/Ontology.html"><code>Ontology</code></a>
interface. Suppose we wish to know the list of URI's that the
ontology imports. First we must obtain the resource representing the
ontology itself:</p>
@@ -2031,7 +2042,7 @@ useful to list the ontology resources in
<p>A common practice is also to use the Ontology element to attach
<a href="http://dublincore.org/">Dublin Core metadata</a>
to the ontology document. Jena provides a copy
-of the Dublin Core vocabulary, in <code>com.hp.hpl.jena.vocabulary.DCTerms</code>.
+of the Dublin Core vocabulary, in <code>org.apache.jena.vocabulary.DCTerms</code>.
To attach a statement saying that the ontology was authored by John
Smith, we can say:</p>
<div class="codehilite"><pre><span class="n">Ontology</span> <span class="n">ont</span> <span class="p">=</span> <span class="n">m</span><span class="p">.</span><span class="n">getOntology</span><span class="p">(</span> <span class="n">baseURI</span> <span class="p">);</span>
@@ -2055,7 +2066,7 @@ meta-data to a model, for example:</p>
document to be imported (or removed). However, by calling
<code>OntModel.setDynamicImports(true)</code>, the model will start noticing
the addition or removal of <code>owl:imports</code> statements.</p>
-<h2 id="ontology-inference-overview">Ontology inference: overview</h2>
+<h2 id="ontology-inference-overview">Ontology inference: overview<a class="headerlink" href="#ontology-inference-overview" title="Permanent link">¶</a></h2>
<p>You have the choice of whether to use the Ontology API with Jena's
reasoning capability turned on, and, if so, which of the various
reasoners to use. Sometimes a reasoner will add information to the
@@ -2094,7 +2105,7 @@ capabilities are supported, and what the
performance are.</p>
<p>The reasoner attached to an ontology model, if any, is specified
through the
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/ontology/OntModelSpec.html"><code>OntModelSpec</code></a>.
+<a href="/documentation/javadoc/jena/org/apache/jena/ontology/OntModelSpec.html"><code>OntModelSpec</code></a>.
The methods <code>setReasoner()</code> and <code>setReasonerFactory()</code> on the model
spec are used to specify a reasoner. The setReasoner variant is
intended for use on a specification which will only be used to
@@ -2115,11 +2126,11 @@ available choices are described in the s
<p>Depending on which of these choices is made, the statements
returned from queries to a given ontology model may vary
considerably.</p>
-<h3 id="additional-notes">Additional notes</h3>
+<h3 id="additional-notes">Additional notes<a class="headerlink" href="#additional-notes" title="Permanent link">¶</a></h3>
<p>Jena's inference machinery defines some specialised services that
are not exposed through the addition of extra triples to the model.
These are exposed by the
-<a href="/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/InfModel.html"><code>InfModel</code></a>
+<a href="/documentation/javadoc/jena/org/apache/jena/rdf/model/InfModel.html"><code>InfModel</code></a>
interface; for convenience OntModel extends this interface to make
these services directly available to the user. Please note that
calling inference-specific methods on an ontology model that does
@@ -2147,7 +2158,7 @@ of the ontology model:</p>
</pre></div>
-<h2 id="working-with-persistent-ontologies">Working with persistent ontologies</h2>
+<h2 id="working-with-persistent-ontologies">Working with persistent ontologies<a class="headerlink" href="#working-with-persistent-ontologies" title="Permanent link">¶</a></h2>
<p>A common way to work with ontology data is to load the ontology
axioms and instances at run-time from a set of source documents.
This is a very flexible approach, but has limitations. In
@@ -2245,7 +2256,7 @@ problem.</p>
<p>A <a href="TODO">sample program</a>
shows the above steps combined, to create an ontology in which both
base model and imports are stored in a persistent database.</p>
-<h2 id="experimental-ontology-tools">Experimental ontology tools</h2>
+<h2 id="experimental-ontology-tools">Experimental ontology tools<a class="headerlink" href="#experimental-ontology-tools" title="Permanent link">¶</a></h2>
<p>Starting with Jena release 2.6, the <code>OntTools</code> class provides a
small collection of commonly-requested utilities for assisting with
ontology processing. Given that this is a new feature, you should
Modified: websites/staging/jena/trunk/content/documentation/query/algebra.html
==============================================================================
--- websites/staging/jena/trunk/content/documentation/query/algebra.html (original)
+++ websites/staging/jena/trunk/content/documentation/query/algebra.html Tue Jul 14 12:52:14 2015
@@ -144,7 +144,18 @@
<div class="col-md-12">
<div id="breadcrumbs"></div>
<h1 class="title">ARQ - SPARQL Algebra</h1>
- <p>A SPARQL query in ARQ goes through several stages of processing:</p>
+ <style type="text/css">
+/* The following code is added by mdx_elementid.py
+ It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+ visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>A SPARQL query in ARQ goes through several stages of processing:</p>
<ul>
<li>String to Query (parsing)</li>
<li>Translation from Query to a SPARQL algebra expression</li>
@@ -160,10 +171,10 @@ found in the SPARQL specification in
of the algebra form to access difefrent graph storage
implementations.</p>
<p>The classes for the datastructures for the algebra resize in the
-package <code>com.hp.hpl.jena.sparql.algebra</code> in the <code>op</code> subpackage.Â
+package <code>org.apache.jena.sparql.algebra</code> in the <code>op</code> subpackage.Â
All the classes are names "<code>Op...</code>"; the interface that they all
offer is "<code>Op</code>".</p>
-<h2 id="viewing-the-algebra-expression-for-a-query">Viewing the algebra expression for a Query</h2>
+<h2 id="viewing-the-algebra-expression-for-a-query">Viewing the algebra expression for a Query<a class="headerlink" href="#viewing-the-algebra-expression-for-a-query" title="Permanent link">¶</a></h2>
<p>The command line tool <a href="cmds.html#arq.qparse">arq.qparse</a> will print
the algebra form of a query:</p>
<div class="codehilite"><pre><span class="n">arq</span><span class="p">.</span><span class="n">qparse</span> <span class="o">--</span><span class="n">print</span><span class="p">=</span><span class="n">op</span> <span class="o">--</span><span class="n">query</span><span class="p">=</span><span class="n">Q</span><span class="p">.</span><span class="n">rq</span>
@@ -175,7 +186,7 @@ the algebra form of a query:</p>
simple format for writing data structures involving RDF terms. It
can be read back in again to produce the Java form of the algebra
expression.</p>
-<h2 id="turning-a-query-into-an-algebra-expression">Turning a query into an algebra expression</h2>
+<h2 id="turning-a-query-into-an-algebra-expression">Turning a query into an algebra expression<a class="headerlink" href="#turning-a-query-into-an-algebra-expression" title="Permanent link">¶</a></h2>
<p>Getting the algebra expression for a Query is simply a matter of
passing the parsed Query object to the transaction function in the
<code>Algebra</code> class:</p>
@@ -198,7 +209,7 @@ algebra. Also, the query produced ma
will yield the same results (for example, filters may be moved
because the SPARQL query algebra translation in the SPARQL
specification moves filter expressions around).</p>
-<h2 id="directly-reading-and-writing-algebra-expression">Directly reading and writing algebra expression</h2>
+<h2 id="directly-reading-and-writing-algebra-expression">Directly reading and writing algebra expression<a class="headerlink" href="#directly-reading-and-writing-algebra-expression" title="Permanent link">¶</a></h2>
<p>The SSE class is a collection of functions to parse SSE expressions
for the SPARQ algebra but also RDF terms, filter expressions and
even dataset and graphs.</p>
@@ -209,7 +220,7 @@ even dataset and graphs.</p>
<p>The SSE class simply calls the appropriate builder operation from
-the <code>com.hp.hpl.jena.sparql.sse.builder</code> package.</p>
+the <code>org.apache.jena.sparql.sse.builder</code> package.</p>
<p>To go with this, there is a collection of writers for many of the
Java structures in ARQ. </p>
<div class="codehilite"><pre><span class="n">Op</span> <span class="n">op</span> <span class="p">=</span> <span class="p">...</span> <span class="p">;</span>
@@ -221,12 +232,12 @@ Java structures in ARQ. </p>
output stream (it manages the conversion to UTF-8) and ARQ own
<code>IndentedWriter</code>s form for embedding in structured output. Again,
SSE is simply passing the calls to the writer operation from the
-<code>com.hp.hpl.jena.sparql.sse.writer</code> package.</p>
-<h2 id="creating-an-algebra-expression-programmatically">Creating an algebra expression programmatically</h2>
+<code>org.apache.jena.sparql.sse.writer</code> package.</p>
+<h2 id="creating-an-algebra-expression-programmatically">Creating an algebra expression programmatically<a class="headerlink" href="#creating-an-algebra-expression-programmatically" title="Permanent link">¶</a></h2>
<p>See the example in <code>src-examples/arq.examples.AlgebraExec</code>.</p>
<p>To produce the complete javadoc for ARQ, download an ARQ
distribution and run the ant task 'javadoc-all'.</p>
-<h2 id="evaluating-a-algebra-expression">Evaluating a algebra expression</h2>
+<h2 id="evaluating-a-algebra-expression">Evaluating a algebra expression<a class="headerlink" href="#evaluating-a-algebra-expression" title="Permanent link">¶</a></h2>
<p>See the example in <code>src-examples/arq.examples.AlgebraExec</code>.</p>
<div class="codehilite"><pre><span class="n">QueryIterator</span> <span class="n">qIter</span> <span class="p">=</span> <span class="n">Algebra</span><span class="p">.</span><span class="n">exec</span><span class="p">(</span><span class="n">op</span><span class="p">,</span><span class="n">graph</span><span class="p">)</span> <span class="p">;</span>
Modified: websites/staging/jena/trunk/content/documentation/query/app_api.html
==============================================================================
--- websites/staging/jena/trunk/content/documentation/query/app_api.html (original)
+++ websites/staging/jena/trunk/content/documentation/query/app_api.html Tue Jul 14 12:52:14 2015
@@ -144,14 +144,25 @@
<div class="col-md-12">
<div id="breadcrumbs"></div>
<h1 class="title">ARQ - Application API</h1>
- <p>The application API is in the package <code>com.hp.hpl.jena.query</code>.</p>
+ <style type="text/css">
+/* The following code is added by mdx_elementid.py
+ It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+ visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>The application API is in the package <code>org.apache.jena.query</code>.</p>
<p>Other packages contain various parts of the system (execution
engine, parsers, testing etc). Most applications will only need to
use the main package. Only applications wishing to programmatically
build queries or modify the behaviour of the query engine need to
use the others packages directly.</p>
-<h2 id="key-classes">Key Classes</h2>
-<p>The package <code>com.hp.hpl.jena.query</code> is the main application
+<h2 id="key-classes">Key Classes<a class="headerlink" href="#key-classes" title="Permanent link">¶</a></h2>
+<p>The package <code>org.apache.jena.query</code> is the main application
package.</p>
<ul>
<li><code>Query</code> - a class that represents the application query. It is
@@ -170,7 +181,7 @@ package.</p>
</ul>
</li>
</ul>
-<h2 id="select-queries">SELECT queries</h2>
+<h2 id="select-queries">SELECT queries<a class="headerlink" href="#select-queries" title="Permanent link">¶</a></h2>
<p>The basic steps in making a SELECT query are outlined in the
example below. A query is created from a string using the
<code>QueryFactory</code>. The query and model or RDF dataset to be queried
@@ -178,7 +189,7 @@ are then passed to <code>QueryExecutionF
of a query execution. <code>QueryExecution</code> objects are <code>java.lang.AutoCloseable</code>
and can be used in try-resource. Result are handled in a loop and finally the
query execution is closed.</p>
-<div class="codehilite"><pre> <span class="n">import</span> <span class="n">com</span><span class="p">.</span><span class="n">hp</span><span class="p">.</span><span class="n">hpl</span><span class="p">.</span><span class="n">jena</span><span class="p">.</span><span class="n">query</span><span class="o">.*</span> <span class="p">;</span>
+<div class="codehilite"><pre> <span class="n">import</span> <span class="n">org</span><span class="p">.</span><span class="n">apache</span><span class="p">.</span><span class="n">jena</span><span class="p">.</span><span class="n">query</span><span class="o">.*</span> <span class="p">;</span>
<span class="n">Model</span> <span class="n">model</span> <span class="p">=</span> <span class="p">...</span> <span class="p">;</span>
<span class="n">String</span> <span class="n">queryString</span> <span class="p">=</span> " <span class="p">....</span> " <span class="p">;</span>
<span class="n">Query</span> <span class="n">query</span> <span class="p">=</span> <span class="n">QueryFactory</span><span class="p">.</span><span class="n">create</span><span class="p">(</span><span class="n">queryString</span><span class="p">)</span> <span class="p">;</span>
@@ -211,7 +222,7 @@ following is also a way to process the r
<p>The step of creating a query and then a query execution can be
reduced to one step in some common cases:</p>
-<div class="codehilite"><pre> <span class="n">import</span> <span class="n">com</span><span class="p">.</span><span class="n">hp</span><span class="p">.</span><span class="n">hpl</span><span class="p">.</span><span class="n">jena</span><span class="p">.</span><span class="n">query</span><span class="o">.*</span> <span class="p">;</span>
+<div class="codehilite"><pre> <span class="n">import</span> <span class="n">org</span><span class="p">.</span><span class="n">apache</span><span class="p">.</span><span class="n">jena</span><span class="p">.</span><span class="n">query</span><span class="o">.*</span> <span class="p">;</span>
<span class="n">Model</span> <span class="n">model</span> <span class="p">=</span> <span class="p">...</span> <span class="p">;</span>
<span class="n">String</span> <span class="n">queryString</span> <span class="p">=</span> " <span class="p">....</span> " <span class="p">;</span>
<span class="k">try</span> <span class="p">(</span><span class="n">QueryExecution</span> <span class="n">qexec</span> <span class="p">=</span> <span class="n">QueryExecutionFactory</span><span class="p">.</span><span class="n">create</span><span class="p">(</span><span class="n">queryString</span><span class="p">,</span> <span class="n">model</span><span class="p">))</span> <span class="p">{</span>
@@ -221,7 +232,7 @@ reduced to one step in some common cases
</pre></div>
-<h3 id="passing-a-result-set-out-of-the-processing-loop">Passing a result set out of the processing loop.</h3>
+<h3 id="passing-a-result-set-out-of-the-processing-loop">Passing a result set out of the processing loop.<a class="headerlink" href="#passing-a-result-set-out-of-the-processing-loop" title="Permanent link">¶</a></h3>
<p>A <code>ResultSet</code> is an iterator and can be traversed only once. What is more, much of query execution
and result set processing is handled internally in a streaming fashion. The <code>ResultSet</code> returned
by <code>execSelect</code> is not valid after the <code>QueryExecution</code> is closed,
@@ -243,7 +254,7 @@ the data. It is not possible to update
over the results of a <code>SELECT</code> query.</p>
<p>The models returned by <code>execConstruct</code> and <code>execDescribe</code> are valid
after the <code>QueryExecution</code> is closed.</p>
-<h3 id="example-formatting-a-result-set">Example: formatting a result set</h3>
+<h3 id="example-formatting-a-result-set">Example: formatting a result set<a class="headerlink" href="#example-formatting-a-result-set" title="Permanent link">¶</a></h3>
<p>Instead of a loop to deal with each row in the result set, the
application can call an operation of the <code>ResultSetFormatter</code>. This
is what the command line applications do.</p>
@@ -258,7 +269,7 @@ is what the command line applications do
</pre></div>
-<h3 id="example-processing-results">Example: Processing results</h3>
+<h3 id="example-processing-results">Example: Processing results<a class="headerlink" href="#example-processing-results" title="Permanent link">¶</a></h3>
<p>The results are objects from the Jena RDF API and API calls, which
do not modify the model, can be mixed with query results
processing:</p>
@@ -285,7 +296,7 @@ processing:</p>
has finished. Typically, this involves collecting results of
interest in a local datastructure and looping over that structure
after the query execution has finished and been closed.</p>
-<h2 id="construct-queries">CONSTRUCT Queries</h2>
+<h2 id="construct-queries">CONSTRUCT Queries<a class="headerlink" href="#construct-queries" title="Permanent link">¶</a></h2>
<p><code>CONSTRUCT</code> queries return a single RDF graph. As usual, the query
execution should be closed after use.</p>
<div class="codehilite"><pre><span class="n">Query</span> <span class="n">query</span> <span class="p">=</span> <span class="n">QueryFactory</span><span class="p">.</span><span class="n">create</span><span class="p">(</span><span class="n">queryString</span><span class="p">)</span> <span class="p">;</span>
@@ -295,7 +306,7 @@ execution should be closed after use.</p
</pre></div>
-<h2 id="describe-queries">DESCRIBE Queries</h2>
+<h2 id="describe-queries">DESCRIBE Queries<a class="headerlink" href="#describe-queries" title="Permanent link">¶</a></h2>
<p><code>DESCRIBE</code> queries return a single RDF graph.Â
<a href="extension.html#describeHandlers">Different handlers</a> for the
<code>DESCRIBE</code> operation can be loaded by added by the application.</p>
@@ -306,7 +317,7 @@ execution should be closed after use.</p
</pre></div>
-<h2 id="ask-queries">ASK Queries</h2>
+<h2 id="ask-queries">ASK Queries<a class="headerlink" href="#ask-queries" title="Permanent link">¶</a></h2>
<p>The operation Query.execAsk() returns a boolean value indicating
whether the query pattern matched the graph or dataset or not.</p>
<div class="codehilite"><pre><span class="n">Query</span> <span class="n">query</span> <span class="p">=</span> <span class="n">QueryFactory</span><span class="p">.</span><span class="n">create</span><span class="p">(</span><span class="n">queryString</span><span class="p">)</span> <span class="p">;</span>
@@ -316,11 +327,11 @@ whether the query pattern matched the gr
</pre></div>
-<h2 id="formatting-xml-results">Formatting XML results</h2>
+<h2 id="formatting-xml-results">Formatting XML results<a class="headerlink" href="#formatting-xml-results" title="Permanent link">¶</a></h2>
<p>The <code>ResultSetFormatter</code> class has methods to write out the
<a href="http://www.w3.org/TR/rdf-sparql-XMLres/">SPARQL Query Results XML Format</a>.
See ResultSetFormatter.outputAsXML method.</p>
-<h2 id="datasets">Datasets</h2>
+<h2 id="datasets">Datasets<a class="headerlink" href="#datasets" title="Permanent link">¶</a></h2>
<p>The examples above are all queries on a single model. A SPARQL
query is made on a dataset, which is a default graph and zero or
more named graphs. Datasets can be constructed using the