History | Log In     View a printable version of the current page. Get help!  
Issue Details [XML]

Key: SES-23
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Arjohn Kampman
Reporter: Arjohn Kampman
Votes: 6
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
Sesame

Statement context mechanism

Created: 27/Feb/04 03:19 PM   Updated: 14/Nov/05 03:40 PM
Component/s: RDBMS Sail, Memory Sail
Affects Version/s: None
Fix Version/s: 2.0-alpha-1


 Description   
It would be very helpful if we had a statement context mechanism in Sesame. With "context mechanism" I mean a mechansim to create named groups of statements. Such a mechanism could e.g. be used to track the source of statements: all statements from file A have context A, etc.

One very useful feature that could be added to Sesame once we have such a context mechanism is the ability to remove from a repository all statements that are in a specific context. In the described use case this would come down to the unloading of one specific RDF file.

 All   Comments   Change History      Sort Order:
Comment by Jeen Broekstra [10/Sep/04 11:37 AM]
This feature will be _the_ feature for release 1.2: it requires significant code changes throughout the architecture, and an extension of the SeRQL query language.

The plan is to extend SAIL API statement methods with a 'context' parameter that takes a URI as argument. Sesame will be agnostic to the semantics of the context, and will simply use it as a statement grouping mechanism. Thus, provenance but also other features (like confidence or temporality) can be encoded through this feature.

Most of the coding work will consist of a generalization of the mechanisms already implemented in the VersioningSail and SecuritySail. The backend implementation is therefore not the main bottleneck, but rather, how to properly integrate this new feature in the different API layers.

Comment by Jeen Broekstra [07/Feb/05 11:07 AM]
We've decided to reschedule this for 1.3 and concentrate on query language extensions in the 1.2 release.

Comment by Rahul Merwah [03/Jun/05 01:43 AM]
As per Jeen's comment above "... it requires significant code changes throughout the architecture, and an extension of the SeRQL query language" it would seem that one barrier is just resources committed to solving the problem.

This seems to be the most popular issue based on votes and my company (Ecosystems) also needs this functionality right now. We are currently in a position to donate at least 1 to 2 full time resources to help crack the problem.

I would like to use this comment to ask who else would be interested stakeholders and who else might want to help with solving this issue? I have sent an email note to Jeen as well but I'm guessing he's very busy and will get to it eventually. In the meantime, if I can identify all the interested parties we can get together via email to analyze the overall problem and propose a set of changes, post them here for verification, and then get just to implement them. If anyone else has had a headstart on what changes actually need to be done, please let us know here so that we can reduce duplication of efforts.

Regards,
- Rahul Merwah

Comment by Arjohn Kampman [13/Jun/05 01:23 PM]
Given the amount of changes to APIs and code required for this feature, the release that includes this will be called "2.0".