Formulate constraints on RDF terms, notably literals. These are
intended to be used as illustrated below. RDF constraints are
pure: they may be placed before, after or inside a graph pattern
and, provided the code contains no commit operations (!, ->),
the semantics of the goal remains the same. Preferably,
constraints are placed before the graph pattern as they often
help the RDF database to exploit its literal indexes. In the
example below, the database can choose between using the subject
and/or predicate hash or the ordered literal table.
{ Date >= "2000-01-01"^^xsd:date },
rdf(S, P, Date)
The following constraints are currently defined:
- (>),(>=),(==),(=<),(<)
- The comparison operators are defined between numbers (of any
recognised type), typed literals of the same type and
langStrings of the same language.
- prefix(String, Pattern)
- substring(String, Pattern)
- word(String, Pattern)
- like(String, Pattern)
- icase(String, Pattern)
- Text matching operators that act on both typed literals
and langStrings.
- lang_matches(Term, Pattern)
- Demands a full RDF term (Text@Lang) or a plain Lang term
to match the language pattern Pattern.
The predicates rdf_where/1 and {}/1 are identical. The
rdf_where/1 variant is provided to avoid ambiguity in
applications where {}/1 is used for other purposes. Note that it
is also possible to write rdf11:{...}
.