Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Introduce "pseudo" named graph for addressing default context in SPARQL

Description

The Sesame 'default context' consists of all triples in the Repository that do not have an associated context. Although this set of triples is explicitly addressable via the Repository API, via: connection.getStatements(null, null, true, (Resource)null); There is currently no way to specifically address these triples in the SPARQL engine (since the SPARQL engine's default graph consists of all triples in the store, not just the ones in the default context). A possible solution to this problem is to introduce a URI constant that represents a 'virtual' named graph that contains exactly those triples that do not have a context. The proposed name for this constant is sesame:default.

Environment

None

Activity

Show:

Jeen BroekstraOctober 29, 2015 at 12:43 AM

This issue was resolved earlier and a release has been done that includes a fix (if applicable), so this can now be closed.

Jeen BroekstraJanuary 9, 2015 at 2:06 AM

Considering this resolved - we'll just leave both in.

Michael GroveNovember 1, 2013 at 11:13 AM

We have constants we use to identify the default context & one to represent the union of all named graphs & the default context within the database. Because I disagree about what the active graph is when nothing is provided from the user (we take the stance that its the default graph), the constant for the default context is rarely used outside of our internals because aside from squirrelly dataset definitions, you wouldn't need to use it.

But I implemented the support for DEFAULT to make it easier for people to takes queries from other Sesame systems and run them in Stardog. I've done the same with a lot of ARQ-specific features, and I've got an intern working on things that are only in Leviathan, which is dotNetRDF's query engine.

That aside, I think "FROM DEFAULT" is more clear than "FROM sesame:nil". I take Jeen's point that using sesame:nil makes it more clear that it's an implementation specific thing, and that's true, but I think FROM DEFAULT is more clear from a user's perspective.

Quite frankly, I think it's absurd that what the default active graph is was not specified in the spec. That just leads to 100% compliant SPARQL engines giving you different results on the same query because they have a different opinion about that is. So much for interop!

My two cents is you should change that behavior (I know, that's massively disruptive to users). But I think its more clear to have to specify a constant for the entire database than a constant for the default graph. I'm biased I guess, since that's what I've chosen to implement, but we've never had push-back or general confusion from our users. But we also provide a flag to switch over to a Sesame behavior-compatible mode, so it could be that everyone just uses that =)

Don't leave it in on my account. I think it's a better syntax, but it's only one line of code for me to support (or not) the constant, so we're not exactly put out by it. And I can always fork the parser and put it back if it really bugs me =)

Jeen BroekstraOctober 31, 2013 at 10:07 PM

Or maybe not feedback from mailinglist (notably ) indicates FROM DEFAULT is already in use.

Jeen BroekstraOctober 31, 2013 at 7:38 PM

Scheduled to be settled for the 2.8 release. "sesame:nil" will remain, "FROM DEFAULT" will be removed.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Priority

Who's Looking?

Open Who's Looking?

Created October 10, 2011 at 6:40 AM
Updated October 29, 2015 at 12:43 AM
Resolved January 9, 2015 at 2:06 AM
Who's Looking?