The SPARQL grammar—in particular the
indicates that it should be possible to
specify either an IRI or a variable as a service
The W3C’s “SPARQL 1.1 Federated Query” recommendation does not, however,
define an evaluation semantics for a service variable.
It indicates only, that
“the service call for any solution depends on that variable’s binding in that solution”.
While this suggestion seems sensible, it neglects to consider that without further specification, the only semantics available to define the scope of the variable and, as a consequence, “that solution”, is the standard bottom-up reduction which applies to SPARQL evaluation, which leaves the variable at the point of reference at best unbound—and likely statically undefined.
Dydra had chosen to avoid this deficiency of the specification by proscribing variable service locations. As part of our work to make historical repository revisions available as first-class datasets and to integrate access to revision meta-data stored in provenance records, we recognize that there would be great value to be found in computing revision identifiers for use as internal federation locations…Continue reading...
The SPARQL query language is relatively silent about how to order strings. When the question was posed to us a while back, what to expect as the order of a solution sequence which contained string literals with language tags, we had just the conservative answer that the relation among simple or string literals and plain literals was undefined. This was not a nice situation.
Even though RDF 1.1
rdf:langString, it defines no relation beyond equality,
plfn:compare to apply but requires some context where it is possible to determine
the collation sequence.
This situation is not quite as unpleasant, but still not satisfactory.
Fortunately ‘undefined’ leaves latitude for improvement, by definition…
Dydra recently extended its native support to cover the full XSD temporal data type complement. This means not only that our platform continues to provide compact native representations for the core data types:
where each term requires one cell – that is, eight bytes, but, in addition, SPOCQ, Dydra’s SPARQL processor, implements internal data classes for the remaining types:
- Quads with a View
- BGP Statement Pattern Counts
- Support Issue Workflow
- Simplified SPARQL Aggregates
- DAWG Test Suite for SPOCQ
- SPARQL 1.1 Now Supported
- SP2B Benchmark Results
- Tuning SPARQL Queries
- Default Prefixes
- Using the Dydra CLI
- New Privacy Options available!
- Get Your Named Graphs!
- Dydra Lifts Off