Re: FSL engine for Sesame

From: Emmanuel Pietriga <>
Date: Wed, 23 Nov 2005 14:17:58 +0100

Emmanuel Pietriga wrote:
> Ryan Lee wrote:
>> Emmanuel Pietriga wrote:
>>> Ryan Lee wrote:
>>>>>> As Sesame 2 is still in alpha and we haven't made the jump there
>>>>>> for any
>>>>>> SIMILE code, I needed to adapt your work to Sesame 1.2.2. This was
>>>>>> mostly just a matter of switching out the *Vertex code for the older
>>>>>> style of finding things in the store and using the older way of
>>>>>> loading data into a Graph.
>>>>> That's good news. We have kind of a 4th implementation. Once you've
>>>>> finalized it, could we consider making it available publicly as a
>>>>> standalone JAR, as I've done for the Jena and Sesame 2
>>>>> implementations ?
>>>> I'd be glad to, but I'd also like to keep it under version control.
>>>> I'm not sure how best to do that - the easiest way to just get it
>>>> done is to fork from your codebase and store it somewhere on
>>>>, but I don't know that forking is a good thing
>>>> considering the small number of changes needed.
>>> Are you only talking about your specific specific class for Sesame
>>> 1.2.2, or about having a complete standalone src code version
>>> including the grammar and shared part of the code (FSLEvaluator,
>>> FSLPath, etc.)?
>>> As far as I am concerned, hosting the Sesame122 evaluator in Simile's
>>> SVN repository is fine. I would just like to avoid duplicating the
>>> code for everything else (all the FSLPath stuff that is repository
>>> type independent, and FSLEvaluator which centralizes all that can be
>>> shared across implementations). If making the Sesame122 evaluator
>>> part of a package other than org.w3c.IsaViz.fresnel causes access
>>> restriction issues, let me know and I'll make the required changes.
>> I think the key issue is the dependence on the HierarchyStore and
>> Jena. If that Jena dependence could be factored out, I could probably
>> put something together in our repository that didn't duplicate the
>> rest of the FSL code.
> I was planning on fixing this today or tomorrow. What I'll do is make
> FSLHierarchyStore a class from which others will inherit (one for Jena,
> one for Sesame, etc.). I should have it ready by Thursday.

I just commited these changes. FSLHierarchyStore is now a class from
which FSLJenaHierarchyStore and FSLSesameHierarchyStore inherit. The
Jena and Sesame evaluators should be completely decoupled now. FSL
evaluators that are not interested in supporting RDFS/OWL hierarchy can
now instantiate an empty FSLHierarchyStore() as it does not require any
specific RDF library such as Jena or Sesame.

I've also added a new test suite that tests the creation of simple class
and property hierarchies with both the Jena and Sesame version.

I've implemented the Sesame version with Sesame 2-alpha1, using their
SeRQL language.

Emmanuel Pietriga
INRIA Futurs - Projet In Situ    tel : +33 1 69 15 34 66
Bat 490, Université Paris-Sud    fax : +33 1 69 15 65 86
91405 ORSAY Cedex FRANCE
Received on Wed Nov 23 2005 - 13:11:45 EST

This archive was generated by hypermail 2.3.0 : Thu Aug 09 2012 - 16:40:51 EDT