Author: wikier
Date: Fri Oct 9 15:48:32 2015
New Revision: 1707763
URL: http://svn.apache.org/viewvc?rev=1707763&view=rev
Log:
minor clarifications
Modified:
marmotta/site/trunk/content/markdown/kiwi/sparql.md.vm
Modified: marmotta/site/trunk/content/markdown/kiwi/sparql.md.vm
URL:
http://svn.apache.org/viewvc/marmotta/site/trunk/content/markdown/kiwi/sparql.md.vm?rev=1707763&r1=1707762&r2=1707763&view=diff
==============================================================================
--- marmotta/site/trunk/content/markdown/kiwi/sparql.md.vm (original)
+++ marmotta/site/trunk/content/markdown/kiwi/sparql.md.vm Fri Oct 9 15:48:32
2015
@@ -57,9 +57,10 @@ connecting to the backend database). Dep
### PostgreSQL
-In PostgreSQL, it is necessary to install the pgcrypto extension from the
contrib package into the Marmotta database.
-Depending on your operating system and distribution, this might also require
installation of additional software packages
-(under Debian: postgresql-contrib). To install the pgcrypto extension, connect
to the database as superuser and run
+In PostgreSQL, it is necessary to install the `pgcrypto` extension (version
`>=1.1`) from the contrib package into the
+Marmotta database. Depending on your operating system and distribution, this
might also require installation of additional
+software packages (under Debian:
[postgresql-contrib](packages.debian.org/postgresql-contrib)). To install the
`pgcrypto`
+extension, connect to the database as superuser and run
CREATE EXTENSION IF NOT EXISTS pgcrypto;
@@ -68,9 +69,8 @@ To connect to the `marmotta` database as
su - postgres
psql marmotta
-You can also use a graphical UI like pgadmin, but make sure to call the
command on the correct database (not the whole
-server).
-
+You can also use a graphical UI, like [pgAdmin](http://www.pgadmin.org/), but
make sure to call the command on the correct
+database (not the whole server).
Performance Considerations
@@ -82,13 +82,13 @@ conjunction with the KiWi triple store.
to keep in mind that certain queries will still be problematic. To improve
SPARQL performance, try to follow the following recommendations:
-* **avoid DISTINCT, ORDER BY, GROUP BY**: filtering out duplicates is a
+* **avoid `DISTINCT`, `ORDER BY`, `GROUP BY`**: filtering out duplicates is a
performance killer, as it requires to first load all results into memory; if
you do not strictly need it, do not use it
-* **use LIMIT**: limiting the number of results helps the underlying SQL query
planner
+* **use `LIMIT`**: limiting the number of results helps the underlying SQL
query planner
to create better query plans, so your query will perform better
-* **use FILTER**: conditions in the FILTER part of a query will be translated
- into WHERE conditions in SQL; the more precise your filter conditions are,
the
+* **use `FILTER`**: conditions in the `FILTER` part of a query will be
translated
+ into `WHERE` conditions in SQL; the more precise your filter conditions are,
the
better your query will perform
Differences from SPARQL Standard
@@ -102,7 +102,7 @@ support them instead.
### OPTIONAL and significant order
There is a special border case where according to the SPARQL standard the
position of
-the OPTIONAL part gives different semantics. Consider the following two SPARQL
queries:
+the `OPTIONAL` part gives different semantics. Consider the following two
SPARQL queries:
SELECT * WHERE {
?s :p1 ?o1 .
@@ -118,15 +118,16 @@ vs
OPTIONAL { ?s :p2 ?o2 }
}
-According to the SPARQL standard, the first query only yields results when the
values for :p2 and :p3 are the same,
-while the second query essentially ignores the OPTIONAL. Since SQL has a
declarative semantics where the order of
-statements does not matter, we do not support this case. We always implement
the semantics of the second
+According to the SPARQL standard, the first query only yields results when the
values for `:p2` and `:p3` are the
+same, while the second query essentially ignores the OPTIONAL. Since SQL has a
declarative semantics where the order
+of statements does not matter, we do not support this case. We always
implement the semantics of the second
SPARQL query.
### MINUS, EXISTS and inner FILTER variable scope
-According to the SPARQL standard, variables occurring in the left and right
argument of a MINUS are scoped
-to their individual arguments. Since we translate this case into a NOT EXISTS,
our implementation does not support
+According to the SPARQL standard, variables occurring in the left and right
argument of a `MINUS` are scoped
+to their individual arguments. Since we translate this case into a `NOT
EXISTS`, our implementation does not support
this case, which can yield unexpected results for certain queries. These cases
should be solved by proper variable
-renaming. All other differences between MINUS and NOT EXISTS are implemented
according to the standard.
+renaming. All other differences between `MINUS` and `NOT EXISTS` are
implemented according to the standard.
+
