dotnetrdf-develop

Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf

[Rob V. <rv...@do...>]

Hey Kevin

Discussion inline:

From:  Kevin <ke...@th...>
Date:  Wednesday, March 13, 2013 7:40 PM
To:  Rob Vesse <rv...@do...>
Subject:  Integrating SPIN into dotnetrdf

> Rob,
>  
> First thank you for your quality work you have done with the dotnetrdf
> project.  I have seen a few different posts about your initiative to integrate
> SPIN into dotnetrdf (ie.  SPIN Post
> <http://answers.semanticweb.com/questions/537/experiences-with-spin> ).  After
> much reading on the subject it really seems that SPIN would really
> propel/complement dotnetrdf.  I believe SPIN not only makes up for the missing
> OWL inference (Via SPIN OWL-RL implementation), it also can expand to suit the
> modelers imagination.  The fact that the rules are in SPARQL makes for an
> unbeatable solution.  Should it matter my current effort involves query a
> Virtuoso database (Some owl support) with dotnetrdf.  I would really
> appreciate you taking a look at the questions below:
>  
> -Have you made any further progress on integrating SPIN into dotnetrdf?  Would
> you allow me to have the source code in its current state?  Could I possibly
> be a contributor on this cause as I am not really equipped for the full task?
> In any case I would appreciate any source code which I could use as a learning
> tool.

No I haven't had time to do anything on SPIN for a long time now.  I've been
primarily concentrating on getting core features stabilized such as the
SPARQL engine which are obviously fairly key to building stuff like SPIN on
top.

However I still don't have time to work on SPIN directly so if you want to
work on this please feel free, find the code in the mercurial repository at
https://bitbucket.org/dotnetrdf/dotnetrdf

The previous and very minimal SPIN stub is under Libraries\Query\Spin,
create your own fork and then you can send pull requests as and when you
have something to 

The key things that need to be done to get the core of SPIN implemented are
as follows:
* Update the current spin-sparql-syntax.ttl to a current version, it likely
doesn't represent the current version of the spec (this is primarily a
convenience reference for developers)
* Finish the existing stubs for converting queries into their SPIN RDF
representation (see SpinSyntax.cs)
* Write code to turn a RDF encoding of a SPIN query into a query
The middle one would be the easiest to start with since there is already
some partial stubs to get you started.

>  
> -From the available TopQuadrant documentation I have tried to deduce how
> dotnetrdf might implement SPIN.  According to SPIN tutrial
> <http://dallemang.typepad.com/my_weblog/2010/08/extending-owl-rl-.html> ,
> TopBraid finds all SPIN inferecer rules and runs them when you hit play.
> Would dotnetrdf SPIN inferencer only run the rules that are associated with
> the class structure being queried?  Basically I am confused how dotnetrdf
> decides when/how/which SPIN rules to run for a given query.

That's an implementation detail, we would control how and when rules get
run.  We need to get the basic implementation of SPIN done first before this
aspect of things gets implemented anyway.

>  
> -How much of SPIN could dotnetrdf possibly support.? It appears SPIN contains
> Inference Rules, Constraint Checking, and ability to Isolate rules for certain
> conditions.  Also the TopBraid tool seems to have  "User-Defined SPARQL
> functions" and "SPIN Query Templates".  I imagine dotnetrdf would have to keep
> up with any SPIN improvements.

All of those are supportable in some shape of form, until we have the core
of SPIN up and running we can't really implement those.  Most of those
features run on top of the SPIN core and so will ultimately just be
implementation details once we have a core to build upon.  User defined
SPARQL functions are basically just SPARQL queries that return a single
value and query templates are just parameterized queries both of which the
existing SPARQL engine is capable of supporting in one way or another.  So
it is just a case of exposing that functionality in the SPIN style.

Hope this is enough to get you started, if not please let us know,

Rob

>  
> Regards,
> Kevin

Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf

[Kevin <ke...@th...>]

Rob, Tom

 

After more reading I believe a dotnetrdf/SPIN/Fluent SPARQL would be an
excellent solution.  In fact I would think people would convert to C#
dotnetrdf due to this compiling story.

 

Strategy Questions:

 

Due to my knowledge, time constraints, and past experience I know if I
attempt SPIN dotnetrdf alone it will drag out and never complete.  Can you
let me know if any of the strategies below make any sense.  Both strategies
involve splitting the work with the understanding that we are all busy and
there is no real obligation.  Also I assume any knowledgeable new comer is
welcomed to contribute to the cause.  I believe the effort will obviously
benefit the community, but also provide a deep insight to the contributing
developers.

 

-Convert the Java TopBraid SPIN API <http://topbraid.org/spin/api/>  (Uses
Jena <http://jena.apache.org/>  interface) into C# starting with a
conversion tool like Tangible Java-
<http://www.tangiblesoftwaresolutions.com/Product_Details/Java_to_CSharp_Con
verter.html> >C# (I will purchase).  The tool will help with most of the
syntax, but there will be a lot of manual work.  The conversion will
obviously entail replacing the Jena <http://jena.apache.org/>  interface
with dotnetrdf.  The benefits of this strategy is we harness the
completeness, robustness, and future updates (re-port changes) of TopBraid
SPIN API.  The conversion should provide insights into the implementation
enabling custom tweaks.  It should also be possible to split the converted
Java files into 3 groups if you guys are up for the task.  I am in
preference of this solution primarily because we are essential creating a
SPIN inference engine based upon code from the people who invented SPIN.

 

-Follow your initial start at SPIN dotnetrdf and maybe use TopBraid SPIN API
as a reference (Difficult because approaches will diverge).  Rob are you a
take any small essential blocks and coordinate the overall effort?  Tom are
you able to help out, especially where Fluent SPARQL is utilized?  Again I
think the alternate strategy above has a lot of merit, but it must align
with Rob's vision.   No matter the strategy please look at the
implementation questions below to help clarify the high/low level picture.

 

Implementation Questions:

 

-Can you provide a high level overview of a SPIN dotnetrdf implementation so
I can ensure the final solution is acceptable.  Let's say you have the SPIN
rule for "adult rdfs:subclassof person" at the top-level (ie. owl:Thing) and
the user queries is Elvis a Adult.   Would dotnetrdf  SPIN spawn numerous
intermediate SPARQL queries to gather the important SPIN rules that must be
executed?  If RDF database is remote (ie. dbpedia) could this accumulative
delay become unacceptably (Over 3 seconds in my application).  Alternatively
is everything required by the user query obtained in 1 or 2 complex
intermediate queries which dotnetrdf SPIN creates and digests?  Basically if
you could paint the high level overview with an example I could then move to
the details.

 

-Can you provide a low-level overview of your SPIN dotnetrdf implementation
strategy.  I only partially understood you explanation below, which I know
will be a little clearer after looking at the code.  What is
spin-sparql-syntax.ttl and how does it fit into the puzzle?  What does it
mean to convert a query into SPIN RDF representation?  My naive picture is
that a user query is converted into internal query(s) to obtain SPIN RDF
rules, which are then executed by the new SPIN dotnetrdf engine.  Lastly
please explain a little more your view of turning a SPIN query into a query?

 

Thanks,

Kevin

 

From: Rob Vesse [mailto:rv...@do...] 
Sent: Friday, March 15, 2013 2:57 PM
To: Kevin
Cc: dotNetRDF Developer Discussion and Feature Request
Subject: Re: Integrating SPIN into dotnetrdf

 

Hey Kevin

 

Discussion inline:

 

From: Kevin <ke...@th...>
Date: Wednesday, March 13, 2013 7:40 PM
To: Rob Vesse <rv...@do...>
Subject: Integrating SPIN into dotnetrdf

 

Rob,

 

First thank you for your quality work you have done with the dotnetrdf
project.  I have seen a few different posts about your initiative to
integrate SPIN into dotnetrdf (ie.  SPIN Post
<http://answers.semanticweb.com/questions/537/experiences-with-spin> ).
After much reading on the subject it really seems that SPIN would really
propel/complement dotnetrdf.  I believe SPIN not only makes up for the
missing OWL inference (Via SPIN OWL-RL implementation), it also can expand
to suit the modelers imagination.  The fact that the rules are in SPARQL
makes for an unbeatable solution.  Should it matter my current effort
involves query a Virtuoso database (Some owl support) with dotnetrdf.  I
would really appreciate you taking a look at the questions below:

 

-Have you made any further progress on integrating SPIN into dotnetrdf?
Would you allow me to have the source code in its current state?  Could I
possibly be a contributor on this cause as I am not really equipped for the
full task?  In any case I would appreciate any source code which I could use
as a learning tool.

 

No I haven't had time to do anything on SPIN for a long time now.  I've been
primarily concentrating on getting core features stabilized such as the
SPARQL engine which are obviously fairly key to building stuff like SPIN on
top.

 

However I still don't have time to work on SPIN directly so if you want to
work on this please feel free, find the code in the mercurial repository at
https://bitbucket.org/dotnetrdf/dotnetrdf 

 

The previous and very minimal SPIN stub is under Libraries\Query\Spin,
create your own fork and then you can send pull requests as and when you
have something to 

 

The key things that need to be done to get the core of SPIN implemented are
as follows:

*	Update the current spin-sparql-syntax.ttl to a current version, it
likely doesn't represent the current version of the spec (this is primarily
a convenience reference for developers)
*	Finish the existing stubs for converting queries into their SPIN RDF
representation (see SpinSyntax.cs)
*	Write code to turn a RDF encoding of a SPIN query into a query

The middle one would be the easiest to start with since there is already
some partial stubs to get you started.

 

 

-From the available TopQuadrant documentation I have tried to deduce how
dotnetrdf might implement SPIN.  According to SPIN tutrial
<http://dallemang.typepad.com/my_weblog/2010/08/extending-owl-rl-.html> ,
TopBraid finds all SPIN inferecer rules and runs them when you hit play.
Would dotnetrdf SPIN inferencer only run the rules that are associated with
the class structure being queried?  Basically I am confused how dotnetrdf
decides when/how/which SPIN rules to run for a given query.

 

That's an implementation detail, we would control how and when rules get
run.  We need to get the basic implementation of SPIN done first before this
aspect of things gets implemented anyway.

 

 

-How much of SPIN could dotnetrdf possibly support.? It appears SPIN
contains Inference Rules, Constraint Checking, and ability to Isolate rules
for certain conditions.  Also the TopBraid tool seems to have  "User-Defined
SPARQL functions" and "SPIN Query Templates".  I imagine dotnetrdf would
have to keep up with any SPIN improvements.

 

All of those are supportable in some shape of form, until we have the core
of SPIN up and running we can't really implement those.  Most of those
features run on top of the SPIN core and so will ultimately just be
implementation details once we have a core to build upon.  User defined
SPARQL functions are basically just SPARQL queries that return a single
value and query templates are just parameterized queries both of which the
existing SPARQL engine is capable of supporting in one way or another.  So
it is just a case of exposing that functionality in the SPIN style.

 

Hope this is enough to get you started, if not please let us know,

 

Rob

 

 

Regards,

Kevin

Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf

[Tomasz P. <tom...@gm...>]

Comments inline

On Sun, Mar 17, 2013 at 4:56 AM, Kevin <ke...@th...> wrote:
> Rob, Tom
>
>
>
> After more reading I believe a dotnetrdf/SPIN/Fluent SPARQL would be an
> excellent solution.  In fact I would think people would convert to C#
> dotnetrdf due to this compiling story.
>
>
>
> Strategy Questions:
>
>
>
> Due to my knowledge, time constraints, and past experience I know if I
> attempt SPIN dotnetrdf alone it will drag out and never complete.  Can you
> let me know if any of the strategies below make any sense.  Both strategies
> involve splitting the work with the understanding that we are all busy and
> there is no real obligation.  Also I assume any knowledgeable new comer is
> welcomed to contribute to the cause.  I believe the effort will obviously
> benefit the community, but also provide a deep insight to the contributing
> developers.
>
>
>
> -Convert the Java TopBraid SPIN API (Uses Jena interface) into C# starting
> with a conversion tool like Tangible Java->C# (I will purchase).  The tool
> will help with most of the syntax, but there will be a lot of manual work.
> The conversion will obviously entail replacing the Jena interface with
> dotnetrdf.  The benefits of this strategy is we harness the completeness,
> robustness, and future updates (re-port changes) of TopBraid SPIN API.  The
> conversion should provide insights into the implementation enabling custom
> tweaks.  It should also be possible to split the converted Java files into 3
> groups if you guys are up for the task.  I am in preference of this solution
> primarily because we are essential creating a SPIN inference engine based
> upon code from the people who invented SPIN.
>
>

Has TopBraid opened all of their SPIN API? Last time I looked only
parts were open source. I wonder that it got no attention at
semanticweb.com. Or did it?

Regarding the first strategy I undersnatd it is very appealing but I'm
afraid converting API calls from Jena to dotNetRDF could be more work
than you expect. I don't know Jena very well but I expect that a lot
of the functionality isn't just a simple 1:1 relation. In this case we
are talking about a number of areas:

- Graph traversal for reading SPIN queries in RDF form
- SPARQL query and it's programmatic counterpart
(VDS.RDF.Query.SparqlQuery and others)
- Query execution
- Reasoner

However what we should definitely try to preserve are any unit tests
and possibly some kind of test hareness. I hope the guys at TopBraid
have SPIN thoroughly tested and we should reuse those tests on our
implementation.

>
> -Follow your initial start at SPIN dotnetrdf and maybe use TopBraid SPIN API
> as a reference (Difficult because approaches will diverge).  Rob are you a
> take any small essential blocks and coordinate the overall effort?  Tom are
> you able to help out, especially where Fluent SPARQL is utilized?  Again I
> think the alternate strategy above has a lot of merit, but it must align
> with Rob's vision.   No matter the strategy please look at the
> implementation questions below to help clarify the high/low level picture.
>

Now, if we had not only the Java API reference but also complete
automatic test suite from the start I would opt for the second
approach.

If not available or somehow unusable for a .NET project I think we
could resort to http://spinservices.org/spinrdfconverter.html for
validating our efforts.

Whatever the case I think that starting from scratch rather than
porting Java is likely a better approach in the long run.

>
>
> Implementation Questions:
>
>
>
> -Can you provide a high level overview of a SPIN dotnetrdf implementation so
> I can ensure the final solution is acceptable.  Let's say you have the SPIN
> rule for "adult rdfs:subclassof person" at the top-level (ie. owl:Thing) and
> the user queries is Elvis a Adult.   Would dotnetrdf  SPIN spawn numerous
> intermediate SPARQL queries to gather the important SPIN rules that must be
> executed?  If RDF database is remote (ie. dbpedia) could this accumulative
> delay become unacceptably (Over 3 seconds in my application).  Alternatively
> is everything required by the user query obtained in 1 or 2 complex
> intermediate queries which dotnetrdf SPIN creates and digests?  Basically if
> you could paint the high level overview with an example I could then move to
> the details.
>
>

I think that a complete dotNetRDF implementation of SPIN would require
at least two components.

1. A converter from SPIN/RDF to in-memory queries (not necessarily
VDS.RDF.Query.SparqlQuery - see below)
2. A SPIN runner, which will take a SPIN query and execute it in an
instance's context
3. A reasoner, which uses the above converter and executes the SPIN
rules and constraints againt a graph or triple store

>
>
> -Can you provide a low-level overview of your SPIN dotnetrdf implementation
> strategy.  I only partially understood you explanation below, which I know
> will be a little clearer after looking at the code.  What is
> spin-sparql-syntax.ttl and how does it fit into the puzzle?  What does it
> mean to convert a query into SPIN RDF representation?  My naive picture is
> that a user query is converted into internal query(s) to obtain SPIN RDF
> rules, which are then executed by the new SPIN dotnetrdf engine.  Lastly
> please explain a little more your view of turning a SPIN query into a query?
>
>

Basically I think that a complete solution should work like this:
1. Prepare a metadata (ontology) graph with your SPIN rules/constraints
2. SPIN rules are converted to SPARQL queries
3. Queries are executed against graph/store to produce constraint
violations and inferences/assertions

If you look at the TopBraid videos and SPIN Modelling vocabulary you
will notice that there is much more to SPIN than just converting
queries from RDF representation to SPARQL:
- rule modularization templates
- constructors
- extending SPARQL Engine with functions and magic properties

I agree with Rob that first we would need a converter from SPIN RDF to
SPARQL but its design should be influenced by how we will use it and
we already know very good what that would be. Unfortunately a lot
seems unclear to me when I read the SPIN Modelling documentation. For
one thing there can be many rules and as Kevin wrote, executing many
such rules against a store may not be a good idea.

Kevin, what do you mean by you last question? You have RDF triples,
which represent a query and you traverse the graph to create a query
(string). The IGraph and Fluent SPARQL APIs combined should make this
work easy.

Hope this helps, for now ;)
Tom

>
>
> Thanks,
>
> Kevin
>
>
>
> From: Rob Vesse [mailto:rv...@do...]
> Sent: Friday, March 15, 2013 2:57 PM
> To: Kevin
> Cc: dotNetRDF Developer Discussion and Feature Request
> Subject: Re: Integrating SPIN into dotnetrdf
>
>
>
> Hey Kevin
>
>
>
> Discussion inline:
>
>
>
> From: Kevin <ke...@th...>
> Date: Wednesday, March 13, 2013 7:40 PM
> To: Rob Vesse <rv...@do...>
> Subject: Integrating SPIN into dotnetrdf
>
>
>
> Rob,
>
>
>
> First thank you for your quality work you have done with the dotnetrdf
> project.  I have seen a few different posts about your initiative to
> integrate SPIN into dotnetrdf (ie.  SPIN Post).  After much reading on the
> subject it really seems that SPIN would really propel/complement dotnetrdf.
> I believe SPIN not only makes up for the missing OWL inference (Via SPIN
> OWL-RL implementation), it also can expand to suit the modelers imagination.
> The fact that the rules are in SPARQL makes for an unbeatable solution.
> Should it matter my current effort involves query a Virtuoso database (Some
> owl support) with dotnetrdf.  I would really appreciate you taking a look at
> the questions below:
>
>
>
> -Have you made any further progress on integrating SPIN into dotnetrdf?
> Would you allow me to have the source code in its current state?  Could I
> possibly be a contributor on this cause as I am not really equipped for the
> full task?  In any case I would appreciate any source code which I could use
> as a learning tool.
>
>
>
> No I haven't had time to do anything on SPIN for a long time now.  I've been
> primarily concentrating on getting core features stabilized such as the
> SPARQL engine which are obviously fairly key to building stuff like SPIN on
> top.
>
>
>
> However I still don't have time to work on SPIN directly so if you want to
> work on this please feel free, find the code in the mercurial repository at
> https://bitbucket.org/dotnetrdf/dotnetrdf
>
>
>
> The previous and very minimal SPIN stub is under Libraries\Query\Spin,
> create your own fork and then you can send pull requests as and when you
> have something to
>
>
>
> The key things that need to be done to get the core of SPIN implemented are
> as follows:
>
> Update the current spin-sparql-syntax.ttl to a current version, it likely
> doesn't represent the current version of the spec (this is primarily a
> convenience reference for developers)
> Finish the existing stubs for converting queries into their SPIN RDF
> representation (see SpinSyntax.cs)
> Write code to turn a RDF encoding of a SPIN query into a query
>
> The middle one would be the easiest to start with since there is already
> some partial stubs to get you started.
>
>
>
>
>
> -From the available TopQuadrant documentation I have tried to deduce how
> dotnetrdf might implement SPIN.  According to SPIN tutrial, TopBraid finds
> all SPIN inferecer rules and runs them when you hit play.  Would dotnetrdf
> SPIN inferencer only run the rules that are associated with the class
> structure being queried?  Basically I am confused how dotnetrdf decides
> when/how/which SPIN rules to run for a given query.
>
>
>
> That's an implementation detail, we would control how and when rules get
> run.  We need to get the basic implementation of SPIN done first before this
> aspect of things gets implemented anyway.
>
>
>
>
>
> -How much of SPIN could dotnetrdf possibly support.? It appears SPIN
> contains Inference Rules, Constraint Checking, and ability to Isolate rules
> for certain conditions.  Also the TopBraid tool seems to have  "User-Defined
> SPARQL functions" and "SPIN Query Templates".  I imagine dotnetrdf would
> have to keep up with any SPIN improvements.
>
>
>
> All of those are supportable in some shape of form, until we have the core
> of SPIN up and running we can't really implement those.  Most of those
> features run on top of the SPIN core and so will ultimately just be
> implementation details once we have a core to build upon.  User defined
> SPARQL functions are basically just SPARQL queries that return a single
> value and query templates are just parameterized queries both of which the
> existing SPARQL engine is capable of supporting in one way or another.  So
> it is just a case of exposing that functionality in the SPIN style.
>
>
>
> Hope this is enough to get you started, if not please let us know,
>
>
>
> Rob
>
>
>
>
>
> Regards,
>
> Kevin
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> dotNetRDF-develop mailing list
> dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>

Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf

[Rob V. <rv...@do...>]

Sorry I've been out the discussion but this week is really busy for me.

Comments inline:

On 3/19/13 10:35 AM, "Tomasz Pluskiewicz" <tom...@gm...>
wrote:

>Comments inline
>
>On Sun, Mar 17, 2013 at 4:56 AM, Kevin <ke...@th...> wrote:
>> Rob, Tom
>>
>>
>>
>> After more reading I believe a dotnetrdf/SPIN/Fluent SPARQL would be an
>> excellent solution.  In fact I would think people would convert to C#
>> dotnetrdf due to this compiling story.
>>
>>
>>
>> Strategy Questions:
>>
>>
>>
>> Due to my knowledge, time constraints, and past experience I know if I
>> attempt SPIN dotnetrdf alone it will drag out and never complete.  Can
>>you
>> let me know if any of the strategies below make any sense.  Both
>>strategies
>> involve splitting the work with the understanding that we are all busy
>>and
>> there is no real obligation.  Also I assume any knowledgeable new comer
>>is
>> welcomed to contribute to the cause.  I believe the effort will
>>obviously
>> benefit the community, but also provide a deep insight to the
>>contributing
>> developers.
>>
>>
>>
>> -Convert the Java TopBraid SPIN API (Uses Jena interface) into C#
>>starting
>> with a conversion tool like Tangible Java->C# (I will purchase).  The
>>tool
>> will help with most of the syntax, but there will be a lot of manual
>>work.
>> The conversion will obviously entail replacing the Jena interface with
>> dotnetrdf.  The benefits of this strategy is we harness the
>>completeness,
>> robustness, and future updates (re-port changes) of TopBraid SPIN API.
>>The
>> conversion should provide insights into the implementation enabling
>>custom
>> tweaks.  It should also be possible to split the converted Java files
>>into 3
>> groups if you guys are up for the task.  I am in preference of this
>>solution
>> primarily because we are essential creating a SPIN inference engine
>>based
>> upon code from the people who invented SPIN.
>>
>>
>
>Has TopBraid opened all of their SPIN API? Last time I looked only
>parts were open source. I wonder that it got no attention at
>semanticweb.com. Or did it?
>
>Regarding the first strategy I undersnatd it is very appealing but I'm
>afraid converting API calls from Jena to dotNetRDF could be more work
>than you expect. I don't know Jena very well but I expect that a lot
>of the functionality isn't just a simple 1:1 relation. In this case we
>are talking about a number of areas:
>
>- Graph traversal for reading SPIN queries in RDF form
>- SPARQL query and it's programmatic counterpart
>(VDS.RDF.Query.SparqlQuery and others)
>- Query execution
>- Reasoner

I would echo what Tom said, write code from scratch don't try and port the
existing Java.  As someone who also works on Jena I can confirm what Tom
said that the APIs around queries and different enough that you would
spend far more time extricating Jena from the converted code than if you
just wrote the relevant code yourself.


Also converting code opened source under a different license than
dotNetRDF uses provides a somewhat grey area about whether you can
re-license the code since we would not be the original copyright holders
and would likely shoot ourselves in the foot wrt making our SPIN
implementation usable in a corporate setting (where they are going to care
about legal stuff like this) if at all.

>
>However what we should definitely try to preserve are any unit tests
>and possibly some kind of test hareness. I hope the guys at TopBraid
>have SPIN thoroughly tested and we should reuse those tests on our
>implementation.

This is a good point, if they have open sourced the tests these would be
useful references to write our own tests from.

>
>>
>> -Follow your initial start at SPIN dotnetrdf and maybe use TopBraid
>>SPIN API
>> as a reference (Difficult because approaches will diverge).  Rob are
>>you a
>> take any small essential blocks and coordinate the overall effort?  Tom
>>are
>> you able to help out, especially where Fluent SPARQL is utilized?
>>Again I
>> think the alternate strategy above has a lot of merit, but it must align
>> with Rob's vision.   No matter the strategy please look at the
>> implementation questions below to help clarify the high/low level
>>picture.
>>
>
>Now, if we had not only the Java API reference but also complete
>automatic test suite from the start I would opt for the second
>approach.
>
>If not available or somehow unusable for a .NET project I think we
>could resort to http://spinservices.org/spinrdfconverter.html for
>validating our efforts.

I think the early tests I wrote did use this as well, I likely need to
drag those over from the old branch as well.

>
>Whatever the case I think that starting from scratch rather than
>porting Java is likely a better approach in the long run.

As I said above +1

>
>>
>>
>> Implementation Questions:
>>
>>
>>
>> -Can you provide a high level overview of a SPIN dotnetrdf
>>implementation so
>> I can ensure the final solution is acceptable.  Let's say you have the
>>SPIN
>> rule for "adult rdfs:subclassof person" at the top-level (ie.
>>owl:Thing) and
>> the user queries is Elvis a Adult.   Would dotnetrdf  SPIN spawn
>>numerous
>> intermediate SPARQL queries to gather the important SPIN rules that
>>must be
>> executed?  If RDF database is remote (ie. dbpedia) could this
>>accumulative
>> delay become unacceptably (Over 3 seconds in my application).
>>Alternatively
>> is everything required by the user query obtained in 1 or 2 complex
>> intermediate queries which dotnetrdf SPIN creates and digests?
>>Basically if
>> you could paint the high level overview with an example I could then
>>move to
>> the details.
>>
>>
>
>I think that a complete dotNetRDF implementation of SPIN would require
>at least two components.
>
>1. A converter from SPIN/RDF to in-memory queries (not necessarily
>VDS.RDF.Query.SparqlQuery - see below)
>2. A SPIN runner, which will take a SPIN query and execute it in an
>instance's context
>3. A reasoner, which uses the above converter and executes the SPIN
>rules and constraints againt a graph or triple store

Yes that is pretty much what I was going to suggest

>
>>
>>
>> -Can you provide a low-level overview of your SPIN dotnetrdf
>>implementation
>> strategy.  I only partially understood you explanation below, which I
>>know
>> will be a little clearer after looking at the code.  What is
>> spin-sparql-syntax.ttl and how does it fit into the puzzle?  What does
>>it
>> mean to convert a query into SPIN RDF representation?  My naive picture
>>is
>> that a user query is converted into internal query(s) to obtain SPIN RDF
>> rules, which are then executed by the new SPIN dotnetrdf engine.  Lastly
>> please explain a little more your view of turning a SPIN query into a
>>query?
>>
>>
>
>Basically I think that a complete solution should work like this:
>1. Prepare a metadata (ontology) graph with your SPIN rules/constraints
>2. SPIN rules are converted to SPARQL queries
>3. Queries are executed against graph/store to produce constraint
>violations and inferences/assertions

I agree, for point 3 we could even go so far to have a SPIN constraint
validator as a decorator over a dataset which would fire off the
constraints in the Flush() method (I.e. the transaction commit) and fail
the transaction if constraints have been violated.  The same goes for
running inferences.

>
>If you look at the TopBraid videos and SPIN Modelling vocabulary you
>will notice that there is much more to SPIN than just converting
>queries from RDF representation to SPARQL:
>- rule modularization templates
>- constructors
>- extending SPARQL Engine with functions and magic properties
>
>I agree with Rob that first we would need a converter from SPIN RDF to
>SPARQL but its design should be influenced by how we will use it and
>we already know very good what that would be. Unfortunately a lot
>seems unclear to me when I read the SPIN Modelling documentation. For
>one thing there can be many rules and as Kevin wrote, executing many
>such rules against a store may not be a good idea.

I think the immediate goal would be to make SPIN runnable against
in-memory data, a longer term goal can be to make this run against
arbitrary SPARQL endpoints.

Rob

>
>Kevin, what do you mean by you last question? You have RDF triples,
>which represent a query and you traverse the graph to create a query
>(string). The IGraph and Fluent SPARQL APIs combined should make this
>work easy.
>
>Hope this helps, for now ;)
>Tom
>
>>
>>
>> Thanks,
>>
>> Kevin
>>
>>
>>
>> From: Rob Vesse [mailto:rv...@do...]
>> Sent: Friday, March 15, 2013 2:57 PM
>> To: Kevin
>> Cc: dotNetRDF Developer Discussion and Feature Request
>> Subject: Re: Integrating SPIN into dotnetrdf
>>
>>
>>
>> Hey Kevin
>>
>>
>>
>> Discussion inline:
>>
>>
>>
>> From: Kevin <ke...@th...>
>> Date: Wednesday, March 13, 2013 7:40 PM
>> To: Rob Vesse <rv...@do...>
>> Subject: Integrating SPIN into dotnetrdf
>>
>>
>>
>> Rob,
>>
>>
>>
>> First thank you for your quality work you have done with the dotnetrdf
>> project.  I have seen a few different posts about your initiative to
>> integrate SPIN into dotnetrdf (ie.  SPIN Post).  After much reading on
>>the
>> subject it really seems that SPIN would really propel/complement
>>dotnetrdf.
>> I believe SPIN not only makes up for the missing OWL inference (Via SPIN
>> OWL-RL implementation), it also can expand to suit the modelers
>>imagination.
>> The fact that the rules are in SPARQL makes for an unbeatable solution.
>> Should it matter my current effort involves query a Virtuoso database
>>(Some
>> owl support) with dotnetrdf.  I would really appreciate you taking a
>>look at
>> the questions below:
>>
>>
>>
>> -Have you made any further progress on integrating SPIN into dotnetrdf?
>> Would you allow me to have the source code in its current state?  Could
>>I
>> possibly be a contributor on this cause as I am not really equipped for
>>the
>> full task?  In any case I would appreciate any source code which I
>>could use
>> as a learning tool.
>>
>>
>>
>> No I haven't had time to do anything on SPIN for a long time now.  I've
>>been
>> primarily concentrating on getting core features stabilized such as the
>> SPARQL engine which are obviously fairly key to building stuff like
>>SPIN on
>> top.
>>
>>
>>
>> However I still don't have time to work on SPIN directly so if you want
>>to
>> work on this please feel free, find the code in the mercurial
>>repository at
>> https://bitbucket.org/dotnetrdf/dotnetrdf
>>
>>
>>
>> The previous and very minimal SPIN stub is under Libraries\Query\Spin,
>> create your own fork and then you can send pull requests as and when you
>> have something to
>>
>>
>>
>> The key things that need to be done to get the core of SPIN implemented
>>are
>> as follows:
>>
>> Update the current spin-sparql-syntax.ttl to a current version, it
>>likely
>> doesn't represent the current version of the spec (this is primarily a
>> convenience reference for developers)
>> Finish the existing stubs for converting queries into their SPIN RDF
>> representation (see SpinSyntax.cs)
>> Write code to turn a RDF encoding of a SPIN query into a query
>>
>> The middle one would be the easiest to start with since there is already
>> some partial stubs to get you started.
>>
>>
>>
>>
>>
>> -From the available TopQuadrant documentation I have tried to deduce how
>> dotnetrdf might implement SPIN.  According to SPIN tutrial, TopBraid
>>finds
>> all SPIN inferecer rules and runs them when you hit play.  Would
>>dotnetrdf
>> SPIN inferencer only run the rules that are associated with the class
>> structure being queried?  Basically I am confused how dotnetrdf decides
>> when/how/which SPIN rules to run for a given query.
>>
>>
>>
>> That's an implementation detail, we would control how and when rules get
>> run.  We need to get the basic implementation of SPIN done first before
>>this
>> aspect of things gets implemented anyway.
>>
>>
>>
>>
>>
>> -How much of SPIN could dotnetrdf possibly support.? It appears SPIN
>> contains Inference Rules, Constraint Checking, and ability to Isolate
>>rules
>> for certain conditions.  Also the TopBraid tool seems to have
>>"User-Defined
>> SPARQL functions" and "SPIN Query Templates".  I imagine dotnetrdf would
>> have to keep up with any SPIN improvements.
>>
>>
>>
>> All of those are supportable in some shape of form, until we have the
>>core
>> of SPIN up and running we can't really implement those.  Most of those
>> features run on top of the SPIN core and so will ultimately just be
>> implementation details once we have a core to build upon.  User defined
>> SPARQL functions are basically just SPARQL queries that return a single
>> value and query templates are just parameterized queries both of which
>>the
>> existing SPARQL engine is capable of supporting in one way or another.
>>So
>> it is just a case of exposing that functionality in the SPIN style.
>>
>>
>>
>> Hope this is enough to get you started, if not please let us know,
>>
>>
>>
>> Rob
>>
>>
>>
>>
>>
>> Regards,
>>
>> Kevin
>>
>>
>> 
>>-------------------------------------------------------------------------
>>-----
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> dotNetRDF-develop mailing list
>> dot...@li...
>> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>>
>
>--------------------------------------------------------------------------
>----
>Everyone hates slow websites. So do we.
>Make your web apps faster with AppDynamics
>Download AppDynamics Lite for free today:
>http://p.sf.net/sfu/appdyn_d2d_mar
>_______________________________________________
>dotNetRDF-develop mailing list
>dot...@li...
>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop

Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf

[Kevin <ke...@th...>]

Rob/Tom,

Thank you for your engagement and valuable feedback.  I will defer to you
guys and develop SPIN dotNetRDF from scratch, using other implementations
only as a reference.  Preserving unit test sounds very smart and will keep
it in mind.

I will sign up for the SPIN dotNetRDF task, but it may not always proceed
quickly.  Since I plan to use SPIN dotNetRDF in my application it should
ensure I will see it to completion.  To achieve this goal can you guys
continue to answer questions and provide snippets of code?  My reading has
lead to numerous questions, which would be confusing to place in a single
email thread.  My plan is to organize the questions and start separate SPIN
integration emails.

Thanks,
Kevin

-----Original Message-----
From: Rob Vesse [mailto:rv...@do...] 
Sent: Friday, March 22, 2013 1:59 PM
To: dotNetRDF Developer Discussion and Feature Request
Subject: Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf

Sorry I've been out the discussion but this week is really busy for me.

Comments inline:

On 3/19/13 10:35 AM, "Tomasz Pluskiewicz" <tom...@gm...>
wrote:

>Comments inline
>
>On Sun, Mar 17, 2013 at 4:56 AM, Kevin <ke...@th...> wrote:
>> Rob, Tom
>>
>>
>>
>> After more reading I believe a dotnetrdf/SPIN/Fluent SPARQL would be 
>> an excellent solution.  In fact I would think people would convert to 
>> C# dotnetrdf due to this compiling story.
>>
>>
>>
>> Strategy Questions:
>>
>>
>>
>> Due to my knowledge, time constraints, and past experience I know if 
>>I  attempt SPIN dotnetrdf alone it will drag out and never complete.  
>>Can you  let me know if any of the strategies below make any sense.  
>>Both strategies  involve splitting the work with the understanding 
>>that we are all busy and  there is no real obligation.  Also I assume 
>>any knowledgeable new comer is  welcomed to contribute to the cause.  
>>I believe the effort will obviously  benefit the community, but also 
>>provide a deep insight to the contributing  developers.
>>
>>
>>
>> -Convert the Java TopBraid SPIN API (Uses Jena interface) into C# 
>>starting  with a conversion tool like Tangible Java->C# (I will 
>>purchase).  The tool  will help with most of the syntax, but there 
>>will be a lot of manual work.
>> The conversion will obviously entail replacing the Jena interface 
>>with  dotnetrdf.  The benefits of this strategy is we harness the 
>>completeness,  robustness, and future updates (re-port changes) of 
>>TopBraid SPIN API.
>>The
>> conversion should provide insights into the implementation enabling 
>>custom  tweaks.  It should also be possible to split the converted 
>>Java files into 3  groups if you guys are up for the task.  I am in 
>>preference of this solution  primarily because we are essential 
>>creating a SPIN inference engine based  upon code from the people who 
>>invented SPIN.
>>
>>
>
>Has TopBraid opened all of their SPIN API? Last time I looked only 
>parts were open source. I wonder that it got no attention at 
>semanticweb.com. Or did it?
>
>Regarding the first strategy I undersnatd it is very appealing but I'm 
>afraid converting API calls from Jena to dotNetRDF could be more work 
>than you expect. I don't know Jena very well but I expect that a lot of 
>the functionality isn't just a simple 1:1 relation. In this case we are 
>talking about a number of areas:
>
>- Graph traversal for reading SPIN queries in RDF form
>- SPARQL query and it's programmatic counterpart 
>(VDS.RDF.Query.SparqlQuery and others)
>- Query execution
>- Reasoner

I would echo what Tom said, write code from scratch don't try and port the
existing Java.  As someone who also works on Jena I can confirm what Tom
said that the APIs around queries and different enough that you would spend
far more time extricating Jena from the converted code than if you just
wrote the relevant code yourself.


Also converting code opened source under a different license than dotNetRDF
uses provides a somewhat grey area about whether you can re-license the code
since we would not be the original copyright holders and would likely shoot
ourselves in the foot wrt making our SPIN implementation usable in a
corporate setting (where they are going to care about legal stuff like this)
if at all.

>
>However what we should definitely try to preserve are any unit tests 
>and possibly some kind of test hareness. I hope the guys at TopBraid 
>have SPIN thoroughly tested and we should reuse those tests on our 
>implementation.

This is a good point, if they have open sourced the tests these would be
useful references to write our own tests from.

>
>>
>> -Follow your initial start at SPIN dotnetrdf and maybe use TopBraid 
>>SPIN API  as a reference (Difficult because approaches will diverge).  
>>Rob are you a  take any small essential blocks and coordinate the 
>>overall effort?  Tom are  you able to help out, especially where 
>>Fluent SPARQL is utilized?
>>Again I
>> think the alternate strategy above has a lot of merit, but it must align
>> with Rob's vision.   No matter the strategy please look at the
>> implementation questions below to help clarify the high/low level 
>>picture.
>>
>
>Now, if we had not only the Java API reference but also complete 
>automatic test suite from the start I would opt for the second 
>approach.
>
>If not available or somehow unusable for a .NET project I think we 
>could resort to http://spinservices.org/spinrdfconverter.html for 
>validating our efforts.

I think the early tests I wrote did use this as well, I likely need to drag
those over from the old branch as well.

>
>Whatever the case I think that starting from scratch rather than 
>porting Java is likely a better approach in the long run.

As I said above +1

>
>>
>>
>> Implementation Questions:
>>
>>
>>
>> -Can you provide a high level overview of a SPIN dotnetrdf 
>>implementation so  I can ensure the final solution is acceptable.  
>>Let's say you have the SPIN  rule for "adult rdfs:subclassof person" 
>>at the top-level (ie.
>>owl:Thing) and
>> the user queries is Elvis a Adult.   Would dotnetrdf  SPIN spawn
>>numerous
>> intermediate SPARQL queries to gather the important SPIN rules that 
>>must be  executed?  If RDF database is remote (ie. dbpedia) could this 
>>accumulative  delay become unacceptably (Over 3 seconds in my 
>>application).
>>Alternatively
>> is everything required by the user query obtained in 1 or 2 complex  
>>intermediate queries which dotnetrdf SPIN creates and digests?
>>Basically if
>> you could paint the high level overview with an example I could then 
>>move to  the details.
>>
>>
>
>I think that a complete dotNetRDF implementation of SPIN would require 
>at least two components.
>
>1. A converter from SPIN/RDF to in-memory queries (not necessarily 
>VDS.RDF.Query.SparqlQuery - see below) 2. A SPIN runner, which will 
>take a SPIN query and execute it in an instance's context 3. A 
>reasoner, which uses the above converter and executes the SPIN rules 
>and constraints againt a graph or triple store

Yes that is pretty much what I was going to suggest

>
>>
>>
>> -Can you provide a low-level overview of your SPIN dotnetrdf 
>>implementation  strategy.  I only partially understood you explanation 
>>below, which I know  will be a little clearer after looking at the 
>>code.  What is  spin-sparql-syntax.ttl and how does it fit into the 
>>puzzle?  What does it  mean to convert a query into SPIN RDF 
>>representation?  My naive picture is  that a user query is converted 
>>into internal query(s) to obtain SPIN RDF  rules, which are then 
>>executed by the new SPIN dotnetrdf engine.  Lastly  please explain a 
>>little more your view of turning a SPIN query into a query?
>>
>>
>
>Basically I think that a complete solution should work like this:
>1. Prepare a metadata (ontology) graph with your SPIN rules/constraints 
>2. SPIN rules are converted to SPARQL queries 3. Queries are executed 
>against graph/store to produce constraint violations and 
>inferences/assertions

I agree, for point 3 we could even go so far to have a SPIN constraint
validator as a decorator over a dataset which would fire off the constraints
in the Flush() method (I.e. the transaction commit) and fail the transaction
if constraints have been violated.  The same goes for running inferences.

>
>If you look at the TopBraid videos and SPIN Modelling vocabulary you 
>will notice that there is much more to SPIN than just converting 
>queries from RDF representation to SPARQL:
>- rule modularization templates
>- constructors
>- extending SPARQL Engine with functions and magic properties
>
>I agree with Rob that first we would need a converter from SPIN RDF to 
>SPARQL but its design should be influenced by how we will use it and we 
>already know very good what that would be. Unfortunately a lot seems 
>unclear to me when I read the SPIN Modelling documentation. For one 
>thing there can be many rules and as Kevin wrote, executing many such 
>rules against a store may not be a good idea.

I think the immediate goal would be to make SPIN runnable against in-memory
data, a longer term goal can be to make this run against arbitrary SPARQL
endpoints.

Rob

>
>Kevin, what do you mean by you last question? You have RDF triples, 
>which represent a query and you traverse the graph to create a query 
>(string). The IGraph and Fluent SPARQL APIs combined should make this 
>work easy.
>
>Hope this helps, for now ;)
>Tom
>
>>
>>
>> Thanks,
>>
>> Kevin
>>
>>
>>
>> From: Rob Vesse [mailto:rv...@do...]
>> Sent: Friday, March 15, 2013 2:57 PM
>> To: Kevin
>> Cc: dotNetRDF Developer Discussion and Feature Request
>> Subject: Re: Integrating SPIN into dotnetrdf
>>
>>
>>
>> Hey Kevin
>>
>>
>>
>> Discussion inline:
>>
>>
>>
>> From: Kevin <ke...@th...>
>> Date: Wednesday, March 13, 2013 7:40 PM
>> To: Rob Vesse <rv...@do...>
>> Subject: Integrating SPIN into dotnetrdf
>>
>>
>>
>> Rob,
>>
>>
>>
>> First thank you for your quality work you have done with the 
>>dotnetrdf  project.  I have seen a few different posts about your 
>>initiative to  integrate SPIN into dotnetrdf (ie.  SPIN Post).  After 
>>much reading on the  subject it really seems that SPIN would really 
>>propel/complement dotnetrdf.
>> I believe SPIN not only makes up for the missing OWL inference (Via 
>>SPIN  OWL-RL implementation), it also can expand to suit the modelers 
>>imagination.
>> The fact that the rules are in SPARQL makes for an unbeatable solution.
>> Should it matter my current effort involves query a Virtuoso database 
>>(Some  owl support) with dotnetrdf.  I would really appreciate you 
>>taking a look at  the questions below:
>>
>>
>>
>> -Have you made any further progress on integrating SPIN into dotnetrdf?
>> Would you allow me to have the source code in its current state?  
>>Could I  possibly be a contributor on this cause as I am not really 
>>equipped for the  full task?  In any case I would appreciate any 
>>source code which I could use  as a learning tool.
>>
>>
>>
>> No I haven't had time to do anything on SPIN for a long time now.  I've
>>been
>> primarily concentrating on getting core features stabilized such as the
>> SPARQL engine which are obviously fairly key to building stuff like
>>SPIN on
>> top.
>>
>>
>>
>> However I still don't have time to work on SPIN directly so if you want
>>to
>> work on this please feel free, find the code in the mercurial
>>repository at
>> https://bitbucket.org/dotnetrdf/dotnetrdf
>>
>>
>>
>> The previous and very minimal SPIN stub is under Libraries\Query\Spin,
>> create your own fork and then you can send pull requests as and when you
>> have something to
>>
>>
>>
>> The key things that need to be done to get the core of SPIN implemented
>>are
>> as follows:
>>
>> Update the current spin-sparql-syntax.ttl to a current version, it
>>likely
>> doesn't represent the current version of the spec (this is primarily a
>> convenience reference for developers)
>> Finish the existing stubs for converting queries into their SPIN RDF
>> representation (see SpinSyntax.cs)
>> Write code to turn a RDF encoding of a SPIN query into a query
>>
>> The middle one would be the easiest to start with since there is already
>> some partial stubs to get you started.
>>
>>
>>
>>
>>
>> -From the available TopQuadrant documentation I have tried to deduce how
>> dotnetrdf might implement SPIN.  According to SPIN tutrial, TopBraid
>>finds
>> all SPIN inferecer rules and runs them when you hit play.  Would
>>dotnetrdf
>> SPIN inferencer only run the rules that are associated with the class
>> structure being queried?  Basically I am confused how dotnetrdf decides
>> when/how/which SPIN rules to run for a given query.
>>
>>
>>
>> That's an implementation detail, we would control how and when rules get
>> run.  We need to get the basic implementation of SPIN done first before
>>this
>> aspect of things gets implemented anyway.
>>
>>
>>
>>
>>
>> -How much of SPIN could dotnetrdf possibly support.? It appears SPIN
>> contains Inference Rules, Constraint Checking, and ability to Isolate
>>rules
>> for certain conditions.  Also the TopBraid tool seems to have
>>"User-Defined
>> SPARQL functions" and "SPIN Query Templates".  I imagine dotnetrdf would
>> have to keep up with any SPIN improvements.
>>
>>
>>
>> All of those are supportable in some shape of form, until we have the
>>core
>> of SPIN up and running we can't really implement those.  Most of those
>> features run on top of the SPIN core and so will ultimately just be
>> implementation details once we have a core to build upon.  User defined
>> SPARQL functions are basically just SPARQL queries that return a single
>> value and query templates are just parameterized queries both of which
>>the
>> existing SPARQL engine is capable of supporting in one way or another.
>>So
>> it is just a case of exposing that functionality in the SPIN style.
>>
>>
>>
>> Hope this is enough to get you started, if not please let us know,
>>
>>
>>
>> Rob
>>
>>
>>
>>
>>
>> Regards,
>>
>> Kevin
>>
>>
>> 
>>-------------------------------------------------------------------------
>>-----
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> dotNetRDF-develop mailing list
>> dot...@li...
>> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>>
>
>--------------------------------------------------------------------------
>----
>Everyone hates slow websites. So do we.
>Make your web apps faster with AppDynamics
>Download AppDynamics Lite for free today:
>http://p.sf.net/sfu/appdyn_d2d_mar
>_______________________________________________
>dotNetRDF-develop mailing list
>dot...@li...
>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop





----------------------------------------------------------------------------
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
dotNetRDF-develop mailing list
dot...@li...
https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop

Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf

[Rob V. <rv...@do...>]

Hey Kevin

Ok that is great, of course we can continue to answer questions and offer
help/advice as needed.

I would suggest that you create a fork of our repository on Bitbucket
(https://bitbucket.org/dotnetrdf/dotnetrdf) so that as you start to get
code written you can open pull requests to merge in chunks of
functionality as you get things working.  Pull requests also provide us a
chance to do a quick review of the code and flag up any obvious issues.

Thanks and good luck, I look forward to working with you,

Rob

On 3/27/13 4:46 AM, "Kevin" <ke...@th...> wrote:

>Rob/Tom,
>
>Thank you for your engagement and valuable feedback.  I will defer to you
>guys and develop SPIN dotNetRDF from scratch, using other implementations
>only as a reference.  Preserving unit test sounds very smart and will keep
>it in mind.
>
>I will sign up for the SPIN dotNetRDF task, but it may not always proceed
>quickly.  Since I plan to use SPIN dotNetRDF in my application it should
>ensure I will see it to completion.  To achieve this goal can you guys
>continue to answer questions and provide snippets of code?  My reading has
>lead to numerous questions, which would be confusing to place in a single
>email thread.  My plan is to organize the questions and start separate
>SPIN
>integration emails.
>
>Thanks,
>Kevin
>
>-----Original Message-----
>From: Rob Vesse [mailto:rv...@do...]
>Sent: Friday, March 22, 2013 1:59 PM
>To: dotNetRDF Developer Discussion and Feature Request
>Subject: Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf
>
>Sorry I've been out the discussion but this week is really busy for me.
>
>Comments inline:
>
>On 3/19/13 10:35 AM, "Tomasz Pluskiewicz" <tom...@gm...>
>wrote:
>
>>Comments inline
>>
>>On Sun, Mar 17, 2013 at 4:56 AM, Kevin <ke...@th...> wrote:
>>> Rob, Tom
>>>
>>>
>>>
>>> After more reading I believe a dotnetrdf/SPIN/Fluent SPARQL would be
>>> an excellent solution.  In fact I would think people would convert to
>>> C# dotnetrdf due to this compiling story.
>>>
>>>
>>>
>>> Strategy Questions:
>>>
>>>
>>>
>>> Due to my knowledge, time constraints, and past experience I know if
>>>I  attempt SPIN dotnetrdf alone it will drag out and never complete.
>>>Can you  let me know if any of the strategies below make any sense.
>>>Both strategies  involve splitting the work with the understanding
>>>that we are all busy and  there is no real obligation.  Also I assume
>>>any knowledgeable new comer is  welcomed to contribute to the cause.
>>>I believe the effort will obviously  benefit the community, but also
>>>provide a deep insight to the contributing  developers.
>>>
>>>
>>>
>>> -Convert the Java TopBraid SPIN API (Uses Jena interface) into C#
>>>starting  with a conversion tool like Tangible Java->C# (I will
>>>purchase).  The tool  will help with most of the syntax, but there
>>>will be a lot of manual work.
>>> The conversion will obviously entail replacing the Jena interface
>>>with  dotnetrdf.  The benefits of this strategy is we harness the
>>>completeness,  robustness, and future updates (re-port changes) of
>>>TopBraid SPIN API.
>>>The
>>> conversion should provide insights into the implementation enabling
>>>custom  tweaks.  It should also be possible to split the converted
>>>Java files into 3  groups if you guys are up for the task.  I am in
>>>preference of this solution  primarily because we are essential
>>>creating a SPIN inference engine based  upon code from the people who
>>>invented SPIN.
>>>
>>>
>>
>>Has TopBraid opened all of their SPIN API? Last time I looked only
>>parts were open source. I wonder that it got no attention at
>>semanticweb.com. Or did it?
>>
>>Regarding the first strategy I undersnatd it is very appealing but I'm
>>afraid converting API calls from Jena to dotNetRDF could be more work
>>than you expect. I don't know Jena very well but I expect that a lot of
>>the functionality isn't just a simple 1:1 relation. In this case we are
>>talking about a number of areas:
>>
>>- Graph traversal for reading SPIN queries in RDF form
>>- SPARQL query and it's programmatic counterpart
>>(VDS.RDF.Query.SparqlQuery and others)
>>- Query execution
>>- Reasoner
>
>I would echo what Tom said, write code from scratch don't try and port the
>existing Java.  As someone who also works on Jena I can confirm what Tom
>said that the APIs around queries and different enough that you would
>spend
>far more time extricating Jena from the converted code than if you just
>wrote the relevant code yourself.
>
>
>Also converting code opened source under a different license than
>dotNetRDF
>uses provides a somewhat grey area about whether you can re-license the
>code
>since we would not be the original copyright holders and would likely
>shoot
>ourselves in the foot wrt making our SPIN implementation usable in a
>corporate setting (where they are going to care about legal stuff like
>this)
>if at all.
>
>>
>>However what we should definitely try to preserve are any unit tests
>>and possibly some kind of test hareness. I hope the guys at TopBraid
>>have SPIN thoroughly tested and we should reuse those tests on our
>>implementation.
>
>This is a good point, if they have open sourced the tests these would be
>useful references to write our own tests from.
>
>>
>>>
>>> -Follow your initial start at SPIN dotnetrdf and maybe use TopBraid
>>>SPIN API  as a reference (Difficult because approaches will diverge).
>>>Rob are you a  take any small essential blocks and coordinate the
>>>overall effort?  Tom are  you able to help out, especially where
>>>Fluent SPARQL is utilized?
>>>Again I
>>> think the alternate strategy above has a lot of merit, but it must
>>>align
>>> with Rob's vision.   No matter the strategy please look at the
>>> implementation questions below to help clarify the high/low level
>>>picture.
>>>
>>
>>Now, if we had not only the Java API reference but also complete
>>automatic test suite from the start I would opt for the second
>>approach.
>>
>>If not available or somehow unusable for a .NET project I think we
>>could resort to http://spinservices.org/spinrdfconverter.html for
>>validating our efforts.
>
>I think the early tests I wrote did use this as well, I likely need to
>drag
>those over from the old branch as well.
>
>>
>>Whatever the case I think that starting from scratch rather than
>>porting Java is likely a better approach in the long run.
>
>As I said above +1
>
>>
>>>
>>>
>>> Implementation Questions:
>>>
>>>
>>>
>>> -Can you provide a high level overview of a SPIN dotnetrdf
>>>implementation so  I can ensure the final solution is acceptable.
>>>Let's say you have the SPIN  rule for "adult rdfs:subclassof person"
>>>at the top-level (ie.
>>>owl:Thing) and
>>> the user queries is Elvis a Adult.   Would dotnetrdf  SPIN spawn
>>>numerous
>>> intermediate SPARQL queries to gather the important SPIN rules that
>>>must be  executed?  If RDF database is remote (ie. dbpedia) could this
>>>accumulative  delay become unacceptably (Over 3 seconds in my
>>>application).
>>>Alternatively
>>> is everything required by the user query obtained in 1 or 2 complex
>>>intermediate queries which dotnetrdf SPIN creates and digests?
>>>Basically if
>>> you could paint the high level overview with an example I could then
>>>move to  the details.
>>>
>>>
>>
>>I think that a complete dotNetRDF implementation of SPIN would require
>>at least two components.
>>
>>1. A converter from SPIN/RDF to in-memory queries (not necessarily
>>VDS.RDF.Query.SparqlQuery - see below) 2. A SPIN runner, which will
>>take a SPIN query and execute it in an instance's context 3. A
>>reasoner, which uses the above converter and executes the SPIN rules
>>and constraints againt a graph or triple store
>
>Yes that is pretty much what I was going to suggest
>
>>
>>>
>>>
>>> -Can you provide a low-level overview of your SPIN dotnetrdf
>>>implementation  strategy.  I only partially understood you explanation
>>>below, which I know  will be a little clearer after looking at the
>>>code.  What is  spin-sparql-syntax.ttl and how does it fit into the
>>>puzzle?  What does it  mean to convert a query into SPIN RDF
>>>representation?  My naive picture is  that a user query is converted
>>>into internal query(s) to obtain SPIN RDF  rules, which are then
>>>executed by the new SPIN dotnetrdf engine.  Lastly  please explain a
>>>little more your view of turning a SPIN query into a query?
>>>
>>>
>>
>>Basically I think that a complete solution should work like this:
>>1. Prepare a metadata (ontology) graph with your SPIN rules/constraints
>>2. SPIN rules are converted to SPARQL queries 3. Queries are executed
>>against graph/store to produce constraint violations and
>>inferences/assertions
>
>I agree, for point 3 we could even go so far to have a SPIN constraint
>validator as a decorator over a dataset which would fire off the
>constraints
>in the Flush() method (I.e. the transaction commit) and fail the
>transaction
>if constraints have been violated.  The same goes for running inferences.
>
>>
>>If you look at the TopBraid videos and SPIN Modelling vocabulary you
>>will notice that there is much more to SPIN than just converting
>>queries from RDF representation to SPARQL:
>>- rule modularization templates
>>- constructors
>>- extending SPARQL Engine with functions and magic properties
>>
>>I agree with Rob that first we would need a converter from SPIN RDF to
>>SPARQL but its design should be influenced by how we will use it and we
>>already know very good what that would be. Unfortunately a lot seems
>>unclear to me when I read the SPIN Modelling documentation. For one
>>thing there can be many rules and as Kevin wrote, executing many such
>>rules against a store may not be a good idea.
>
>I think the immediate goal would be to make SPIN runnable against
>in-memory
>data, a longer term goal can be to make this run against arbitrary SPARQL
>endpoints.
>
>Rob
>
>>
>>Kevin, what do you mean by you last question? You have RDF triples,
>>which represent a query and you traverse the graph to create a query
>>(string). The IGraph and Fluent SPARQL APIs combined should make this
>>work easy.
>>
>>Hope this helps, for now ;)
>>Tom
>>
>>>
>>>
>>> Thanks,
>>>
>>> Kevin
>>>
>>>
>>>
>>> From: Rob Vesse [mailto:rv...@do...]
>>> Sent: Friday, March 15, 2013 2:57 PM
>>> To: Kevin
>>> Cc: dotNetRDF Developer Discussion and Feature Request
>>> Subject: Re: Integrating SPIN into dotnetrdf
>>>
>>>
>>>
>>> Hey Kevin
>>>
>>>
>>>
>>> Discussion inline:
>>>
>>>
>>>
>>> From: Kevin <ke...@th...>
>>> Date: Wednesday, March 13, 2013 7:40 PM
>>> To: Rob Vesse <rv...@do...>
>>> Subject: Integrating SPIN into dotnetrdf
>>>
>>>
>>>
>>> Rob,
>>>
>>>
>>>
>>> First thank you for your quality work you have done with the
>>>dotnetrdf  project.  I have seen a few different posts about your
>>>initiative to  integrate SPIN into dotnetrdf (ie.  SPIN Post).  After
>>>much reading on the  subject it really seems that SPIN would really
>>>propel/complement dotnetrdf.
>>> I believe SPIN not only makes up for the missing OWL inference (Via
>>>SPIN  OWL-RL implementation), it also can expand to suit the modelers
>>>imagination.
>>> The fact that the rules are in SPARQL makes for an unbeatable solution.
>>> Should it matter my current effort involves query a Virtuoso database
>>>(Some  owl support) with dotnetrdf.  I would really appreciate you
>>>taking a look at  the questions below:
>>>
>>>
>>>
>>> -Have you made any further progress on integrating SPIN into dotnetrdf?
>>> Would you allow me to have the source code in its current state?
>>>Could I  possibly be a contributor on this cause as I am not really
>>>equipped for the  full task?  In any case I would appreciate any
>>>source code which I could use  as a learning tool.
>>>
>>>
>>>
>>> No I haven't had time to do anything on SPIN for a long time now.  I've
>>>been
>>> primarily concentrating on getting core features stabilized such as the
>>> SPARQL engine which are obviously fairly key to building stuff like
>>>SPIN on
>>> top.
>>>
>>>
>>>
>>> However I still don't have time to work on SPIN directly so if you want
>>>to
>>> work on this please feel free, find the code in the mercurial
>>>repository at
>>> https://bitbucket.org/dotnetrdf/dotnetrdf
>>>
>>>
>>>
>>> The previous and very minimal SPIN stub is under Libraries\Query\Spin,
>>> create your own fork and then you can send pull requests as and when
>>>you
>>> have something to
>>>
>>>
>>>
>>> The key things that need to be done to get the core of SPIN implemented
>>>are
>>> as follows:
>>>
>>> Update the current spin-sparql-syntax.ttl to a current version, it
>>>likely
>>> doesn't represent the current version of the spec (this is primarily a
>>> convenience reference for developers)
>>> Finish the existing stubs for converting queries into their SPIN RDF
>>> representation (see SpinSyntax.cs)
>>> Write code to turn a RDF encoding of a SPIN query into a query
>>>
>>> The middle one would be the easiest to start with since there is
>>>already
>>> some partial stubs to get you started.
>>>
>>>
>>>
>>>
>>>
>>> -From the available TopQuadrant documentation I have tried to deduce
>>>how
>>> dotnetrdf might implement SPIN.  According to SPIN tutrial, TopBraid
>>>finds
>>> all SPIN inferecer rules and runs them when you hit play.  Would
>>>dotnetrdf
>>> SPIN inferencer only run the rules that are associated with the class
>>> structure being queried?  Basically I am confused how dotnetrdf decides
>>> when/how/which SPIN rules to run for a given query.
>>>
>>>
>>>
>>> That's an implementation detail, we would control how and when rules
>>>get
>>> run.  We need to get the basic implementation of SPIN done first before
>>>this
>>> aspect of things gets implemented anyway.
>>>
>>>
>>>
>>>
>>>
>>> -How much of SPIN could dotnetrdf possibly support.? It appears SPIN
>>> contains Inference Rules, Constraint Checking, and ability to Isolate
>>>rules
>>> for certain conditions.  Also the TopBraid tool seems to have
>>>"User-Defined
>>> SPARQL functions" and "SPIN Query Templates".  I imagine dotnetrdf
>>>would
>>> have to keep up with any SPIN improvements.
>>>
>>>
>>>
>>> All of those are supportable in some shape of form, until we have the
>>>core
>>> of SPIN up and running we can't really implement those.  Most of those
>>> features run on top of the SPIN core and so will ultimately just be
>>> implementation details once we have a core to build upon.  User defined
>>> SPARQL functions are basically just SPARQL queries that return a single
>>> value and query templates are just parameterized queries both of which
>>>the
>>> existing SPARQL engine is capable of supporting in one way or another.
>>>So
>>> it is just a case of exposing that functionality in the SPIN style.
>>>
>>>
>>>
>>> Hope this is enough to get you started, if not please let us know,
>>>
>>>
>>>
>>> Rob
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>> Kevin
>>>
>>>
>>> 
>>>------------------------------------------------------------------------
>>>-
>>>-----
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>> _______________________________________________
>>> dotNetRDF-develop mailing list
>>> dot...@li...
>>> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>>>
>>
>>-------------------------------------------------------------------------
>>-
>>----
>>Everyone hates slow websites. So do we.
>>Make your web apps faster with AppDynamics
>>Download AppDynamics Lite for free today:
>>http://p.sf.net/sfu/appdyn_d2d_mar
>>_______________________________________________
>>dotNetRDF-develop mailing list
>>dot...@li...
>>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>
>
>
>
>
>--------------------------------------------------------------------------
>--
>--
>Everyone hates slow websites. So do we.
>Make your web apps faster with AppDynamics
>Download AppDynamics Lite for free today:
>http://p.sf.net/sfu/appdyn_d2d_mar
>_______________________________________________
>dotNetRDF-develop mailing list
>dot...@li...
>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>
>
>--------------------------------------------------------------------------
>----
>Own the Future-Intel&reg; Level Up Game Demo Contest 2013
>Rise to greatness in Intel's independent game demo contest.
>Compete for recognition, cash, and the chance to get your game
>on Steam. $5K grand prize plus 10 genre and skill prizes.
>Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
>_______________________________________________
>dotNetRDF-develop mailing list
>dot...@li...
>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop

Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf

[Tomasz P. <tom...@gm...>]

Hi Kevin, Rob

I have been thinking about SPIN for a very long time. And I have
actually very recently read somehere on answeres.semanticweb.com about
using SPIN to implement OWL reasoning.

Ever since I had started that fluent SPARQL I thought it could
actually be a good base to easily go from SPIN RDF representation to
actual queries.

I know that the implementation is far from complete. I have been busy
with a multitude of other tasks but if it could prove useful in
implementing SPIN it would be great. Actually one of my goals I did
have in mind was to use Fluent SPARQL for SPIN. Especially that
working with query strings or low-level SPARQL API will be far from
developer-friendly in te long run IMO.

Kevin, please have a look at my fork, where I have been documenting my
work on a wiki: http://bitbucket.org/romanticweb/dotnetrdf/wiki/Home

What do you guys think?

Thank,
Tom

On Fri, Mar 15, 2013 at 8:57 PM, Rob Vesse <rv...@do...> wrote:
> Hey Kevin
>
> Discussion inline:
>
> From: Kevin <ke...@th...>
> Date: Wednesday, March 13, 2013 7:40 PM
> To: Rob Vesse <rv...@do...>
> Subject: Integrating SPIN into dotnetrdf
>
> Rob,
>
>
>
> First thank you for your quality work you have done with the dotnetrdf
> project.  I have seen a few different posts about your initiative to
> integrate SPIN into dotnetrdf (ie.  SPIN Post).  After much reading on the
> subject it really seems that SPIN would really propel/complement dotnetrdf.
> I believe SPIN not only makes up for the missing OWL inference (Via SPIN
> OWL-RL implementation), it also can expand to suit the modelers imagination.
> The fact that the rules are in SPARQL makes for an unbeatable solution.
> Should it matter my current effort involves query a Virtuoso database (Some
> owl support) with dotnetrdf.  I would really appreciate you taking a look at
> the questions below:
>
>
>
> -Have you made any further progress on integrating SPIN into dotnetrdf?
> Would you allow me to have the source code in its current state?  Could I
> possibly be a contributor on this cause as I am not really equipped for the
> full task?  In any case I would appreciate any source code which I could use
> as a learning tool.
>
>
> No I haven't had time to do anything on SPIN for a long time now.  I've been
> primarily concentrating on getting core features stabilized such as the
> SPARQL engine which are obviously fairly key to building stuff like SPIN on
> top.
>
> However I still don't have time to work on SPIN directly so if you want to
> work on this please feel free, find the code in the mercurial repository at
> https://bitbucket.org/dotnetrdf/dotnetrdf
>
> The previous and very minimal SPIN stub is under Libraries\Query\Spin,
> create your own fork and then you can send pull requests as and when you
> have something to
>
> The key things that need to be done to get the core of SPIN implemented are
> as follows:
>
> Update the current spin-sparql-syntax.ttl to a current version, it likely
> doesn't represent the current version of the spec (this is primarily a
> convenience reference for developers)
> Finish the existing stubs for converting queries into their SPIN RDF
> representation (see SpinSyntax.cs)
> Write code to turn a RDF encoding of a SPIN query into a query
>
> The middle one would be the easiest to start with since there is already
> some partial stubs to get you started.
>
>
>
> -From the available TopQuadrant documentation I have tried to deduce how
> dotnetrdf might implement SPIN.  According to SPIN tutrial, TopBraid finds
> all SPIN inferecer rules and runs them when you hit play.  Would dotnetrdf
> SPIN inferencer only run the rules that are associated with the class
> structure being queried?  Basically I am confused how dotnetrdf decides
> when/how/which SPIN rules to run for a given query.
>
>
> That's an implementation detail, we would control how and when rules get
> run.  We need to get the basic implementation of SPIN done first before this
> aspect of things gets implemented anyway.
>
>
>
> -How much of SPIN could dotnetrdf possibly support.? It appears SPIN
> contains Inference Rules, Constraint Checking, and ability to Isolate rules
> for certain conditions.  Also the TopBraid tool seems to have  "User-Defined
> SPARQL functions" and "SPIN Query Templates".  I imagine dotnetrdf would
> have to keep up with any SPIN improvements.
>
>
> All of those are supportable in some shape of form, until we have the core
> of SPIN up and running we can't really implement those.  Most of those
> features run on top of the SPIN core and so will ultimately just be
> implementation details once we have a core to build upon.  User defined
> SPARQL functions are basically just SPARQL queries that return a single
> value and query templates are just parameterized queries both of which the
> existing SPARQL engine is capable of supporting in one way or another.  So
> it is just a case of exposing that functionality in the SPIN style.
>
> Hope this is enough to get you started, if not please let us know,
>
> Rob
>
>
>
> Regards,
>
> Kevin
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> dotNetRDF-develop mailing list
> dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>

Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf

[Rob V. <rv...@do...>]

Hey

Yes I think using the Fluent Query API for helping to convert the RDF
representation back into queries would likely make life much easier.

Rob

On 3/15/13 1:19 PM, "Tomasz Pluskiewicz" <tom...@gm...>
wrote:

>Hi Kevin, Rob
>
>I have been thinking about SPIN for a very long time. And I have
>actually very recently read somehere on answeres.semanticweb.com about
>using SPIN to implement OWL reasoning.
>
>Ever since I had started that fluent SPARQL I thought it could
>actually be a good base to easily go from SPIN RDF representation to
>actual queries.
>
>I know that the implementation is far from complete. I have been busy
>with a multitude of other tasks but if it could prove useful in
>implementing SPIN it would be great. Actually one of my goals I did
>have in mind was to use Fluent SPARQL for SPIN. Especially that
>working with query strings or low-level SPARQL API will be far from
>developer-friendly in te long run IMO.
>
>Kevin, please have a look at my fork, where I have been documenting my
>work on a wiki: http://bitbucket.org/romanticweb/dotnetrdf/wiki/Home
>
>What do you guys think?
>
>Thank,
>Tom
>
>On Fri, Mar 15, 2013 at 8:57 PM, Rob Vesse <rv...@do...> wrote:
>> Hey Kevin
>>
>> Discussion inline:
>>
>> From: Kevin <ke...@th...>
>> Date: Wednesday, March 13, 2013 7:40 PM
>> To: Rob Vesse <rv...@do...>
>> Subject: Integrating SPIN into dotnetrdf
>>
>> Rob,
>>
>>
>>
>> First thank you for your quality work you have done with the dotnetrdf
>> project.  I have seen a few different posts about your initiative to
>> integrate SPIN into dotnetrdf (ie.  SPIN Post).  After much reading on
>>the
>> subject it really seems that SPIN would really propel/complement
>>dotnetrdf.
>> I believe SPIN not only makes up for the missing OWL inference (Via SPIN
>> OWL-RL implementation), it also can expand to suit the modelers
>>imagination.
>> The fact that the rules are in SPARQL makes for an unbeatable solution.
>> Should it matter my current effort involves query a Virtuoso database
>>(Some
>> owl support) with dotnetrdf.  I would really appreciate you taking a
>>look at
>> the questions below:
>>
>>
>>
>> -Have you made any further progress on integrating SPIN into dotnetrdf?
>> Would you allow me to have the source code in its current state?  Could
>>I
>> possibly be a contributor on this cause as I am not really equipped for
>>the
>> full task?  In any case I would appreciate any source code which I
>>could use
>> as a learning tool.
>>
>>
>> No I haven't had time to do anything on SPIN for a long time now.  I've
>>been
>> primarily concentrating on getting core features stabilized such as the
>> SPARQL engine which are obviously fairly key to building stuff like
>>SPIN on
>> top.
>>
>> However I still don't have time to work on SPIN directly so if you want
>>to
>> work on this please feel free, find the code in the mercurial
>>repository at
>> https://bitbucket.org/dotnetrdf/dotnetrdf
>>
>> The previous and very minimal SPIN stub is under Libraries\Query\Spin,
>> create your own fork and then you can send pull requests as and when you
>> have something to
>>
>> The key things that need to be done to get the core of SPIN implemented
>>are
>> as follows:
>>
>> Update the current spin-sparql-syntax.ttl to a current version, it
>>likely
>> doesn't represent the current version of the spec (this is primarily a
>> convenience reference for developers)
>> Finish the existing stubs for converting queries into their SPIN RDF
>> representation (see SpinSyntax.cs)
>> Write code to turn a RDF encoding of a SPIN query into a query
>>
>> The middle one would be the easiest to start with since there is already
>> some partial stubs to get you started.
>>
>>
>>
>> -From the available TopQuadrant documentation I have tried to deduce how
>> dotnetrdf might implement SPIN.  According to SPIN tutrial, TopBraid
>>finds
>> all SPIN inferecer rules and runs them when you hit play.  Would
>>dotnetrdf
>> SPIN inferencer only run the rules that are associated with the class
>> structure being queried?  Basically I am confused how dotnetrdf decides
>> when/how/which SPIN rules to run for a given query.
>>
>>
>> That's an implementation detail, we would control how and when rules get
>> run.  We need to get the basic implementation of SPIN done first before
>>this
>> aspect of things gets implemented anyway.
>>
>>
>>
>> -How much of SPIN could dotnetrdf possibly support.? It appears SPIN
>> contains Inference Rules, Constraint Checking, and ability to Isolate
>>rules
>> for certain conditions.  Also the TopBraid tool seems to have
>>"User-Defined
>> SPARQL functions" and "SPIN Query Templates".  I imagine dotnetrdf would
>> have to keep up with any SPIN improvements.
>>
>>
>> All of those are supportable in some shape of form, until we have the
>>core
>> of SPIN up and running we can't really implement those.  Most of those
>> features run on top of the SPIN core and so will ultimately just be
>> implementation details once we have a core to build upon.  User defined
>> SPARQL functions are basically just SPARQL queries that return a single
>> value and query templates are just parameterized queries both of which
>>the
>> existing SPARQL engine is capable of supporting in one way or another.
>>So
>> it is just a case of exposing that functionality in the SPIN style.
>>
>> Hope this is enough to get you started, if not please let us know,
>>
>> Rob
>>
>>
>>
>> Regards,
>>
>> Kevin
>>
>>
>> 
>>-------------------------------------------------------------------------
>>-----
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> dotNetRDF-develop mailing list
>> dot...@li...
>> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>>
>
>--------------------------------------------------------------------------
>----
>Everyone hates slow websites. So do we.
>Make your web apps faster with AppDynamics
>Download AppDynamics Lite for free today:
>http://p.sf.net/sfu/appdyn_d2d_mar
>_______________________________________________
>dotNetRDF-develop mailing list
>dot...@li...
>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop

Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf

[Kevin <ke...@th...>]

Tom,

I read your Fluent SPQRQL link and the proposal seemed helpful, elegant, and
LINQish.  I am curious do other SPARQL engines (ie. Java Based) have the
APIs akin to Fluent SPARAL?  Exactly how far is the Fluent SPARQL
development and do you have a target date?

Thanks,
Kevin

-----Original Message-----
From: Rob Vesse [mailto:rv...@do...] 
Sent: Friday, March 15, 2013 3:45 PM
To: dotNetRDF Developer Discussion and Feature Request
Cc: Kevin
Subject: Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf

Hey

Yes I think using the Fluent Query API for helping to convert the RDF
representation back into queries would likely make life much easier.

Rob

On 3/15/13 1:19 PM, "Tomasz Pluskiewicz" <tom...@gm...>
wrote:

>Hi Kevin, Rob
>
>I have been thinking about SPIN for a very long time. And I have 
>actually very recently read somehere on answeres.semanticweb.com about 
>using SPIN to implement OWL reasoning.
>
>Ever since I had started that fluent SPARQL I thought it could actually 
>be a good base to easily go from SPIN RDF representation to actual 
>queries.
>
>I know that the implementation is far from complete. I have been busy 
>with a multitude of other tasks but if it could prove useful in 
>implementing SPIN it would be great. Actually one of my goals I did 
>have in mind was to use Fluent SPARQL for SPIN. Especially that working 
>with query strings or low-level SPARQL API will be far from 
>developer-friendly in te long run IMO.
>
>Kevin, please have a look at my fork, where I have been documenting my 
>work on a wiki: http://bitbucket.org/romanticweb/dotnetrdf/wiki/Home
>
>What do you guys think?
>
>Thank,
>Tom
>
>On Fri, Mar 15, 2013 at 8:57 PM, Rob Vesse <rv...@do...> wrote:
>> Hey Kevin
>>
>> Discussion inline:
>>
>> From: Kevin <ke...@th...>
>> Date: Wednesday, March 13, 2013 7:40 PM
>> To: Rob Vesse <rv...@do...>
>> Subject: Integrating SPIN into dotnetrdf
>>
>> Rob,
>>
>>
>>
>> First thank you for your quality work you have done with the 
>>dotnetrdf  project.  I have seen a few different posts about your 
>>initiative to  integrate SPIN into dotnetrdf (ie.  SPIN Post).  After 
>>much reading on the  subject it really seems that SPIN would really 
>>propel/complement dotnetrdf.
>> I believe SPIN not only makes up for the missing OWL inference (Via 
>>SPIN  OWL-RL implementation), it also can expand to suit the modelers 
>>imagination.
>> The fact that the rules are in SPARQL makes for an unbeatable solution.
>> Should it matter my current effort involves query a Virtuoso database 
>>(Some  owl support) with dotnetrdf.  I would really appreciate you 
>>taking a look at  the questions below:
>>
>>
>>
>> -Have you made any further progress on integrating SPIN into dotnetrdf?
>> Would you allow me to have the source code in its current state?  
>>Could I  possibly be a contributor on this cause as I am not really 
>>equipped for the  full task?  In any case I would appreciate any 
>>source code which I could use  as a learning tool.
>>
>>
>> No I haven't had time to do anything on SPIN for a long time now.  I've
>>been
>> primarily concentrating on getting core features stabilized such as the
>> SPARQL engine which are obviously fairly key to building stuff like
>>SPIN on
>> top.
>>
>> However I still don't have time to work on SPIN directly so if you want
>>to
>> work on this please feel free, find the code in the mercurial
>>repository at
>> https://bitbucket.org/dotnetrdf/dotnetrdf
>>
>> The previous and very minimal SPIN stub is under Libraries\Query\Spin,
>> create your own fork and then you can send pull requests as and when you
>> have something to
>>
>> The key things that need to be done to get the core of SPIN implemented
>>are
>> as follows:
>>
>> Update the current spin-sparql-syntax.ttl to a current version, it
>>likely
>> doesn't represent the current version of the spec (this is primarily a
>> convenience reference for developers)
>> Finish the existing stubs for converting queries into their SPIN RDF
>> representation (see SpinSyntax.cs)
>> Write code to turn a RDF encoding of a SPIN query into a query
>>
>> The middle one would be the easiest to start with since there is already
>> some partial stubs to get you started.
>>
>>
>>
>> -From the available TopQuadrant documentation I have tried to deduce how
>> dotnetrdf might implement SPIN.  According to SPIN tutrial, TopBraid
>>finds
>> all SPIN inferecer rules and runs them when you hit play.  Would
>>dotnetrdf
>> SPIN inferencer only run the rules that are associated with the class
>> structure being queried?  Basically I am confused how dotnetrdf decides
>> when/how/which SPIN rules to run for a given query.
>>
>>
>> That's an implementation detail, we would control how and when rules get
>> run.  We need to get the basic implementation of SPIN done first before
>>this
>> aspect of things gets implemented anyway.
>>
>>
>>
>> -How much of SPIN could dotnetrdf possibly support.? It appears SPIN
>> contains Inference Rules, Constraint Checking, and ability to Isolate
>>rules
>> for certain conditions.  Also the TopBraid tool seems to have
>>"User-Defined
>> SPARQL functions" and "SPIN Query Templates".  I imagine dotnetrdf would
>> have to keep up with any SPIN improvements.
>>
>>
>> All of those are supportable in some shape of form, until we have the
>>core
>> of SPIN up and running we can't really implement those.  Most of those
>> features run on top of the SPIN core and so will ultimately just be
>> implementation details once we have a core to build upon.  User defined
>> SPARQL functions are basically just SPARQL queries that return a single
>> value and query templates are just parameterized queries both of which
>>the
>> existing SPARQL engine is capable of supporting in one way or another.
>>So
>> it is just a case of exposing that functionality in the SPIN style.
>>
>> Hope this is enough to get you started, if not please let us know,
>>
>> Rob
>>
>>
>>
>> Regards,
>>
>> Kevin
>>
>>
>> 
>>-------------------------------------------------------------------------
>>-----
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> dotNetRDF-develop mailing list
>> dot...@li...
>> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>>
>
>--------------------------------------------------------------------------
>----
>Everyone hates slow websites. So do we.
>Make your web apps faster with AppDynamics
>Download AppDynamics Lite for free today:
>http://p.sf.net/sfu/appdyn_d2d_mar
>_______________________________________________
>dotNetRDF-develop mailing list
>dot...@li...
>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop

Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf

[Tomasz P. <tom...@gm...>]

Kevin,

I am not aware of any such API attempt in other languages. For Java it
would have to be a lot different as Java currently has a limited
support for lambdas. I haven't got a clue about Ruby or Python for
instance.

There is no deadline. I got most of SPARQL 1.0 and some SPARQL 1.1
implemented. The general API is pretty much frozen at this point and
thus implementig the rest is just wrapping the remaining SPARQL
features. However because this hasn't been released yet, some things
are bound to change. Especially there could be missing or superfluos
overloads for some of the methods here and there. Having said that I
think the API is complete enough to employ in a real world use line
SPIN. Anything missing we would implement whenever a need arises.

If we were to use Fluent SPARQL for SPIN, it would be a great testing
ground and motivation to get it 100% complete finally.

Thanks,
Tom

On Sun, Mar 17, 2013 at 4:57 AM, Kevin <ke...@th...> wrote:
> Tom,
>
> I read your Fluent SPQRQL link and the proposal seemed helpful, elegant, and
> LINQish.  I am curious do other SPARQL engines (ie. Java Based) have the
> APIs akin to Fluent SPARAL?  Exactly how far is the Fluent SPARQL
> development and do you have a target date?
>
> Thanks,
> Kevin
>
> -----Original Message-----
> From: Rob Vesse [mailto:rv...@do...]
> Sent: Friday, March 15, 2013 3:45 PM
> To: dotNetRDF Developer Discussion and Feature Request
> Cc: Kevin
> Subject: Re: [dotNetRDF-Develop] Integrating SPIN into dotnetrdf
>
> Hey
>
> Yes I think using the Fluent Query API for helping to convert the RDF
> representation back into queries would likely make life much easier.
>
> Rob
>
> On 3/15/13 1:19 PM, "Tomasz Pluskiewicz" <tom...@gm...>
> wrote:
>
>>Hi Kevin, Rob
>>
>>I have been thinking about SPIN for a very long time. And I have
>>actually very recently read somehere on answeres.semanticweb.com about
>>using SPIN to implement OWL reasoning.
>>
>>Ever since I had started that fluent SPARQL I thought it could actually
>>be a good base to easily go from SPIN RDF representation to actual
>>queries.
>>
>>I know that the implementation is far from complete. I have been busy
>>with a multitude of other tasks but if it could prove useful in
>>implementing SPIN it would be great. Actually one of my goals I did
>>have in mind was to use Fluent SPARQL for SPIN. Especially that working
>>with query strings or low-level SPARQL API will be far from
>>developer-friendly in te long run IMO.
>>
>>Kevin, please have a look at my fork, where I have been documenting my
>>work on a wiki: http://bitbucket.org/romanticweb/dotnetrdf/wiki/Home
>>
>>What do you guys think?
>>
>>Thank,
>>Tom
>>
>>On Fri, Mar 15, 2013 at 8:57 PM, Rob Vesse <rv...@do...> wrote:
>>> Hey Kevin
>>>
>>> Discussion inline:
>>>
>>> From: Kevin <ke...@th...>
>>> Date: Wednesday, March 13, 2013 7:40 PM
>>> To: Rob Vesse <rv...@do...>
>>> Subject: Integrating SPIN into dotnetrdf
>>>
>>> Rob,
>>>
>>>
>>>
>>> First thank you for your quality work you have done with the
>>>dotnetrdf  project.  I have seen a few different posts about your
>>>initiative to  integrate SPIN into dotnetrdf (ie.  SPIN Post).  After
>>>much reading on the  subject it really seems that SPIN would really
>>>propel/complement dotnetrdf.
>>> I believe SPIN not only makes up for the missing OWL inference (Via
>>>SPIN  OWL-RL implementation), it also can expand to suit the modelers
>>>imagination.
>>> The fact that the rules are in SPARQL makes for an unbeatable solution.
>>> Should it matter my current effort involves query a Virtuoso database
>>>(Some  owl support) with dotnetrdf.  I would really appreciate you
>>>taking a look at  the questions below:
>>>
>>>
>>>
>>> -Have you made any further progress on integrating SPIN into dotnetrdf?
>>> Would you allow me to have the source code in its current state?
>>>Could I  possibly be a contributor on this cause as I am not really
>>>equipped for the  full task?  In any case I would appreciate any
>>>source code which I could use  as a learning tool.
>>>
>>>
>>> No I haven't had time to do anything on SPIN for a long time now.  I've
>>>been
>>> primarily concentrating on getting core features stabilized such as the
>>> SPARQL engine which are obviously fairly key to building stuff like
>>>SPIN on
>>> top.
>>>
>>> However I still don't have time to work on SPIN directly so if you want
>>>to
>>> work on this please feel free, find the code in the mercurial
>>>repository at
>>> https://bitbucket.org/dotnetrdf/dotnetrdf
>>>
>>> The previous and very minimal SPIN stub is under Libraries\Query\Spin,
>>> create your own fork and then you can send pull requests as and when you
>>> have something to
>>>
>>> The key things that need to be done to get the core of SPIN implemented
>>>are
>>> as follows:
>>>
>>> Update the current spin-sparql-syntax.ttl to a current version, it
>>>likely
>>> doesn't represent the current version of the spec (this is primarily a
>>> convenience reference for developers)
>>> Finish the existing stubs for converting queries into their SPIN RDF
>>> representation (see SpinSyntax.cs)
>>> Write code to turn a RDF encoding of a SPIN query into a query
>>>
>>> The middle one would be the easiest to start with since there is already
>>> some partial stubs to get you started.
>>>
>>>
>>>
>>> -From the available TopQuadrant documentation I have tried to deduce how
>>> dotnetrdf might implement SPIN.  According to SPIN tutrial, TopBraid
>>>finds
>>> all SPIN inferecer rules and runs them when you hit play.  Would
>>>dotnetrdf
>>> SPIN inferencer only run the rules that are associated with the class
>>> structure being queried?  Basically I am confused how dotnetrdf decides
>>> when/how/which SPIN rules to run for a given query.
>>>
>>>
>>> That's an implementation detail, we would control how and when rules get
>>> run.  We need to get the basic implementation of SPIN done first before
>>>this
>>> aspect of things gets implemented anyway.
>>>
>>>
>>>
>>> -How much of SPIN could dotnetrdf possibly support.? It appears SPIN
>>> contains Inference Rules, Constraint Checking, and ability to Isolate
>>>rules
>>> for certain conditions.  Also the TopBraid tool seems to have
>>>"User-Defined
>>> SPARQL functions" and "SPIN Query Templates".  I imagine dotnetrdf would
>>> have to keep up with any SPIN improvements.
>>>
>>>
>>> All of those are supportable in some shape of form, until we have the
>>>core
>>> of SPIN up and running we can't really implement those.  Most of those
>>> features run on top of the SPIN core and so will ultimately just be
>>> implementation details once we have a core to build upon.  User defined
>>> SPARQL functions are basically just SPARQL queries that return a single
>>> value and query templates are just parameterized queries both of which
>>>the
>>> existing SPARQL engine is capable of supporting in one way or another.
>>>So
>>> it is just a case of exposing that functionality in the SPIN style.
>>>
>>> Hope this is enough to get you started, if not please let us know,
>>>
>>> Rob
>>>
>>>
>>>
>>> Regards,
>>>
>>> Kevin
>>>
>>>
>>>
>>>-------------------------------------------------------------------------
>>>-----
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>> _______________________________________________
>>> dotNetRDF-develop mailing list
>>> dot...@li...
>>> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>>>
>>
>>--------------------------------------------------------------------------
>>----
>>Everyone hates slow websites. So do we.
>>Make your web apps faster with AppDynamics
>>Download AppDynamics Lite for free today:
>>http://p.sf.net/sfu/appdyn_d2d_mar
>>_______________________________________________
>>dotNetRDF-develop mailing list
>>dot...@li...
>>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> dotNetRDF-develop mailing list
> dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop