Blog

Variable SPARQL Service Locations

The SPARQL grammar—in particular the ServiceGraphPattern production— indicates that it should be possible to specify either an IRI or a variable as a service location.[1] The W3C’s “SPARQL 1.1 Federated Query” recommendation[2] 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...

Collation Sequences in SPARQL

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 ratifies the type rdf:langString, it defines no relation beyond equality, which leaves 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…

Continue reading...

Extended Temporal Datatype Support

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:

  • xsd:date
  • xsd:dateTime
  • xsd:time

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:

  • xsd:dayTimeDuration
  • xsd:yearMonthDuration
  • xsd:gDay
  • xsd:gMonth
  • xsd:gMonthDay
  • xsd:gYear
  • xsd:gYearMonth
Continue reading...