Menu
▾
▴
dotnetrdf-develop — Developer Discussion and Feature Request
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
|
Feb
(11) |
Mar
(17) |
Apr
(12) |
May
(2) |
Jun
(20) |
Jul
(2) |
Aug
(2) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(5) |
| 2011 |
Jan
(4) |
Feb
(1) |
Mar
(2) |
Apr
(2) |
May
(5) |
Jun
|
Jul
(12) |
Aug
(4) |
Sep
(5) |
Oct
(1) |
Nov
(38) |
Dec
(27) |
| 2012 |
Jan
(46) |
Feb
(182) |
Mar
(83) |
Apr
(22) |
May
(68) |
Jun
(47) |
Jul
(135) |
Aug
(84) |
Sep
(57) |
Oct
(45) |
Nov
(27) |
Dec
(61) |
| 2013 |
Jan
(59) |
Feb
(78) |
Mar
(66) |
Apr
(107) |
May
(27) |
Jun
(56) |
Jul
(53) |
Aug
(3) |
Sep
(19) |
Oct
(41) |
Nov
(44) |
Dec
(54) |
| 2014 |
Jan
(49) |
Feb
(72) |
Mar
(22) |
Apr
(41) |
May
(63) |
Jun
(27) |
Jul
(45) |
Aug
(12) |
Sep
(3) |
Oct
(8) |
Nov
(27) |
Dec
(16) |
| 2015 |
Jan
(3) |
Feb
(20) |
Mar
(6) |
Apr
(4) |
May
(15) |
Jun
(2) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(16) |
May
(9) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: COHEN Y. <yo...@ra...> - 2012-11-11 14:00:43
|
Hi, - Connecting to Virtuoso from localhost works like a charm (using dotNetRDF VirtuosoManager). - Trying to access it (e.g., ListGraphs) from a client on another machine on the same intrAnet fails with the message: "An address incompatible with the request protocol was used" followed by the [IPV6] of the machine hosting Virtuoso. Is there a workaround? Am I doing somthing wrong? Best, Yossi Cohen Technical Lead Smart Intelligence Systems ********************************************************************************************** This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter "RAFAEL") contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:la...@ra... and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. ********************************************************************************************** |
|
From: <tr...@do...> - 2012-11-10 00:07:06
|
<p>A new comment has been added to the following issue.</p>
<table border="0">
<tr>
<td width="90px" valign="top"><b>Title:</b></td>
<td>Update SPARQL Endpoint implementations to pass all the SPARQL 1.1 Protocol Tests</td>
</tr>
<tr>
<td><b>Project:</b></td>
<td>Core Library (dotNetRDF.dll)</td>
</tr>
<tr>
<td><b>Created By:</b></td>
<td>Rob Vesse</td>
</tr>
<tr>
<td><b>Date:</b></td>
<td>2012-11-10 12:06 AM</td>
</tr>
<tr>
<td><b>Comment:</b></td>
</tr>
<tr>
<td colspan="2"><p>
Made some progress on this today, improved score to 22/35</p></td>
</tr>
</table>
<p>
More information on this issue can be found at
<a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=289" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=289</a></p>
<p style="text-align:center;font-size:8pt;padding:5px;">
If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options.
</p>
|
|
From: <tr...@do...> - 2012-11-09 23:03:39
|
<p>The following issue has been added to a project that you are monitoring.</p>
<table border="0">
<tr>
<td width="90px" valign="top"><b>Title:</b></td>
<td>Update SPARQL Endpoint implementations to pass all the SPARQL 1.1 Protocol Tests</td>
</tr>
<tr>
<td><b>Project:</b></td>
<td>Core Library (dotNetRDF.dll)</td>
</tr>
<tr>
<td><b>Created By:</b></td>
<td>Rob Vesse</td>
</tr>
<tr>
<td><b>Milestone:</b></td>
<td>0.8.0 RC 1</td>
</tr>
<tr>
<td><b>Category:</b></td>
<td>Web (ASP.Net)</td>
</tr>
<tr>
<td><b>Priority:</b></td>
<td>Critical</td>
</tr>
<tr>
<td><b>Type:</b></td>
<td>Bug</td>
</tr>
<tr>
<td><b>Description:</b></td>
</tr>
<tr>
<td colspan="2"><p>
Tests can be run by hitting the validator at <a href="http://www.w3.org/2009/sparql/protocol_validator">http://www.w3.org/2009/sparql/protocol_validator</a> - run against the live install of the latest Leviathan code at <a href="http://www.w3.org/2009/sparql/protocol_validator?query_url=http%3A%2F%2Fwww.dotnetrdf.org%2Fdemos%2Fserver%2Fquery&update_url=http%3A%2F%2Fwww.dotnetrdf.org%2Fdemos%2Fserver%2Fupdate&software=http%3A%2F%2Fwww.dotnetrdf.org%2Fleviathan%23&submit=Submit">http://www.w3.org/2009/sparql/protocol_validator?query_url=http%3A%2F%2Fwww.dotnetrdf.org%2Fdemos%2Fserver%2Fquery&update_url=http%3A%2F%2Fwww.dotnetrdf.org%2Fdemos%2Fserver%2Fupdate&software=http%3A%2F%2Fwww.dotnetrdf.org%2Fleviathan%23&submit=Submit</a></p>
<p>
As of writing we pass 18/35 which is just over 50%, particular issues to look at from reading the report are as follows:</p>
<ul>
<li>
text/plain returned for CONSTRUCT/DESCRIBE results - we should be returning the proper MIME type for NTriples or defaulting to Turtle or RDF/XML instead</li>
<li>
Queries should use the endpoint URI as the Default Base URI for the parser</li>
<li>
Several update then query to validate update result tests fail - cause not obvious</li>
<li>
POST should fail when Content-Type is missing/bad for both query and update</li>
<li>
application/sparql-query or application/sparql-update POST must be UTF-8</li>
<li>
GET on update endpoint should give HTTP 400</li>
<li>
Multiple update= parameters should give HTTP 400</li>
<li>
Update syntax errors don't give HTTP 400</li>
</ul></td>
</tr>
</table>
<p>
More information on this issue can be found at
<a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=289" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=289</a></p>
<p style="text-align:center;font-size:8pt;padding:5px;">
If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options.
</p>
|
|
From: Tomasz P. <tom...@gm...> - 2012-11-09 19:55:42
|
Great stuff. I just have a little fix. It is included in the pull request I've just created. Tom On Wed, Nov 7, 2012 at 7:24 PM, Rob Vesse <rv...@do...> wrote: > Hey All > > I've just completed a refactoring of how we manage dependencies in the > project. All external dependencies are now obtained via NuGet and there is > no longer a Dependencies folder checked into source control. > > I've also changed how we do the alternative builds of the libraries so the > main solution now has projects included to build the libraries for all > supported platforms. The alternative builds get synced up with the main > build by a pre-build event so when you add/remove something to/from the main > build on the next compile of the alternative builds the change(s) will be > automatically pulled in for you (though VS will make you reload the > project). > > Note this does however mean that you will now need to have Silverlight 4 > Tools for VS and Windows Phone 7.1 Tools for VS installed to build the > solution correctly. > > Hopefully this makes building things much easier for people since all the > libraries can now be built directly from Visual Studio > > Rob > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > |
|
From: Rob V. <rv...@do...> - 2012-11-09 19:07:37
|
Hey All Would anyone object if I went ahead and made the 0.8.0 release sometime next week? There's a whole bunch of bug fixes in there, updates to SPARQL 1.1 compliance and general improvements to SPARQL implementation plus significant fixes and updates to the Query.FullText library. I had originally thought that we might get the Fluent Query API in this release but looking at what Tom's got so far (which is great btw) it's clearly a much bigger lift than I first thought. I'd rather push that to unscheduled and have it be merged in as and when Tom thinks it's ready rather than holding back a useful (and primarily bug fix) release. Any other thoughts/objections? Rob |
|
From: <tr...@do...> - 2012-11-09 17:30:33
|
<p>The following issue has been updated by Rob Vesse:</p>
<table border="0">
<tr>
<td width="90px" valign="top"><b>Title:</b></td>
<td>Implement the rdfDBStudio tool</td>
</tr>
<tr>
<td><b>Project:</b></td>
<td>Toolkit</td>
</tr>
<tr>
<td colspan="2"><b>Changes:</b></td>
</tr>
<tr>
<td colspan="2">
<ul>
<li>Parent issue changed from "" to "Added"
</li>
</ul>
</td>
</tr>
</table>
<p>
More information on this issue can be found at
<a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=277" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=277</a></p>
<p style="text-align:center;font-size:8pt;padding:5px;">
If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options.
</p>
|
|
From: Rob V. <rv...@do...> - 2012-11-08 17:40:04
|
Ok Given that we have consensus I have gone ahead and updated the code base If you find any mention of GPL in the code please let me know (or just fix it yourself) I will update the website and project pages when we make the next release Rob From: Kal Ahmed <ka...@ne...> Reply-To: dotNetRDF Developer Discussion and Feature Request <dot...@li...> Date: Thursday, November 8, 2012 1:09 AM To: dotNetRDF Developer Discussion and Feature Request <dot...@li...> Subject: Re: [dotNetRDF-Develop] License Model simplification? > +1 > > > On Thu, Nov 8, 2012 at 5:36 AM, Tomasz Pluskiewicz > <tom...@gm...> wrote: >> >> I too agree. >> >> Tom >> >> 08-11-2012 04:11, "Ron Michael Zettlemoyer" <ro...@ze...> napisał(a): >>> Sounds like a good idea, Rob. >>> >>> >>> On Wed, Nov 7, 2012 at 5:16 PM, Rob Vesse <rv...@do...> wrote: >>>> Hi All >>>> >>>> I've been considering simplifying the license model of dotNetRDF. >>>> Currently we have a choose your own license model where you can choose from >>>> GPL, LGPL or MIT >>>> >>>> I propose to simplify this to just MIT I.e. the most permissive >>>> >>>> Any objections to this? >>>> >>>> Rob >>>> >>>> --------------------------------------------------------------------------- >>>> --- >>>> LogMeIn Central: Instant, anywhere, Remote PC access and management. >>>> Stay in control, update software, and manage PCs from one command center >>>> Diagnose problems and improve visibility into emerging IT issues >>>> Automate, monitor and manage. Do more in less time with Central >>>> http://p.sf.net/sfu/logmein12331_d2d >>>> _______________________________________________ >>>> 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_nov >>> >>> _______________________________________________ >>> 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_nov >> _______________________________________________ >> dotNetRDF-develop mailing list >> dot...@li... >> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >> > > > > -- > Kal Ahmed > Director, Networked Planet Limited > e: kal...@ne... > w: www.networkedplanet.com <http://www.networkedplanet.com> > > ------------------------------------------------------------------------------ > 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_nov____________________________________________ > ___ dotNetRDF-develop mailing list dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop |
|
From: Khalil A. <ka...@ne...> - 2012-11-08 09:31:00
|
+1 On Thu, Nov 8, 2012 at 5:36 AM, Tomasz Pluskiewicz < tom...@gm...> wrote: > I too agree. > > Tom > 08-11-2012 04:11, "Ron Michael Zettlemoyer" <ro...@ze...> > napisał(a): > >> Sounds like a good idea, Rob. >> >> >> On Wed, Nov 7, 2012 at 5:16 PM, Rob Vesse <rv...@do...> wrote: >> >>> Hi All >>> >>> I've been considering simplifying the license model of dotNetRDF. >>> Currently we have a choose your own license model where you can choose >>> from GPL, LGPL or MIT >>> >>> I propose to simplify this to just MIT I.e. the most permissive >>> >>> Any objections to this? >>> >>> Rob >>> >>> >>> ------------------------------------------------------------------------------ >>> LogMeIn Central: Instant, anywhere, Remote PC access and management. >>> Stay in control, update software, and manage PCs from one command center >>> Diagnose problems and improve visibility into emerging IT issues >>> Automate, monitor and manage. Do more in less time with Central >>> http://p.sf.net/sfu/logmein12331_d2d >>> _______________________________________________ >>> 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_nov >> >> _______________________________________________ >> 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_nov > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > -- Kal Ahmed Director, Networked Planet Limited e: kal...@ne... w: www.networkedplanet.com |
|
From: Tomasz P. <tom...@gm...> - 2012-11-08 05:36:54
|
I too agree. Tom 08-11-2012 04:11, "Ron Michael Zettlemoyer" <ro...@ze...> napisał(a): > Sounds like a good idea, Rob. > > > On Wed, Nov 7, 2012 at 5:16 PM, Rob Vesse <rv...@do...> wrote: > >> Hi All >> >> I've been considering simplifying the license model of dotNetRDF. >> Currently we have a choose your own license model where you can choose >> from GPL, LGPL or MIT >> >> I propose to simplify this to just MIT I.e. the most permissive >> >> Any objections to this? >> >> Rob >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Central: Instant, anywhere, Remote PC access and management. >> Stay in control, update software, and manage PCs from one command center >> Diagnose problems and improve visibility into emerging IT issues >> Automate, monitor and manage. Do more in less time with Central >> http://p.sf.net/sfu/logmein12331_d2d >> _______________________________________________ >> 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_nov > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > |
|
From: Ron M. Z. <ro...@ze...> - 2012-11-08 03:11:31
|
Sounds like a good idea, Rob. On Wed, Nov 7, 2012 at 5:16 PM, Rob Vesse <rv...@do...> wrote: > Hi All > > I've been considering simplifying the license model of dotNetRDF. > Currently we have a choose your own license model where you can choose > from GPL, LGPL or MIT > > I propose to simplify this to just MIT I.e. the most permissive > > Any objections to this? > > Rob > > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > |
|
From: Rob V. <rv...@do...> - 2012-11-07 22:17:25
|
Hi All I've been considering simplifying the license model of dotNetRDF. Currently we have a choose your own license model where you can choose from GPL, LGPL or MIT I propose to simplify this to just MIT I.e. the most permissive Any objections to this? Rob |
|
From: Rob V. <rv...@do...> - 2012-11-07 18:25:50
|
Hey All I've just completed a refactoring of how we manage dependencies in the project. All external dependencies are now obtained via NuGet and there is no longer a Dependencies folder checked into source control. I've also changed how we do the alternative builds of the libraries so the main solution now has projects included to build the libraries for all supported platforms. The alternative builds get synced up with the main build by a pre-build event so when you add/remove something to/from the main build on the next compile of the alternative builds the change(s) will be automatically pulled in for you (though VS will make you reload the project). Note this does however mean that you will now need to have Silverlight 4 Tools for VS and Windows Phone 7.1 Tools for VS installed to build the solution correctly. Hopefully this makes building things much easier for people since all the libraries can now be built directly from Visual Studio Rob |
|
From: Tomasz P. <tom...@gm...> - 2012-10-30 19:38:32
|
Hi Rob Again, some comments inline On Tue, Oct 30, 2012 at 7:54 PM, Rob Vesse <rv...@do...> wrote: > Hey Tom > > There's no such thing as a IBooleanSparqlExpression since an expression is > not required to evaluate directly to a boolean in order for it to be > usable in a FILTER > > The result of evaluating the expression is transformed into a boolean > using the SPARQL Effective Boolean Value rules > (http://www.w3.org/TR/sparql11-query/#ebv) > > The upshot of which is that there should be no need to restrict what > expressions can be nested in each other, implementations will throw errors > and otherwise behave appropriately if a non-sensical expression results. > I know that this is not necessary from expressions' point of view. I understand that modifications in the existing core will be superfluous. The thing is that errors at runtime is a bit late IMHO especially that we know what the expected results are for each function/expression call. I think that users would benefit from a more strict API. And there still will be an opening to pass any expression and let it break in the processor. > > Other comments inline: > > On 10/30/12 5:05 AM, "Tomasz Pluskiewicz" <tom...@gm...> > wrote: > >>Hi >> >>I have recently started implementing filtering part of the fluent API >>and I would like your opinion on how it should be designed. >> >>1. From high level view I imagine we could go for an >>IExpressionBuilder as previously discussed. For example there could be >>a call like >> >>graphPattern.Filter(eb => eb.Regex(value, pattern, flags)) >> >>There are quite a few built-in methods in SPARQL and many more >>available in dotNetRDF out-of-the-box so implementing all of those as >>builder methods will be an effort but there of course will be an >>opening for passing any pre-built ISparqlExpression: >> >>graphPattern.Filter(eb => eb.Expression(new RegexFunction(...))) >> >>Also I think we could group some of the functions in extension >>classes. XPath, Leviathan or ARQ libraries are some likely candidates. >> >>2. The expression builder methods will have to be aware of the >>expressions' return types so that it should be illegal (ie. compile >>error) to call any of the below >> >>// str function returns literal and not boolean >>graphPattern.Filter(eb => eb.Str(literal)) >> >>// isBlank expects an RDF term and regex returns boolean >>graphPattern.Filter(eb => eb.IsBlank(eb.Regex(...))); >> >>There are two conclusions coming from this. >> >>* Filter method should have it's signature similar to: >>Filter(Func<IExpressionBuilder, IBooleanSparqlExpression> eb) >>* Each method on the expression builder should return one of the >>expression types depending on the return type >> >>I can't find anything like IBooleanExpression in the library. There is >>just ISparqlExpression. Do you thnik we could add such (marker?) >>interfaces to the VDS.RDF.Query.Expressions namespace or just control >>the expressions' return types in the builder? > > See above, this is not necessary > >> >>3. It should be possible to chain expression calls to manipulate them >>logically. For example: >> >>graphPattern.Filter(eb => eb.Regex(value, pattern).Or(eb.Regex(value, >>otherPattern))) >> >>or >> >>graphPattern.Filter(eb => eb.Regex(value, pattern).Or().Regex(value, >>otherPattern)) >> >>or >> >>graphPattern.Filter(eb => eb.Or(eb.Regex(value, pattern), >>eb.Regex(value, otherPattern))) >> >>Negation example: >> >>graphPattern.Filter(eb => eb.Not(eb.Regex(value, pattern)) >> >>or >> >>graphPattern.Filter(eb => eb.Not().Regex(value, pattern)) >> >>We should decide which of the above is the best design as it will >>probably influence the internals and flexibility of expression >>builder. Or actually, meybe we could comnbine the two... > > I like the first options for both personally > Me too. I though more about it and it prorably is the only option flexible enough for any combination of operators. I will go this way. > >> >>4. Many functions accept literal parameters but there can also be a >>result of another expression call. For example to match gmail.com >>email addresses one would call >> >>graphPattern.Filter(eb => eb.Regex(eb.Str("email"), "@gmail.com$")) >> >>However the problem here is to distinguish between plain string and a >>variable's name. In the above "email" is a variable and the other >>string is of course a simple string. One way to have it would be to >>encapsulate the VariableExpression with its own method so the last >>call would be rewritten as >> >>graphPattern.Filter(eb => eb.Regex(eb.Str(eb.Variable("email")), >>"@gmail.com$")) >> >>Then the I am not convicned though as it could be a little too >>verbose. Are there any other ideas? > > I think we may just have to live with having a Variable() and a Constant() > method, a Constant() method would be nice because then you can accept a > variety of common types as constants and use the existing ToLiteral() > extension methods to turn them into appropriate RDF terms e.g. > > eb.Constant(1); > > or > > eb.Constant(1.2e5); > > or > > eb.Constant(true); > >> >>5. Lastly, what are expression factories? Are they of any use in this >>case? > > Expression factories allow for creation of functions based on function > URIs rather than on keywords, essentially they provide a mechanism to > support the SPARQL concept of extension functions > (http://www.w3.org/TR/sparql11-query/#extensionFunctions). You may want > to provide a general builder call for creating these: > > eb.Function(uri, args); > > Making the definition of args flexible enough to allow for zero/more > arguments > > Rob > >> >>Thanks, >>Tom >> >>-------------------------------------------------------------------------- >>---- >>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_sfd2d_oct >>_______________________________________________ >>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_sfd2d_oct > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop |
|
From: Rob V. <rv...@do...> - 2012-10-30 18:55:08
|
Hey Tom There's no such thing as a IBooleanSparqlExpression since an expression is not required to evaluate directly to a boolean in order for it to be usable in a FILTER The result of evaluating the expression is transformed into a boolean using the SPARQL Effective Boolean Value rules (http://www.w3.org/TR/sparql11-query/#ebv) The upshot of which is that there should be no need to restrict what expressions can be nested in each other, implementations will throw errors and otherwise behave appropriately if a non-sensical expression results. Other comments inline: On 10/30/12 5:05 AM, "Tomasz Pluskiewicz" <tom...@gm...> wrote: >Hi > >I have recently started implementing filtering part of the fluent API >and I would like your opinion on how it should be designed. > >1. From high level view I imagine we could go for an >IExpressionBuilder as previously discussed. For example there could be >a call like > >graphPattern.Filter(eb => eb.Regex(value, pattern, flags)) > >There are quite a few built-in methods in SPARQL and many more >available in dotNetRDF out-of-the-box so implementing all of those as >builder methods will be an effort but there of course will be an >opening for passing any pre-built ISparqlExpression: > >graphPattern.Filter(eb => eb.Expression(new RegexFunction(...))) > >Also I think we could group some of the functions in extension >classes. XPath, Leviathan or ARQ libraries are some likely candidates. > >2. The expression builder methods will have to be aware of the >expressions' return types so that it should be illegal (ie. compile >error) to call any of the below > >// str function returns literal and not boolean >graphPattern.Filter(eb => eb.Str(literal)) > >// isBlank expects an RDF term and regex returns boolean >graphPattern.Filter(eb => eb.IsBlank(eb.Regex(...))); > >There are two conclusions coming from this. > >* Filter method should have it's signature similar to: >Filter(Func<IExpressionBuilder, IBooleanSparqlExpression> eb) >* Each method on the expression builder should return one of the >expression types depending on the return type > >I can't find anything like IBooleanExpression in the library. There is >just ISparqlExpression. Do you thnik we could add such (marker?) >interfaces to the VDS.RDF.Query.Expressions namespace or just control >the expressions' return types in the builder? See above, this is not necessary > >3. It should be possible to chain expression calls to manipulate them >logically. For example: > >graphPattern.Filter(eb => eb.Regex(value, pattern).Or(eb.Regex(value, >otherPattern))) > >or > >graphPattern.Filter(eb => eb.Regex(value, pattern).Or().Regex(value, >otherPattern)) > >or > >graphPattern.Filter(eb => eb.Or(eb.Regex(value, pattern), >eb.Regex(value, otherPattern))) > >Negation example: > >graphPattern.Filter(eb => eb.Not(eb.Regex(value, pattern)) > >or > >graphPattern.Filter(eb => eb.Not().Regex(value, pattern)) > >We should decide which of the above is the best design as it will >probably influence the internals and flexibility of expression >builder. Or actually, meybe we could comnbine the two... I like the first options for both personally > >4. Many functions accept literal parameters but there can also be a >result of another expression call. For example to match gmail.com >email addresses one would call > >graphPattern.Filter(eb => eb.Regex(eb.Str("email"), "@gmail.com$")) > >However the problem here is to distinguish between plain string and a >variable's name. In the above "email" is a variable and the other >string is of course a simple string. One way to have it would be to >encapsulate the VariableExpression with its own method so the last >call would be rewritten as > >graphPattern.Filter(eb => eb.Regex(eb.Str(eb.Variable("email")), >"@gmail.com$")) > >Then the I am not convicned though as it could be a little too >verbose. Are there any other ideas? I think we may just have to live with having a Variable() and a Constant() method, a Constant() method would be nice because then you can accept a variety of common types as constants and use the existing ToLiteral() extension methods to turn them into appropriate RDF terms e.g. eb.Constant(1); or eb.Constant(1.2e5); or eb.Constant(true); > >5. Lastly, what are expression factories? Are they of any use in this >case? Expression factories allow for creation of functions based on function URIs rather than on keywords, essentially they provide a mechanism to support the SPARQL concept of extension functions (http://www.w3.org/TR/sparql11-query/#extensionFunctions). You may want to provide a general builder call for creating these: eb.Function(uri, args); Making the definition of args flexible enough to allow for zero/more arguments Rob > >Thanks, >Tom > >-------------------------------------------------------------------------- >---- >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_sfd2d_oct >_______________________________________________ >dotNetRDF-develop mailing list >dot...@li... >https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop |
|
From: Tomasz P. <tom...@gm...> - 2012-10-30 12:05:54
|
Hi I have recently started implementing filtering part of the fluent API and I would like your opinion on how it should be designed. 1. From high level view I imagine we could go for an IExpressionBuilder as previously discussed. For example there could be a call like graphPattern.Filter(eb => eb.Regex(value, pattern, flags)) There are quite a few built-in methods in SPARQL and many more available in dotNetRDF out-of-the-box so implementing all of those as builder methods will be an effort but there of course will be an opening for passing any pre-built ISparqlExpression: graphPattern.Filter(eb => eb.Expression(new RegexFunction(...))) Also I think we could group some of the functions in extension classes. XPath, Leviathan or ARQ libraries are some likely candidates. 2. The expression builder methods will have to be aware of the expressions' return types so that it should be illegal (ie. compile error) to call any of the below // str function returns literal and not boolean graphPattern.Filter(eb => eb.Str(literal)) // isBlank expects an RDF term and regex returns boolean graphPattern.Filter(eb => eb.IsBlank(eb.Regex(...))); There are two conclusions coming from this. * Filter method should have it's signature similar to: Filter(Func<IExpressionBuilder, IBooleanSparqlExpression> eb) * Each method on the expression builder should return one of the expression types depending on the return type I can't find anything like IBooleanExpression in the library. There is just ISparqlExpression. Do you thnik we could add such (marker?) interfaces to the VDS.RDF.Query.Expressions namespace or just control the expressions' return types in the builder? 3. It should be possible to chain expression calls to manipulate them logically. For example: graphPattern.Filter(eb => eb.Regex(value, pattern).Or(eb.Regex(value, otherPattern))) or graphPattern.Filter(eb => eb.Regex(value, pattern).Or().Regex(value, otherPattern)) or graphPattern.Filter(eb => eb.Or(eb.Regex(value, pattern), eb.Regex(value, otherPattern))) Negation example: graphPattern.Filter(eb => eb.Not(eb.Regex(value, pattern)) or graphPattern.Filter(eb => eb.Not().Regex(value, pattern)) We should decide which of the above is the best design as it will probably influence the internals and flexibility of expression builder. Or actually, meybe we could comnbine the two... 4. Many functions accept literal parameters but there can also be a result of another expression call. For example to match gmail.com email addresses one would call graphPattern.Filter(eb => eb.Regex(eb.Str("email"), "@gmail.com$")) However the problem here is to distinguish between plain string and a variable's name. In the above "email" is a variable and the other string is of course a simple string. One way to have it would be to encapsulate the VariableExpression with its own method so the last call would be rewritten as graphPattern.Filter(eb => eb.Regex(eb.Str(eb.Variable("email")), "@gmail.com$")) Then the I am not convicned though as it could be a little too verbose. Are there any other ideas? 5. Lastly, what are expression factories? Are they of any use in this case? Thanks, Tom |
|
From: Tomasz P. <tom...@gm...> - 2012-10-27 17:10:10
|
Hi Rob
Thanks. Yes this helps of course.
No I'm working on that and am doing some rethinking of the API. I will
be documenting the API in a wiki [1] on my fork. It also serves me as
a sandbox for ideas.
Currently I have made two decisions and would like your opinion.
1. I have added the IGraphPatternBuilder and decided to keep it
cleanly separated from ITriplePatternBuilder. This constrains the API
however. First, an example:
QueryBuilder.SelectAll()
.Where(tpb => tpb.Subject("s").Predicate("p").Object("o"))
.Optional(gpb => gpb.Where(tpb =>
tpb.Subject("s").PredicateUri(UriFactory.Create(RdfSpecsHelper.RdfType)).Object("type")));
Notice the second Where call inside the Optional() lambda. This is to
actually split keep the two builders apart. When I though about them
it would seem to me that ITriplePatternBuilder's and
IGraphPatternBuilder's responsibility kind of overlaps in the triple
building part.
Therefore I decided to have only the Where(), Optional(), etc. methods
on the IGraphPatternBuilder and ITriplePatternBuilder would only do
the Subject().Predicate().Object(). This is why it is necessary to
call another Where again when in scope of building a child graph
pattern. Also it won't be possible to have something like below, what
we have discussed earlier. This is where I think we would get a
reposibilities issue in our classes.
Where(tpb => tpb.Subject().Predicate().Object().Optional( ... ))
It is still possible though to nest the graph patterns indefinitely:
gpb =>
{
gpb.Where(tpb => );
gpb.Graph("g", graph =>
{
graph.Optional(optional =>
{
optional.Where(tpb => );
optional.Minus(minus => minus.Where(tpb => );
}
}
}
2. The above I'm pretty sure is fine. The second issue I'm not
convinced. Consider the code:
IQueryBuilder builder = QueryBuilder.SelectAll();
builder.Where(tpb => tpb.Subject("s").Predicate("p").Object("o"));
builder.Optional(gpb => gpb.Where(tpb =>
tpb.Subject("s").PredicateUri(UriFactory.Create(RdfSpecsHelper.RdfType)).Object("type")));
buidler.Where(tpb => tpb.Subject("x").Predicate("y").Object("z"));
Intuitively it produces
SELECT *
WHERE
{
?s ?p ?o
OPTIONAL { ?s a ?type }
?x ?y ?z
}
I decided to wit with actual building until the GetExecutableQuery()
method is called (as a side note, I think renaming it to BuildQuery()
or similar would be good). Instead of actually creaiting the Triple-
and GraphPatterns I hold on to the passed delagates and execute the
child builders later. The current problem with this approach is that
the above code produces a different query then expected. In each graph
pattern you would call the Where()s before the child graph patterns
followed by filters. So the query would be:
SELECT *
WHERE
{
?s ?p ?o
?x ?y ?z
OPTIONAL { ?s a ?type }
}
I know that in this example they are equivalent. Can you think of
cases where it would actually matter?
Thanks,
Tom
[1] https://bitbucket.org/romanticweb/dotnetrdf/wiki
On Fri, Oct 26, 2012 at 1:48 AM, Rob Vesse <rv...@do...> wrote:
> Answer #1
>
> Not all queries are required to have a Root Graph Pattern e.g.
>
> DESCRIBE <http://example>
>
> There was a bug in the ToString() form and SparqlFormatter.Format() form
> of queries where the RootGraphPattern itself has a modifier, such a query
> can never be generated by the parser (because you'll always have the outer
> { } to start the root graph pattern) so this case was never accounted for.
> Fixed in default
>
> Answer #2
>
> The two forms you've shown are equivalent, they both generate identical
> algebra. Any child graph pattern breaks the parent graph pattern and
> requires that any subsequent triple patterns be inserted into a new child
> graph pattern. This behavior is required to comply with the SPARQL
> specification
> correctly.
>
> When we generate the string form we always generate the explicitly nested
> form as this helps ensure queries round trip when serialized and re-parsed.
>
> Hope this helps,
>
> Rob
>
> On 10/25/12 12:03 PM, "Tomasz Pluskiewicz" <tom...@gm...>
> wrote:
>
>>Hi
>>
>>Thanks for your reply. I think I get the idea. I have some two
>>questions/issues about graph patterns:
>>
>>1. Why is it that new SparqlQuery has the RootGraphPattern null? It
>>causes weird behaviour what I add an optional to a query first you
>>would add the graph pattern as root. That produces an invalid query
>>like
>>
>>SELECT * WHERE
>>OPTIONAL { ... }
>>
>>Another problem there was that calling Where() after Optional() would
>>add the additional triples to Optional instead the regular root
>>pattern (because optional was added as root).
>>
>>For now I am making sure in the private QueryBuilder constructor that
>>RootGraphPattern is initialized which helps.
>>
>>2. I added a test where I first add an optional graph pattern and then
>>call Where which adds some more pattern to root. However adding triple
>>patterns to root causes an extra nesting, because adding optional
>>breaks the root graph pattern. Is that necessary? How would I produce
>>a graph pattern like:
>>
>>{
>> OPTIONAL {...}
>> ?s ?p ?o
>>}
>>
>>instead of the current result:
>>
>>{
>> OPTIONAL {...}
>> {
>> ?s ?p ?o
>> }
>>}
>>
>>Thanks
>>Tom
>>
>>On Sat, Oct 20, 2012 at 2:04 AM, Rob Vesse <rv...@do...> wrote:
>>> Hey Tom
>>>
>>> You would use it to combine multiple triple pattern builders into graph
>>> pattern builders in order to join and nest graph patterns together
>>>
>>> e.g.
>>>
>>> t1.Union(t2);
>>>
>>> Or:
>>>
>>> t1.Optional(t2);
>>>
>>> Or:
>>>
>>> t1.InGraph(new Uri("http://graph"));
>>>
>>> Or:
>>>
>>> t1.Minus(t2);
>>>
>>> The query builder would allow for either a triple pattern builder or a
>>> graph pattern builder to set the where clause. Similarly most of the
>>> above methods could either take a triple pattern builder or a graph
>>> pattern builder.
>>>
>>> Sorry for being vague but it's Friday afternoon and I'm about to head
>>>home
>>> for the weekend having only flown back into the country on Monday (yay
>>>jet
>>> lag and over tiredness)
>>>
>>> Rob
>>>
>>> On 10/19/12 8:05 AM, "Tomasz Pluskiewicz" <tom...@gm...>
>>> wrote:
>>>
>>>>Hi Rob
>>>>
>>>>I have been pondering your idea of IGraphPatternBuilder but I'm not
>>>>sure I understand. Could you give an example of how you would design
>>>>it's API?
>>>>
>>>>Thanks,
>>>>Tom
>>>>
>>>>On Thu, Oct 18, 2012 at 9:31 PM, Rob Vesse <rv...@do...> wrote:
>>>>> Hey Tom
>>>>>
>>>>> That all looks great, comments inline
>>>>>
>>>>> On 10/18/12 11:34 AM, "Tomasz Pluskiewicz"
>>>>><tom...@gm...>
>>>>> wrote:
>>>>>
>>>>>>Hi Rob
>>>>>>
>>>>>>Actually I have just today been preparing an email to agree on the
>>>>>>fluent API. Here it goes.
>>>>>>
>>>>>>I have been thinking about the shape of the fluent query API and I
>>>>>>would like to propose some changes.
>>>>>>
>>>>>>1. Currently there are quite a few overloads of the Where method. I
>>>>>>think the API will be more usable if we left only a limited number,
>>>>>>eg.
>>>>>>
>>>>>>* IQueryBuilder#Where(params ITriplePattern[] patterns)
>>>>>>* IQueryBuilder#Where(params Triple[] triples) - not sure about
>>>>>>triples here though
>>>>>>* IQueryBuilder#Where(GraphPattern)
>>>>>
>>>>> Yes I agree having a simpler high level interface for building queries
>>>>>is
>>>>> better
>>>>>
>>>>>>
>>>>>>Regarding the ast overload, what are the ways to create graph
>>>>>>patterns? I mean I have seen the ToGraphPattern() method here and
>>>>>>there. Which classes define such a method and what are differences in
>>>>>>the graph patterns they produce?
>>>>>
>>>>> ToGraphPattern() is typically on algebra classes but it not reliable
>>>>> because
>>>>> some algebras (particularly those generated by optimization) cannot be
>>>>> converted to graph patterns.
>>>>>
>>>>> Basically graph pattern wise you have the following:
>>>>>
>>>>> - Normal
>>>>> - OPTIONAL
>>>>> - GRAPH
>>>>> - UNION
>>>>> - SERVICE
>>>>> - MINUS
>>>>> - EXISTS/NOT EXISTS (within FILTER only)
>>>>>
>>>>>>
>>>>>>2. I think the API should expose functionality but with least required
>>>>>>use of the internal SPARQL types like the ITriplePattern,
>>>>>>ISparqlExpression and such. I would not remove it of course to leave
>>>>>>room for flexibility. For a day-to-day query building I think that
>>>>>>maybe creating triple patterns should be split into subjects,
>>>>>>predicates, object and possibly graphs (here this posin overlaps the
>>>>>>above about GraphPatterns). As such it sould be possible to implement
>>>>>>less code and at the same time give a greater flexibility for the user
>>>>>>and remove the burden of creating instances of the SparqlVariable
>>>>>>class and such. For example:
>>>>>>
>>>>>>var prefixes = new NamespaceMapped();
>>>>>>// set up prefixes ...
>>>>>>
>>>>>>IQueryBuilder query = QueryBuilder.Select("person", "name");
>>>>>>
>>>>>>// I have just made this up, but could be useful although string name
>>>>>>interfere with
>>>>>>// QNames. Maybe add a struct QName?
>>>>>>query.UsePrefixesFrom(prefixes);
>>>>>>
>>>>>>2a.
>>>>>>// a more flexible form of triple pattern building
>>>>>>// note the RdfType mehod. This way it would could provide some common
>>>>>>// properties/classes and also leave an opening for users to create
>>>>>>their own extension methods
>>>>>>query.Where.Subject("person").RdfType().Object(new
>>>>>>QName("foaf:Person"));
>>>>>>
>>>>>>2b.
>>>>>>// alternatively there's a proposal without the QName struct/class,
>>>>>>which I like more
>>>>>>query.Where.Subject("person").RdfType().Object<IUriNode>("foaf:Person"
>>>>>>))
>>>>>>;
>>>>>>
>>>>>>2c.
>>>>>>// here NodeMatchPattern for predicate with full Uri given and obejct
>>>>>>as a VariablePattern
>>>>>>query.Where.Subject("person").Predicate(new
>>>>>>Uri("http://xmlns.com/foaf/0.1/name")).Object("name"));
>>>>>>
>>>>>>In terms of graphs, I think that maybe we could provide one more
>>>>>>method to such ITripleVariable-producing chain, to select the
>>>>>>appropriate named graph pattern
>>>>>>
>>>>>>2d.
>>>>>>query.Where.Subject("person").Predicate(new
>>>>>>Uri("http://xmlns.com/foaf/0.1/firstName")).Object("name")).InGraph(ne
>>>>>>w
>>>>>>Uri("http://uri/of/graph"));
>>>>>>query.Where.Subject("person").Predicate(new
>>>>>>Uri("http://xmlns.com/foaf/0.1/lastName")).Object("surname")).InGraph(
>>>>>>ne
>>>>>>w
>>>>>>Uri("http://uri/of/graph"));
>>>>>>query.Optional.Subject("person").Predicate<IUriNode>("foaf:mbox_sha1su
>>>>>>m"
>>>>>>).
>>>>>>Object("emailSha1")).InGraph(new
>>>>>>Uri("http://uri/with/contact/data"));
>>>>>>
>>>>>>All the above would produce:
>>>>>>
>>>>>>ad 2a/2b and 2c
>>>>>>
>>>>>>WHERE
>>>>>>{
>>>>>> ?person a foaf:Person .
>>>>>> ?person foaf:name ?name .
>>>>>>}
>>>>>>
>>>>>>ad 2d
>>>>>>
>>>>>>WHERE
>>>>>>{
>>>>>> # calling InGraph() with same parameter should
>>>>>> # add triple pattern to same graph pattern, right?
>>>>>
>>>>> Yes that would make sense, implementing it might be slightly trickier
>>>>>but
>>>>> the notion is sound
>>>>>
>>>>> Perhaps InGraph() would turn a ITriplePatternBuilder into a
>>>>> IGraphPatternBuilder and the user
>>>>> would have the option of adding further triple/graph pattern builders
>>>>>to
>>>>> an existing one
>>>>>
>>>>>> GRAPH <http://uri/of/graph>
>>>>>> {
>>>>>> ?person foaf:firstName ?name
>>>>>> ?person foaf:lastName ?surname
>>>>>> }
>>>>>> GRAPH <http://uri/with/contact/data>
>>>>>> {
>>>>>> OPTIONAL { ?person foaf:mbox_sha1sum ?name }
>>>>>> }
>>>>>>}
>>>>>>
>>>>>>Not how the OPTIONAL has API equivalent to WHERE
>>>>>>
>>>>>>3. I have also been thinking that a simmilar way could be used to
>>>>>>create CONSTRUCT queries. However with the current static
>>>>>>initialization of query builder I would suggest slightly modifying the
>>>>>>above to reuse the same methods in both scenarios
>>>>>>
>>>>>>One way I find quite good could be using an Action<> delegate and
>>>>>>introducing an ITriplePatternBuilder interface to actually build the
>>>>>>triple patterns:
>>>>>>
>>>>>>var query = QueryBuilder.Construct(
>>>>>> (ITriplePatternBuilder tp) =>
>>>>>>tp.Subject("person").RdfType().Object<IUriNode>("ex:MyPersonClass")
>>>>>>);
>>>>>
>>>>> I like this approach, it's clean and extensible
>>>>>
>>>>> I assume we'd have ITriplePatternBuilder, maybe IGraphPatternBuilder
>>>>>and
>>>>> likely a IExpressionBuilder ?
>>>>>
>>>>>>
>>>>>>With this approach, the Where/Optional would change to:
>>>>>>
>>>>>>query.Where( tp =>
>>>>>>tp.Subject("person").RdfType().Object<IUriNode>("foaf:Person")) );
>>>>>>
>>>>>>and internally bouth would look somewhat like:
>>>>>>
>>>>>>public IQueryBuilder Where(Action<ITriplePatternBuilder>
>>>>>>buildTriplePatterns)
>>>>>>{
>>>>>> var builder = new TriplePatternBuilder(); //implementation internal
>>>>>> buildTriplePatterns(builder);
>>>>>> return Where(builder.TriplePatterns.ToArray());
>>>>>>}
>>>>>>
>>>>>>I think this way we get a clean seperation of concerns, good
>>>>>>testability and room for extensibility.
>>>>>>
>>>>>>4. Ask query is trivial. The SPARQL update could also use the proposed
>>>>>>ITriplePatternBuilder I think
>>>>>>
>>>>>>5. Basic federated queries could be achived in a simmilar way the
>>>>>>InGraph() method is used above for
>>>>>>
>>>>>>6. We need a method for the BIND keyword, eg.
>>>>>>
>>>>>>public IQueryBuilderBind(ISparqlExpression expression, string
>>>>>>variableName) { ... }
>>>>>
>>>>> There could maybe just be a method on the ITriplePatternBuilder to
>>>>>create
>>>>> a BIND, possible also similar for FILTER and so forth
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Oh well, there is much more, but we have enough to discuss just for
>>>>>>now. Tell me what are your feelings about all the above. You are
>>>>>>certainly more experienced with SPARQL so I would be greateful for
>>>>>>your own ideas for this feature, which I'm sure you have :).
>>>>>>
>>>>>>Also, what do you think would be the greatest challenges here?
>>>>>
>>>>> I don't think anything sounds too hard, the tricky bit is just
>>>>>ensuring
>>>>> you turn these into triple/graph patterns in a consistent manner which
>>>>> makes sense from the point of the user. We need to be making sure
>>>>>things
>>>>> group and nest in predictable and appropriate ways e.g. calling
>>>>>InGraph()
>>>>> creates all the triple patterns from it's builder in a single GRAPH
>>>>> pattern rather than into multiple GRAPH patterns if that makes sense
>>>>>
>>>>> Sounds like you have a good idea what you are doing so I will leave
>>>>>you
>>>>>to
>>>>> get on with it for the time being.
>>>>>
>>>>> One thought I did have is that it probably isn't necessary to have
>>>>> everything explicitly implement INodeFactory (even SparqlQuery), what
>>>>> would be simpler is just to have the builders that do need to generate
>>>>> nodes just extend NodeFactory (and thus get a pre-build implementation
>>>>>of
>>>>> INodeFactory) though given your above proposal it may turn out that
>>>>>making
>>>>> the builders be node factories is entirely unnecessary and you can
>>>>>just
>>>>> have a private NodeFactory for use within the builders.
>>>>>
>>>>> Rob
>>>>>
>>>>>>
>>>>>>Thanks,
>>>>>>Tom
>>>>>>
>>>>>>On Thu, Oct 18, 2012 at 7:04 PM, Rob Vesse <rv...@do...>
>>>>>>wrote:
>>>>>>> Hey Tom
>>>>>>>
>>>>>>> Can you send me a pull request for what you have so far on the
>>>>>>>fluent-query
>>>>>>> branch?
>>>>>>>
>>>>>>> I've finished up the refactor I was working on so have some more
>>>>>>>time
>>>>>>>to
>>>>>>> look at the fluent-query work if you'd like some help
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Rob
>>>>>>>
>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>--
>>>>>>>--
>>>>>>>-----
>>>>>>> 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_sfd2d_oct
>>>>>>> _______________________________________________
>>>>>>> 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_sfd2d_oct
>>>>>>_______________________________________________
>>>>>>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_sfd2d_oct
>>>>> _______________________________________________
>>>>> 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_sfd2d_oct
>>>>_______________________________________________
>>>>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_sfd2d_oct
>>> _______________________________________________
>>> 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_sfd2d_oct
>>_______________________________________________
>>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_sfd2d_oct
> _______________________________________________
> dotNetRDF-develop mailing list
> dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
|
|
From: Ron M. Z. <ro...@ze...> - 2012-10-27 00:15:13
|
Hi Rob. I just set up an ID. It's *ronmichael*. Thanks, Ron On Fri, Oct 26, 2012 at 12:37 PM, Rob Vesse <rv...@do...> wrote: > Hey All > > I'm expanding the list of authors in our NuSpec files so that as many of > us as possible are listed as authors as of the next release. I am missing > User IDs for Ron and Graham, if you guys have one can you let me know, if > you don't want to create one then I'll leave you out for the time being > > Rob – RobVesse > Tom – tpluscode > Kal – kal_ahmed > Ron - ? > Graham - ? > > Thanks, > > Rob > > > ------------------------------------------------------------------------------ > The Windows 8 Center > In partnership with Sourceforge > Your idea - your app - 30 days. Get started! > http://windows8center.sourceforge.net/ > what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > |
|
From: Ron M. Z. <ro...@ze...> - 2012-10-27 00:13:41
|
Sorry for taking so long to respond, Rob, it's been a hectic couple of
weeks. I haven't had a chance to look more at this but I'll try to
reproduce it again and see if I can make any headway soon.
On Thu, Sep 27, 2012 at 4:10 PM, Rob Vesse <rv...@do...> wrote:
> Hey Ron
>
> Did you ever get a chance to look into this more or do you want me to take
> this?
>
> Rob
>
> From: Ron Michael Zettlemoyer <ro...@ze...>
> Reply-To: dotNetRDF User Help and Support <
> dot...@li...>
> Date: Thursday, August 30, 2012 8:23 AM
> To: dotNetRDF User Help and Support <
> dot...@li...>
> Subject: [dotNetRDF-Support] Problem deleting data in a graph in Stardog
>
> I've dug around a little in the code but not been able to figure this out
> myself. This delete statement does not seem to work when talking to Stardog:
>
> DELETE { graph ?g { ?s ?p ?o } }
> WHERE
> {
> graph ?g {
> ?s ?p ?o.
> }
> filter (datatype(?o)=xsd:datetime)
> }
>
> I debugged using Fiddler and I can see dotNetRDF does a query to get the
> data that matches the where clause, and it initiates a transaction but then
> it simply ends the transaction without performing any changes. Which is odd
> since I thought I updated the Stardog portion of the code to not initiate a
> transaction if no change was going to be made but it may be getting called
> in some places that isn't checking for this yet.
>
> I'm not sure if my statement is just not correct or if it's a bug
> somewhere. Any thoughts?
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference Exclusive live event will cover all the
> ways today's security and threat landscape has changed and how IT managers
> can respond. Discussions will include endpoint security, mobile security
> and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________dotNetRDF-Support mailing list
> dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-support
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> dotNetRDF-develop mailing list
> dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>
>
|
|
From: Rob V. <rv...@do...> - 2012-10-26 21:27:19
|
As promised some time ago I have finally got round to starting to draft a document which describes my proposed design for a 2.0 once 1.0 is out the way. As previously stated I intend the next couple of releases (0.8, 0.9 and 1.0) to primarily be bug fixing and hardening releases. I then want to start thinking longer term which potentially involves some substantial refactors which is what this document attempts to outline. The design document is in Mercurial here: https://bitbucket.org/dotnetrdf/documentation/src/tip/Design/dotNetRDF%202.0 %20Design.md This is a work in progress and subject to change based on suggestions, my experiments with making these refactors etc. It is also by no means finished either, I haven't finished writing up all the ideas I have yet but what I have so far covers some of the most significant changes I'm thinking of Rob |
|
From: Rob V. <rv...@do...> - 2012-10-26 16:38:47
|
Hey All I'm expanding the list of authors in our NuSpec files so that as many of us as possible are listed as authors as of the next release. I am missing User IDs for Ron and Graham, if you guys have one can you let me know, if you don't want to create one then I'll leave you out for the time being Rob RobVesse Tom tpluscode Kal kal_ahmed Ron - ? Graham - ? Thanks, Rob |
|
From: Rob V. <rv...@do...> - 2012-10-25 23:49:00
|
Answer #1
Not all queries are required to have a Root Graph Pattern e.g.
DESCRIBE <http://example>
There was a bug in the ToString() form and SparqlFormatter.Format() form
of queries where the RootGraphPattern itself has a modifier, such a query
can never be generated by the parser (because you'll always have the outer
{ } to start the root graph pattern) so this case was never accounted for.
Fixed in default
Answer #2
The two forms you've shown are equivalent, they both generate identical
algebra. Any child graph pattern breaks the parent graph pattern and
requires that any subsequent triple patterns be inserted into a new child
graph pattern. This behavior is required to comply with the SPARQL
specification
correctly.
When we generate the string form we always generate the explicitly nested
form as this helps ensure queries round trip when serialized and re-parsed.
Hope this helps,
Rob
On 10/25/12 12:03 PM, "Tomasz Pluskiewicz" <tom...@gm...>
wrote:
>Hi
>
>Thanks for your reply. I think I get the idea. I have some two
>questions/issues about graph patterns:
>
>1. Why is it that new SparqlQuery has the RootGraphPattern null? It
>causes weird behaviour what I add an optional to a query first you
>would add the graph pattern as root. That produces an invalid query
>like
>
>SELECT * WHERE
>OPTIONAL { ... }
>
>Another problem there was that calling Where() after Optional() would
>add the additional triples to Optional instead the regular root
>pattern (because optional was added as root).
>
>For now I am making sure in the private QueryBuilder constructor that
>RootGraphPattern is initialized which helps.
>
>2. I added a test where I first add an optional graph pattern and then
>call Where which adds some more pattern to root. However adding triple
>patterns to root causes an extra nesting, because adding optional
>breaks the root graph pattern. Is that necessary? How would I produce
>a graph pattern like:
>
>{
> OPTIONAL {...}
> ?s ?p ?o
>}
>
>instead of the current result:
>
>{
> OPTIONAL {...}
> {
> ?s ?p ?o
> }
>}
>
>Thanks
>Tom
>
>On Sat, Oct 20, 2012 at 2:04 AM, Rob Vesse <rv...@do...> wrote:
>> Hey Tom
>>
>> You would use it to combine multiple triple pattern builders into graph
>> pattern builders in order to join and nest graph patterns together
>>
>> e.g.
>>
>> t1.Union(t2);
>>
>> Or:
>>
>> t1.Optional(t2);
>>
>> Or:
>>
>> t1.InGraph(new Uri("http://graph"));
>>
>> Or:
>>
>> t1.Minus(t2);
>>
>> The query builder would allow for either a triple pattern builder or a
>> graph pattern builder to set the where clause. Similarly most of the
>> above methods could either take a triple pattern builder or a graph
>> pattern builder.
>>
>> Sorry for being vague but it's Friday afternoon and I'm about to head
>>home
>> for the weekend having only flown back into the country on Monday (yay
>>jet
>> lag and over tiredness)
>>
>> Rob
>>
>> On 10/19/12 8:05 AM, "Tomasz Pluskiewicz" <tom...@gm...>
>> wrote:
>>
>>>Hi Rob
>>>
>>>I have been pondering your idea of IGraphPatternBuilder but I'm not
>>>sure I understand. Could you give an example of how you would design
>>>it's API?
>>>
>>>Thanks,
>>>Tom
>>>
>>>On Thu, Oct 18, 2012 at 9:31 PM, Rob Vesse <rv...@do...> wrote:
>>>> Hey Tom
>>>>
>>>> That all looks great, comments inline
>>>>
>>>> On 10/18/12 11:34 AM, "Tomasz Pluskiewicz"
>>>><tom...@gm...>
>>>> wrote:
>>>>
>>>>>Hi Rob
>>>>>
>>>>>Actually I have just today been preparing an email to agree on the
>>>>>fluent API. Here it goes.
>>>>>
>>>>>I have been thinking about the shape of the fluent query API and I
>>>>>would like to propose some changes.
>>>>>
>>>>>1. Currently there are quite a few overloads of the Where method. I
>>>>>think the API will be more usable if we left only a limited number,
>>>>>eg.
>>>>>
>>>>>* IQueryBuilder#Where(params ITriplePattern[] patterns)
>>>>>* IQueryBuilder#Where(params Triple[] triples) - not sure about
>>>>>triples here though
>>>>>* IQueryBuilder#Where(GraphPattern)
>>>>
>>>> Yes I agree having a simpler high level interface for building queries
>>>>is
>>>> better
>>>>
>>>>>
>>>>>Regarding the ast overload, what are the ways to create graph
>>>>>patterns? I mean I have seen the ToGraphPattern() method here and
>>>>>there. Which classes define such a method and what are differences in
>>>>>the graph patterns they produce?
>>>>
>>>> ToGraphPattern() is typically on algebra classes but it not reliable
>>>> because
>>>> some algebras (particularly those generated by optimization) cannot be
>>>> converted to graph patterns.
>>>>
>>>> Basically graph pattern wise you have the following:
>>>>
>>>> - Normal
>>>> - OPTIONAL
>>>> - GRAPH
>>>> - UNION
>>>> - SERVICE
>>>> - MINUS
>>>> - EXISTS/NOT EXISTS (within FILTER only)
>>>>
>>>>>
>>>>>2. I think the API should expose functionality but with least required
>>>>>use of the internal SPARQL types like the ITriplePattern,
>>>>>ISparqlExpression and such. I would not remove it of course to leave
>>>>>room for flexibility. For a day-to-day query building I think that
>>>>>maybe creating triple patterns should be split into subjects,
>>>>>predicates, object and possibly graphs (here this posin overlaps the
>>>>>above about GraphPatterns). As such it sould be possible to implement
>>>>>less code and at the same time give a greater flexibility for the user
>>>>>and remove the burden of creating instances of the SparqlVariable
>>>>>class and such. For example:
>>>>>
>>>>>var prefixes = new NamespaceMapped();
>>>>>// set up prefixes ...
>>>>>
>>>>>IQueryBuilder query = QueryBuilder.Select("person", "name");
>>>>>
>>>>>// I have just made this up, but could be useful although string name
>>>>>interfere with
>>>>>// QNames. Maybe add a struct QName?
>>>>>query.UsePrefixesFrom(prefixes);
>>>>>
>>>>>2a.
>>>>>// a more flexible form of triple pattern building
>>>>>// note the RdfType mehod. This way it would could provide some common
>>>>>// properties/classes and also leave an opening for users to create
>>>>>their own extension methods
>>>>>query.Where.Subject("person").RdfType().Object(new
>>>>>QName("foaf:Person"));
>>>>>
>>>>>2b.
>>>>>// alternatively there's a proposal without the QName struct/class,
>>>>>which I like more
>>>>>query.Where.Subject("person").RdfType().Object<IUriNode>("foaf:Person"
>>>>>))
>>>>>;
>>>>>
>>>>>2c.
>>>>>// here NodeMatchPattern for predicate with full Uri given and obejct
>>>>>as a VariablePattern
>>>>>query.Where.Subject("person").Predicate(new
>>>>>Uri("http://xmlns.com/foaf/0.1/name")).Object("name"));
>>>>>
>>>>>In terms of graphs, I think that maybe we could provide one more
>>>>>method to such ITripleVariable-producing chain, to select the
>>>>>appropriate named graph pattern
>>>>>
>>>>>2d.
>>>>>query.Where.Subject("person").Predicate(new
>>>>>Uri("http://xmlns.com/foaf/0.1/firstName")).Object("name")).InGraph(ne
>>>>>w
>>>>>Uri("http://uri/of/graph"));
>>>>>query.Where.Subject("person").Predicate(new
>>>>>Uri("http://xmlns.com/foaf/0.1/lastName")).Object("surname")).InGraph(
>>>>>ne
>>>>>w
>>>>>Uri("http://uri/of/graph"));
>>>>>query.Optional.Subject("person").Predicate<IUriNode>("foaf:mbox_sha1su
>>>>>m"
>>>>>).
>>>>>Object("emailSha1")).InGraph(new
>>>>>Uri("http://uri/with/contact/data"));
>>>>>
>>>>>All the above would produce:
>>>>>
>>>>>ad 2a/2b and 2c
>>>>>
>>>>>WHERE
>>>>>{
>>>>> ?person a foaf:Person .
>>>>> ?person foaf:name ?name .
>>>>>}
>>>>>
>>>>>ad 2d
>>>>>
>>>>>WHERE
>>>>>{
>>>>> # calling InGraph() with same parameter should
>>>>> # add triple pattern to same graph pattern, right?
>>>>
>>>> Yes that would make sense, implementing it might be slightly trickier
>>>>but
>>>> the notion is sound
>>>>
>>>> Perhaps InGraph() would turn a ITriplePatternBuilder into a
>>>> IGraphPatternBuilder and the user
>>>> would have the option of adding further triple/graph pattern builders
>>>>to
>>>> an existing one
>>>>
>>>>> GRAPH <http://uri/of/graph>
>>>>> {
>>>>> ?person foaf:firstName ?name
>>>>> ?person foaf:lastName ?surname
>>>>> }
>>>>> GRAPH <http://uri/with/contact/data>
>>>>> {
>>>>> OPTIONAL { ?person foaf:mbox_sha1sum ?name }
>>>>> }
>>>>>}
>>>>>
>>>>>Not how the OPTIONAL has API equivalent to WHERE
>>>>>
>>>>>3. I have also been thinking that a simmilar way could be used to
>>>>>create CONSTRUCT queries. However with the current static
>>>>>initialization of query builder I would suggest slightly modifying the
>>>>>above to reuse the same methods in both scenarios
>>>>>
>>>>>One way I find quite good could be using an Action<> delegate and
>>>>>introducing an ITriplePatternBuilder interface to actually build the
>>>>>triple patterns:
>>>>>
>>>>>var query = QueryBuilder.Construct(
>>>>> (ITriplePatternBuilder tp) =>
>>>>>tp.Subject("person").RdfType().Object<IUriNode>("ex:MyPersonClass")
>>>>>);
>>>>
>>>> I like this approach, it's clean and extensible
>>>>
>>>> I assume we'd have ITriplePatternBuilder, maybe IGraphPatternBuilder
>>>>and
>>>> likely a IExpressionBuilder ?
>>>>
>>>>>
>>>>>With this approach, the Where/Optional would change to:
>>>>>
>>>>>query.Where( tp =>
>>>>>tp.Subject("person").RdfType().Object<IUriNode>("foaf:Person")) );
>>>>>
>>>>>and internally bouth would look somewhat like:
>>>>>
>>>>>public IQueryBuilder Where(Action<ITriplePatternBuilder>
>>>>>buildTriplePatterns)
>>>>>{
>>>>> var builder = new TriplePatternBuilder(); //implementation internal
>>>>> buildTriplePatterns(builder);
>>>>> return Where(builder.TriplePatterns.ToArray());
>>>>>}
>>>>>
>>>>>I think this way we get a clean seperation of concerns, good
>>>>>testability and room for extensibility.
>>>>>
>>>>>4. Ask query is trivial. The SPARQL update could also use the proposed
>>>>>ITriplePatternBuilder I think
>>>>>
>>>>>5. Basic federated queries could be achived in a simmilar way the
>>>>>InGraph() method is used above for
>>>>>
>>>>>6. We need a method for the BIND keyword, eg.
>>>>>
>>>>>public IQueryBuilderBind(ISparqlExpression expression, string
>>>>>variableName) { ... }
>>>>
>>>> There could maybe just be a method on the ITriplePatternBuilder to
>>>>create
>>>> a BIND, possible also similar for FILTER and so forth
>>>>
>>>>>
>>>>>
>>>>>
>>>>>Oh well, there is much more, but we have enough to discuss just for
>>>>>now. Tell me what are your feelings about all the above. You are
>>>>>certainly more experienced with SPARQL so I would be greateful for
>>>>>your own ideas for this feature, which I'm sure you have :).
>>>>>
>>>>>Also, what do you think would be the greatest challenges here?
>>>>
>>>> I don't think anything sounds too hard, the tricky bit is just
>>>>ensuring
>>>> you turn these into triple/graph patterns in a consistent manner which
>>>> makes sense from the point of the user. We need to be making sure
>>>>things
>>>> group and nest in predictable and appropriate ways e.g. calling
>>>>InGraph()
>>>> creates all the triple patterns from it's builder in a single GRAPH
>>>> pattern rather than into multiple GRAPH patterns if that makes sense
>>>>
>>>> Sounds like you have a good idea what you are doing so I will leave
>>>>you
>>>>to
>>>> get on with it for the time being.
>>>>
>>>> One thought I did have is that it probably isn't necessary to have
>>>> everything explicitly implement INodeFactory (even SparqlQuery), what
>>>> would be simpler is just to have the builders that do need to generate
>>>> nodes just extend NodeFactory (and thus get a pre-build implementation
>>>>of
>>>> INodeFactory) though given your above proposal it may turn out that
>>>>making
>>>> the builders be node factories is entirely unnecessary and you can
>>>>just
>>>> have a private NodeFactory for use within the builders.
>>>>
>>>> Rob
>>>>
>>>>>
>>>>>Thanks,
>>>>>Tom
>>>>>
>>>>>On Thu, Oct 18, 2012 at 7:04 PM, Rob Vesse <rv...@do...>
>>>>>wrote:
>>>>>> Hey Tom
>>>>>>
>>>>>> Can you send me a pull request for what you have so far on the
>>>>>>fluent-query
>>>>>> branch?
>>>>>>
>>>>>> I've finished up the refactor I was working on so have some more
>>>>>>time
>>>>>>to
>>>>>> look at the fluent-query work if you'd like some help
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>--
>>>>>>--
>>>>>>-----
>>>>>> 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_sfd2d_oct
>>>>>> _______________________________________________
>>>>>> 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_sfd2d_oct
>>>>>_______________________________________________
>>>>>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_sfd2d_oct
>>>> _______________________________________________
>>>> 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_sfd2d_oct
>>>_______________________________________________
>>>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_sfd2d_oct
>> _______________________________________________
>> 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_sfd2d_oct
>_______________________________________________
>dotNetRDF-develop mailing list
>dot...@li...
>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
|
|
From: Tomasz P. <tom...@gm...> - 2012-10-25 19:04:07
|
Hi
Thanks for your reply. I think I get the idea. I have some two
questions/issues about graph patterns:
1. Why is it that new SparqlQuery has the RootGraphPattern null? It
causes weird behaviour what I add an optional to a query first you
would add the graph pattern as root. That produces an invalid query
like
SELECT * WHERE
OPTIONAL { ... }
Another problem there was that calling Where() after Optional() would
add the additional triples to Optional instead the regular root
pattern (because optional was added as root).
For now I am making sure in the private QueryBuilder constructor that
RootGraphPattern is initialized which helps.
2. I added a test where I first add an optional graph pattern and then
call Where which adds some more pattern to root. However adding triple
patterns to root causes an extra nesting, because adding optional
breaks the root graph pattern. Is that necessary? How would I produce
a graph pattern like:
{
OPTIONAL {...}
?s ?p ?o
}
instead of the current result:
{
OPTIONAL {...}
{
?s ?p ?o
}
}
Thanks
Tom
On Sat, Oct 20, 2012 at 2:04 AM, Rob Vesse <rv...@do...> wrote:
> Hey Tom
>
> You would use it to combine multiple triple pattern builders into graph
> pattern builders in order to join and nest graph patterns together
>
> e.g.
>
> t1.Union(t2);
>
> Or:
>
> t1.Optional(t2);
>
> Or:
>
> t1.InGraph(new Uri("http://graph"));
>
> Or:
>
> t1.Minus(t2);
>
> The query builder would allow for either a triple pattern builder or a
> graph pattern builder to set the where clause. Similarly most of the
> above methods could either take a triple pattern builder or a graph
> pattern builder.
>
> Sorry for being vague but it's Friday afternoon and I'm about to head home
> for the weekend having only flown back into the country on Monday (yay jet
> lag and over tiredness)
>
> Rob
>
> On 10/19/12 8:05 AM, "Tomasz Pluskiewicz" <tom...@gm...>
> wrote:
>
>>Hi Rob
>>
>>I have been pondering your idea of IGraphPatternBuilder but I'm not
>>sure I understand. Could you give an example of how you would design
>>it's API?
>>
>>Thanks,
>>Tom
>>
>>On Thu, Oct 18, 2012 at 9:31 PM, Rob Vesse <rv...@do...> wrote:
>>> Hey Tom
>>>
>>> That all looks great, comments inline
>>>
>>> On 10/18/12 11:34 AM, "Tomasz Pluskiewicz"
>>><tom...@gm...>
>>> wrote:
>>>
>>>>Hi Rob
>>>>
>>>>Actually I have just today been preparing an email to agree on the
>>>>fluent API. Here it goes.
>>>>
>>>>I have been thinking about the shape of the fluent query API and I
>>>>would like to propose some changes.
>>>>
>>>>1. Currently there are quite a few overloads of the Where method. I
>>>>think the API will be more usable if we left only a limited number,
>>>>eg.
>>>>
>>>>* IQueryBuilder#Where(params ITriplePattern[] patterns)
>>>>* IQueryBuilder#Where(params Triple[] triples) - not sure about
>>>>triples here though
>>>>* IQueryBuilder#Where(GraphPattern)
>>>
>>> Yes I agree having a simpler high level interface for building queries
>>>is
>>> better
>>>
>>>>
>>>>Regarding the ast overload, what are the ways to create graph
>>>>patterns? I mean I have seen the ToGraphPattern() method here and
>>>>there. Which classes define such a method and what are differences in
>>>>the graph patterns they produce?
>>>
>>> ToGraphPattern() is typically on algebra classes but it not reliable
>>> because
>>> some algebras (particularly those generated by optimization) cannot be
>>> converted to graph patterns.
>>>
>>> Basically graph pattern wise you have the following:
>>>
>>> - Normal
>>> - OPTIONAL
>>> - GRAPH
>>> - UNION
>>> - SERVICE
>>> - MINUS
>>> - EXISTS/NOT EXISTS (within FILTER only)
>>>
>>>>
>>>>2. I think the API should expose functionality but with least required
>>>>use of the internal SPARQL types like the ITriplePattern,
>>>>ISparqlExpression and such. I would not remove it of course to leave
>>>>room for flexibility. For a day-to-day query building I think that
>>>>maybe creating triple patterns should be split into subjects,
>>>>predicates, object and possibly graphs (here this posin overlaps the
>>>>above about GraphPatterns). As such it sould be possible to implement
>>>>less code and at the same time give a greater flexibility for the user
>>>>and remove the burden of creating instances of the SparqlVariable
>>>>class and such. For example:
>>>>
>>>>var prefixes = new NamespaceMapped();
>>>>// set up prefixes ...
>>>>
>>>>IQueryBuilder query = QueryBuilder.Select("person", "name");
>>>>
>>>>// I have just made this up, but could be useful although string name
>>>>interfere with
>>>>// QNames. Maybe add a struct QName?
>>>>query.UsePrefixesFrom(prefixes);
>>>>
>>>>2a.
>>>>// a more flexible form of triple pattern building
>>>>// note the RdfType mehod. This way it would could provide some common
>>>>// properties/classes and also leave an opening for users to create
>>>>their own extension methods
>>>>query.Where.Subject("person").RdfType().Object(new
>>>>QName("foaf:Person"));
>>>>
>>>>2b.
>>>>// alternatively there's a proposal without the QName struct/class,
>>>>which I like more
>>>>query.Where.Subject("person").RdfType().Object<IUriNode>("foaf:Person"))
>>>>;
>>>>
>>>>2c.
>>>>// here NodeMatchPattern for predicate with full Uri given and obejct
>>>>as a VariablePattern
>>>>query.Where.Subject("person").Predicate(new
>>>>Uri("http://xmlns.com/foaf/0.1/name")).Object("name"));
>>>>
>>>>In terms of graphs, I think that maybe we could provide one more
>>>>method to such ITripleVariable-producing chain, to select the
>>>>appropriate named graph pattern
>>>>
>>>>2d.
>>>>query.Where.Subject("person").Predicate(new
>>>>Uri("http://xmlns.com/foaf/0.1/firstName")).Object("name")).InGraph(new
>>>>Uri("http://uri/of/graph"));
>>>>query.Where.Subject("person").Predicate(new
>>>>Uri("http://xmlns.com/foaf/0.1/lastName")).Object("surname")).InGraph(ne
>>>>w
>>>>Uri("http://uri/of/graph"));
>>>>query.Optional.Subject("person").Predicate<IUriNode>("foaf:mbox_sha1sum"
>>>>).
>>>>Object("emailSha1")).InGraph(new
>>>>Uri("http://uri/with/contact/data"));
>>>>
>>>>All the above would produce:
>>>>
>>>>ad 2a/2b and 2c
>>>>
>>>>WHERE
>>>>{
>>>> ?person a foaf:Person .
>>>> ?person foaf:name ?name .
>>>>}
>>>>
>>>>ad 2d
>>>>
>>>>WHERE
>>>>{
>>>> # calling InGraph() with same parameter should
>>>> # add triple pattern to same graph pattern, right?
>>>
>>> Yes that would make sense, implementing it might be slightly trickier
>>>but
>>> the notion is sound
>>>
>>> Perhaps InGraph() would turn a ITriplePatternBuilder into a
>>> IGraphPatternBuilder and the user
>>> would have the option of adding further triple/graph pattern builders to
>>> an existing one
>>>
>>>> GRAPH <http://uri/of/graph>
>>>> {
>>>> ?person foaf:firstName ?name
>>>> ?person foaf:lastName ?surname
>>>> }
>>>> GRAPH <http://uri/with/contact/data>
>>>> {
>>>> OPTIONAL { ?person foaf:mbox_sha1sum ?name }
>>>> }
>>>>}
>>>>
>>>>Not how the OPTIONAL has API equivalent to WHERE
>>>>
>>>>3. I have also been thinking that a simmilar way could be used to
>>>>create CONSTRUCT queries. However with the current static
>>>>initialization of query builder I would suggest slightly modifying the
>>>>above to reuse the same methods in both scenarios
>>>>
>>>>One way I find quite good could be using an Action<> delegate and
>>>>introducing an ITriplePatternBuilder interface to actually build the
>>>>triple patterns:
>>>>
>>>>var query = QueryBuilder.Construct(
>>>> (ITriplePatternBuilder tp) =>
>>>>tp.Subject("person").RdfType().Object<IUriNode>("ex:MyPersonClass")
>>>>);
>>>
>>> I like this approach, it's clean and extensible
>>>
>>> I assume we'd have ITriplePatternBuilder, maybe IGraphPatternBuilder and
>>> likely a IExpressionBuilder ?
>>>
>>>>
>>>>With this approach, the Where/Optional would change to:
>>>>
>>>>query.Where( tp =>
>>>>tp.Subject("person").RdfType().Object<IUriNode>("foaf:Person")) );
>>>>
>>>>and internally bouth would look somewhat like:
>>>>
>>>>public IQueryBuilder Where(Action<ITriplePatternBuilder>
>>>>buildTriplePatterns)
>>>>{
>>>> var builder = new TriplePatternBuilder(); //implementation internal
>>>> buildTriplePatterns(builder);
>>>> return Where(builder.TriplePatterns.ToArray());
>>>>}
>>>>
>>>>I think this way we get a clean seperation of concerns, good
>>>>testability and room for extensibility.
>>>>
>>>>4. Ask query is trivial. The SPARQL update could also use the proposed
>>>>ITriplePatternBuilder I think
>>>>
>>>>5. Basic federated queries could be achived in a simmilar way the
>>>>InGraph() method is used above for
>>>>
>>>>6. We need a method for the BIND keyword, eg.
>>>>
>>>>public IQueryBuilderBind(ISparqlExpression expression, string
>>>>variableName) { ... }
>>>
>>> There could maybe just be a method on the ITriplePatternBuilder to
>>>create
>>> a BIND, possible also similar for FILTER and so forth
>>>
>>>>
>>>>
>>>>
>>>>Oh well, there is much more, but we have enough to discuss just for
>>>>now. Tell me what are your feelings about all the above. You are
>>>>certainly more experienced with SPARQL so I would be greateful for
>>>>your own ideas for this feature, which I'm sure you have :).
>>>>
>>>>Also, what do you think would be the greatest challenges here?
>>>
>>> I don't think anything sounds too hard, the tricky bit is just ensuring
>>> you turn these into triple/graph patterns in a consistent manner which
>>> makes sense from the point of the user. We need to be making sure things
>>> group and nest in predictable and appropriate ways e.g. calling
>>>InGraph()
>>> creates all the triple patterns from it's builder in a single GRAPH
>>> pattern rather than into multiple GRAPH patterns if that makes sense
>>>
>>> Sounds like you have a good idea what you are doing so I will leave you
>>>to
>>> get on with it for the time being.
>>>
>>> One thought I did have is that it probably isn't necessary to have
>>> everything explicitly implement INodeFactory (even SparqlQuery), what
>>> would be simpler is just to have the builders that do need to generate
>>> nodes just extend NodeFactory (and thus get a pre-build implementation
>>>of
>>> INodeFactory) though given your above proposal it may turn out that
>>>making
>>> the builders be node factories is entirely unnecessary and you can just
>>> have a private NodeFactory for use within the builders.
>>>
>>> Rob
>>>
>>>>
>>>>Thanks,
>>>>Tom
>>>>
>>>>On Thu, Oct 18, 2012 at 7:04 PM, Rob Vesse <rv...@do...> wrote:
>>>>> Hey Tom
>>>>>
>>>>> Can you send me a pull request for what you have so far on the
>>>>>fluent-query
>>>>> branch?
>>>>>
>>>>> I've finished up the refactor I was working on so have some more time
>>>>>to
>>>>> look at the fluent-query work if you'd like some help
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Rob
>>>>>
>>>>>
>>>>>-----------------------------------------------------------------------
>>>>>--
>>>>>-----
>>>>> 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_sfd2d_oct
>>>>> _______________________________________________
>>>>> 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_sfd2d_oct
>>>>_______________________________________________
>>>>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_sfd2d_oct
>>> _______________________________________________
>>> 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_sfd2d_oct
>>_______________________________________________
>>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_sfd2d_oct
> _______________________________________________
> dotNetRDF-develop mailing list
> dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
|
|
From: <tr...@do...> - 2012-10-22 22:34:37
|
<p>The following issue has been updated by Rob Vesse:</p>
<table border="0">
<tr>
<td width="90px" valign="top"><b>Title:</b></td>
<td>BIND in SPARQL query produces diffrent results</td>
</tr>
<tr>
<td><b>Project:</b></td>
<td>Core Library (dotNetRDF.dll)</td>
</tr>
<tr>
<td colspan="2"><b>Changes:</b></td>
</tr>
<tr>
<td colspan="2">
<ul>
<li>Status changed from "Confirmed" to "Completed"
</li>
<li>Affected Milestone changed from "0.7.2 Beta" to "0.7.1 Beta"
</li>
<li>Progress changed from "0.00 %" to "10,000.00 %"
</li>
</ul>
</td>
</tr>
</table>
<p>
More information on this issue can be found at
<a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=287" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=287</a></p>
<p style="text-align:center;font-size:8pt;padding:5px;">
If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options.
</p>
|
|
From: Rob V. <rv...@do...> - 2012-10-22 20:40:47
|
On 10/22/12 1:38 PM, "Rob Vesse" <rv...@do...> wrote:
>Ok
>
>Can you send me a pull request for the IIS Express related changes?
>
>Then I'll look at getting those projects fixed up as necessary
>
>Rob
>
>On 10/22/12 11:32 AM, "Tomasz Pluskiewicz" <tom...@gm...>
>wrote:
>
>>Thanks Rob, looks like vsmdi file was the cause.
>>
>>I still got quite a few tests failing for various reasons. One more
>>frequent reason comes from the WebDemos app, where ConfigurationLoader
>>calls Type.GetType("VDS.RDF.Configuration.AdoObjectFactory,
>>dotNetRDF.Data.Sql") but AdoObjectFactory is apparently not there
>>anymore and the config.ttl needs updating. There is the same issue
>>with BSBM and sp2b web apps.
>>
>>Speaking of the web applications. Have a look at my latest commit [1].
>>I have changed the projects to use the IIS Express I have mentioned
>>some time ago so you can see how it works for you. I have also updated
>>the test config template and the IIS servers should start on the same
>>port for everyone. If you have Visual Studio with SP1 installed IIS
>>Express you should be prompted to install IIS Express the first time
>>using Web Platform installer. It is an advantage over using full IIS,
>>which for one may be absent on developer machines and doesn't require
>>running VS with admin rights (actually is it currently necessary for
>>running the WebDemos and others?). Also to address your concerns you
>>have expressed the other time, IIS Express 7.5 is fully compatible
>>with IIS 7. I have used it for several projects during development and
>>there were never any issues.
>>
>>Regards,
>>Tom
>>
>>[1]
>>https://bitbucket.org/romanticweb/dotnetrdf/changeset/95a6fee1fd093ea49f9
>>f
>>c62c35c45df2634e0997
>>
>>On Mon, Oct 22, 2012 at 6:50 PM, Rob Vesse <rv...@do...> wrote:
>>> This sounds like your test environment may not be correct, looks like
>>>this
>>> is because I have the Tests.testrunconfig checked in but not the
>>> dotNetRDF.vsmdi which would be required for that testrunconfig file to
>>>be
>>> respected, should be corrected in the repo now. Please pull the latest
>>> from Trunk
>>>
>>> Other comments inline:
>>>
>>>
>>> On 10/22/12 2:36 AM, "Tomasz Pluskiewicz"
>>><tom...@gm...>
>>> wrote:
>>>
>>>>Hi Rob
>>>>
>>>>I wanted to make sure my working on the fluant API didn't intruduce
>>>>any regressions I ran the unit tests and many of them have failed on
>>>>opening the test files. Namely 436 tests have failed and most seem to
>>>>fail for simmilar reasons. It seems that in most of the test methods
>>>>you load files simmilarily to
>>>>
>>>>OntologyGraph g = new OntologyGraph();
>>>>FileLoader.Load(g, "InferenceTest.ttl");
>>>>
>>>>This tries to load the file from the bin/Debug folder but the testing
>>>>files reside inside bin\Debug\resources. Do you or anyone else also
>>>>get all those failed? It seem there is a need to fix that...
>>>
>>> The MSTest runner in Visual Studio does not run tests from the
>>>bin/Debug
>>> directory, rather it copies the DLL (and dependencies) to a new
>>>directory
>>> called TestResults/somedir usually created at the solution level.
>>>somedir
>>> is a generated name consisting usually of your machine name and a
>>> timestamp concatenated.
>>>
>>> It does not explicitly copy any Content resources for the project,
>>>this
>>>is
>>> done explicitly by configuring the Tests.testrunconfig file which can
>>>be
>>> found at the top level of the repository (or under Solution Items in
>>> Visual Studio). This is where it specifies that the resources
>>>directory
>>> be copied into the test directory, this copying copies directory
>>>contents
>>> rather than directories as-is hence the lack of "resources" in the
>>>paths
>>> in the actual tests.
>>>
>>> The missing vsdmi file meant the test config wasn't respected and so
>>>the
>>> resources weren't copied hence the errors you saw.
>>>
>>>
>>>>
>>>>Also taking VDS.RDF.Test.Ontology.OntologyTests as an example, you
>>>>load the file in every test method. You are but aware of the
>>>>[TestInitialize] attribute for method which runs before every test
>>>>method and can be used for preparing test environment?
>>>
>>> Yes but often the act of loading the model is part of the test not a
>>>setup
>>> activity.
>>>
>>>
>>>>Also having
>>>>looked at the aforementioned test class, why are there no Asserts in
>>>>the test methods?
>>>
>>> For some tests the test is simply that the code not thrown an exception
>>> (which would by definition cause a test failure)
>>>
>>> Rob
>>>
>>>>
>>>>Thanks
>>>>Tom
>>>
>>>
>>>
|
|
From: <tr...@do...> - 2012-10-22 20:30:27
|
<p>A new comment has been added to the following issue.</p>
<table border="0">
<tr>
<td width="90px" valign="top"><b>Title:</b></td>
<td>BIND in SPARQL query produces diffrent results</td>
</tr>
<tr>
<td><b>Project:</b></td>
<td>Core Library (dotNetRDF.dll)</td>
</tr>
<tr>
<td><b>Created By:</b></td>
<td>Tomasz Pluskiewicz</td>
</tr>
<tr>
<td><b>Date:</b></td>
<td>2012-10-22 09:29 PM</td>
</tr>
<tr>
<td><b>Comment:</b></td>
</tr>
<tr>
<td colspan="2"><p>
Apparently the current state of default branch has already introduced a fix for this issue in which case I'm closing</p></td>
</tr>
</table>
<p>
More information on this issue can be found at
<a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=287" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=287</a></p>
<p style="text-align:center;font-size:8pt;padding:5px;">
If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options.
</p>
|
48 messages has been excluded from this view by a project administrator.
