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: Rob V. <rv...@do...> - 2016-04-11 10:11:18
|
Folks, So you may have noticed that there has not been any releases in a long time, and again you may have not since there is little to no activity here at all. Personally I no longer have the drive, time nor the capability (due to unforeseen health issues) to continue making any efforts to take this project forward or even to continue to maintain it. Therefore since no one else is helping out with this the project is for all intents and purposes dead. As a good friend in the open source community is fond of saying: There are three ways to participate in open source -hope, sponsor, contribute Unfortunately this project has never succeeded in building a community of contributors and has mostly relied on hoping someone else will do the work for them. I acknowledge that this is as much my failure to build a viable community as it is a failure of the community to get more heavily involved but unfortunately it leaves us in a situation where my stepping down essentially kills the project. Sorry to be leaving like this, Rob |
|
From: <dot...@li...> - 2015-10-15 12:06:12
|
Send dotNetRDF-commits mailing list submissions to dot...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits or, via email, send a message with subject or body 'help' to dot...@li... You can reach the person managing the list at dot...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of dotNetRDF-commits digest..." Today's Topics: 1. commit/dotnetrdf: rvesse: Fix failing PCL tests when built in Release Mode (CORE-453) (Bitbucket) 2. commit/dotnetrdf: rvesse: Build Order fixes (Bitbucket) 3. commit/dotnetrdf: rvesse: Stablise File IDs so installer build is portable (TOOLS-456) (Bitbucket) 4. commit/dotnetrdf: 4 new changesets (Bitbucket) 5. commit/dotnetrdf: rvesse: Fix Release build of rdfServerGUI output path so installer builds in Release configuration (TOOLS-456) (Bitbucket) 6. commit/dotnetrdf: rvesse: Upgrade to latest Virtuoso 7 drivers (VIRT-359) (Bitbucket) 7. commit/dotnetrdf: rvesse: Properly update references to Virtuoso 7 assemblies (VIRT-359) (Bitbucket) 8. commit/dotnetrdf: rvesse: Correct hint paths for Virtuoso 7 driver (VIRT-359) (Bitbucket) 9. commit/dotnetrdf: 2 new changesets (Bitbucket) ---------------------------------------------------------------------- Message: 1 Date: Fri, 25 Sep 2015 14:19:46 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Fix failing PCL tests when built in Release Mode (CORE-453) To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/ab2cbe315c36/ Changeset: ab2cbe315c36 User: rvesse Date: 2015-09-25 14:19:10+00:00 Summary: Fix failing PCL tests when built in Release Mode (CORE-453) Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 2 Date: Fri, 25 Sep 2015 14:24:47 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Build Order fixes To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/8d78f5dec7f2/ Changeset: 8d78f5dec7f2 User: rvesse Date: 2015-09-25 14:23:24+00:00 Summary: Build Order fixes Affected #: 11 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 3 Date: Fri, 25 Sep 2015 15:46:12 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Stablise File IDs so installer build is portable (TOOLS-456) To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/d0de0cd17353/ Changeset: d0de0cd17353 User: rvesse Date: 2015-09-25 15:45:34+00:00 Summary: Stablise File IDs so installer build is portable (TOOLS-456) Affected #: 14 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 4 Date: Tue, 13 Oct 2015 14:36:43 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 4 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 4 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/7d034f174ce1/ Changeset: 7d034f174ce1 Branch: CORE-457 User: rvesse Date: 2015-10-13 13:57:22+00:00 Summary: Add tests to investigate GRAPH and OPTIONAL performance interaction (CORE-457) Affected #: 8 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/eb06ddce6cd9/ Changeset: eb06ddce6cd9 Branch: CORE-457 User: rvesse Date: 2015-10-13 14:24:43+00:00 Summary: Further tests related to CORE-457 Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e86f02e5f5c7/ Changeset: e86f02e5f5c7 Branch: CORE-457 User: rvesse Date: 2015-10-13 14:35:17+00:00 Summary: Close CORE-457 branch Affected #: 0 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e9c926788c49/ Changeset: e9c926788c49 User: rvesse Date: 2015-10-13 14:36:00+00:00 Summary: Merge extra tests from CORE-457 Affected #: 8 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 5 Date: Tue, 13 Oct 2015 14:52:03 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Fix Release build of rdfServerGUI output path so installer builds in Release configuration (TOOLS-456) To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/2025affa7986/ Changeset: 2025affa7986 User: rvesse Date: 2015-10-13 14:51:46+00:00 Summary: Fix Release build of rdfServerGUI output path so installer builds in Release configuration (TOOLS-456) Affected #: 11 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 6 Date: Thu, 15 Oct 2015 11:54:57 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Upgrade to latest Virtuoso 7 drivers (VIRT-359) To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/63822fbb57ed/ Changeset: 63822fbb57ed Branch: virtuoso-7 User: rvesse Date: 2015-10-15 11:54:24+00:00 Summary: Upgrade to latest Virtuoso 7 drivers (VIRT-359) Affected #: 925 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 7 Date: Thu, 15 Oct 2015 11:58:28 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Properly update references to Virtuoso 7 assemblies (VIRT-359) To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e53532f9dfd5/ Changeset: e53532f9dfd5 Branch: virtuoso-7 User: rvesse Date: 2015-10-15 11:58:06+00:00 Summary: Properly update references to Virtuoso 7 assemblies (VIRT-359) Affected #: 2 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 8 Date: Thu, 15 Oct 2015 12:02:47 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Correct hint paths for Virtuoso 7 driver (VIRT-359) To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/4ff9992e2b4d/ Changeset: 4ff9992e2b4d Branch: virtuoso-7 User: rvesse Date: 2015-10-15 12:02:29+00:00 Summary: Correct hint paths for Virtuoso 7 driver (VIRT-359) Affected #: 15 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 9 Date: Thu, 15 Oct 2015 12:06:02 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/ef40a583af0c/ Changeset: ef40a583af0c Branch: virtuoso-7 User: rvesse Date: 2015-10-15 12:05:15+00:00 Summary: Close the virtuoso-7 branch (VIRT-359) Affected #: 0 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e0920795e20d/ Changeset: e0920795e20d User: rvesse Date: 2015-10-15 12:05:47+00:00 Summary: Merge upgrades to Virtuoso 7 drivers (VIRT-359) Affected #: 33 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ ------------------------------------------------------------------------------ ------------------------------ _______________________________________________ dotNetRDF-commits mailing list dot...@li... https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits End of dotNetRDF-commits Digest, Vol 31, Issue 1 ************************************************ |
|
From: <dot...@li...> - 2015-09-25 14:16:38
|
Send dotNetRDF-commits mailing list submissions to dot...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits or, via email, send a message with subject or body 'help' to dot...@li... You can reach the person managing the list at dot...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of dotNetRDF-commits digest..." Today's Topics: 1. commit/dotnetrdf: 9 new changesets (Bitbucket) 2. commit/dotnetrdf: 9 new changesets (Bitbucket) 3. commit/dotnetrdf: MartinLercher: CORE-452 - symptomatic fix. (Bitbucket) 4. commit/dotnetrdf: 3 new changesets (Bitbucket) 5. commit/dotnetrdf: 2 new changesets (Bitbucket) 6. commit/dotnetrdf: rvesse: Fix bug in packaging that was causing outdated installer to be distributed (Bitbucket) 7. commit/dotnetrdf: 5 new changesets (Bitbucket) 8. commit/dotnetrdf: 4 new changesets (Bitbucket) ---------------------------------------------------------------------- Message: 1 Date: Fri, 10 Jul 2015 10:45:17 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 9 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 9 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/ee9fcd4b22d8/ Changeset: ee9fcd4b22d8 Branch: 1.9 User: rvesse Date: 2015-07-10 09:43:45+00:00 Summary: Updated references Affected #: 6 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/94a727f072cb/ Changeset: 94a727f072cb User: rvesse Date: 2015-07-10 09:55:27+00:00 Summary: Use FastVirtualNodeComprarer in various additional places (CORE-449, CORE-450, CORE-451) Affected #: 8 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/81d177927312/ Changeset: 81d177927312 User: rvesse Date: 2015-07-10 10:02:48+00:00 Summary: Allow endpoint requests to be customised in more detail (CORE-448) Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/665a0e801486/ Changeset: 665a0e801486 User: rvesse Date: 2015-07-10 10:15:59+00:00 Summary: Fix but with AllegroGraph needing old NTriples MIME Type to accept data save requests (CORE-447) Affected #: 8 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/f395f90280f9/ Changeset: f395f90280f9 User: rvesse Date: 2015-07-10 10:17:29+00:00 Summary: Fix AllegroGraphConnector portable builds (CORE-447) Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/5ba08d7373df/ Changeset: 5ba08d7373df Branch: CORE-446 User: rvesse Date: 2015-07-10 10:40:46+00:00 Summary: Unit tests and fixes for SPARQL Query Parser strictness bug (CORE-446) Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e8961278069e/ Changeset: e8961278069e Branch: CORE-446 User: rvesse Date: 2015-07-10 10:41:39+00:00 Summary: Note CORE-446 fix in Change Log Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/618a36a25d23/ Changeset: 618a36a25d23 User: rvesse Date: 2015-07-10 10:42:06+00:00 Summary: Merge CORE-446 fixes Affected #: 3 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/212b1aae3ccd/ Changeset: 212b1aae3ccd Branch: 1.9 User: rvesse Date: 2015-07-10 10:44:27+00:00 Summary: Merge 1.9 heads Affected #: 6 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 2 Date: Fri, 10 Jul 2015 14:14:46 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 9 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 9 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/72bb7a04bdf5/ Changeset: 72bb7a04bdf5 Branch: CORE-443 User: rvesse Date: 2015-07-10 13:15:03+00:00 Summary: Prep work for Stardog 3.x support (CORE-443) Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/a1791a024471/ Changeset: a1791a024471 Branch: CORE-443 User: rvesse Date: 2015-07-10 13:20:25+00:00 Summary: Prep work for Stardog 3.x support (CORE-443) Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/2cd98e553747/ Changeset: 2cd98e553747 Branch: CORE-443 User: rvesse Date: 2015-07-10 13:29:18+00:00 Summary: Prep work for Stardog 3.x support (CORE-443) Affected #: 13 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/78823e12bee4/ Changeset: 78823e12bee4 Branch: CORE-443 User: rvesse Date: 2015-07-10 13:38:28+00:00 Summary: Minor tweaks to Stardog tests Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/0b8c42c31f8a/ Changeset: 0b8c42c31f8a Branch: CORE-443 User: rvesse Date: 2015-07-10 13:41:33+00:00 Summary: Additional tests for Stardog 3 (CORE-443) Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/eee0ee408069/ Changeset: eee0ee408069 Branch: CORE-443 User: rvesse Date: 2015-07-10 13:45:00+00:00 Summary: Note Stardog 3.x support in Change Log (CORE-443) Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/06801cf8165e/ Changeset: 06801cf8165e User: rvesse Date: 2015-07-10 13:55:09+00:00 Summary: Merge Stardog 3.x support (CORE-443) Affected #: 17 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/462fefcd0450/ Changeset: 462fefcd0450 User: rvesse Date: 2015-07-10 14:02:22+00:00 Summary: Minor improvements Affected #: 19 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/2ba8bf5b94ad/ Changeset: 2ba8bf5b94ad User: rvesse Date: 2015-07-10 14:14:13+00:00 Summary: Tweaks to build file to make NuGet packaging quicker Affected #: 3 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 3 Date: Fri, 24 Jul 2015 10:48:01 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: MartinLercher: CORE-452 - symptomatic fix. To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/d3b1179f4dd4/ Changeset: d3b1179f4dd4 User: MartinLercher Date: 2015-07-10 18:24:26+00:00 Summary: CORE-452 - symptomatic fix. Affected #: 3 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 4 Date: Fri, 24 Jul 2015 11:06:46 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 3 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 3 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e7970f3feef9/ Changeset: e7970f3feef9 User: rvesse Date: 2015-07-24 10:57:30+00:00 Summary: Prepare for 1.0.9 release Affected #: 32 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/178b30711565/ Changeset: 178b30711565 User: rvesse Date: 2015-07-24 11:03:18+00:00 Summary: Fix bad reference Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/24f93f6c5968/ Changeset: 24f93f6c5968 User: rvesse Date: 2015-07-24 11:06:09+00:00 Summary: Added tag 1.0.9, 109 for changeset 178b30711565 Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 5 Date: Fri, 11 Sep 2015 14:36:33 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/4487f4826fa1/ Changeset: 4487f4826fa1 Branch: 1.9 User: rvesse Date: 2015-09-11 14:20:54+00:00 Summary: Start working on SPARQL IO Core library Affected #: 23 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/48b7597ae6e8/ Changeset: 48b7597ae6e8 Branch: 1.9 User: rvesse Date: 2015-09-11 14:35:56+00:00 Summary: Some minor changes to SPARQL IO Core Affected #: 2 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 6 Date: Tue, 22 Sep 2015 09:00:03 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Fix bug in packaging that was causing outdated installer to be distributed To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/c90ccf3ad462/ Changeset: c90ccf3ad462 User: rvesse Date: 2015-09-22 08:59:47+00:00 Summary: Fix bug in packaging that was causing outdated installer to be distributed Affected #: 2 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 7 Date: Fri, 25 Sep 2015 11:18:13 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 5 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 5 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e61f6803d123/ Changeset: e61f6803d123 User: rvesse Date: 2015-09-25 10:37:56+00:00 Summary: Disable HTTP Keep Alive by default (CORE-454) Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/8a661d166ef3/ Changeset: 8a661d166ef3 User: rvesse Date: 2015-09-25 10:46:59+00:00 Summary: Disable HTTP Keep Alive by default (CORE-454) Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/be95f908241a/ Changeset: be95f908241a User: rvesse Date: 2015-09-25 11:01:41+00:00 Summary: Add failing test for CORE-453 Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/bf97eb271b42/ Changeset: bf97eb271b42 User: rvesse Date: 2015-09-25 11:13:35+00:00 Summary: Fix bug with inconsistent compression to XML entities in RdfXmlWriter (CORE-453) Affected #: 12 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/47c215f2bcac/ Changeset: 47c215f2bcac User: rvesse Date: 2015-09-25 11:16:02+00:00 Summary: Note fixes for CORE-453 and CORE-454 in Change Log Affected #: 2 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 8 Date: Fri, 25 Sep 2015 14:16:27 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 4 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 4 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/5b9dce302a5c/ Changeset: 5b9dce302a5c Branch: TOOLS-456 User: rvesse Date: 2015-09-25 14:06:08+00:00 Summary: Include Start Menu Shortcuts in WiX Installer (TOOLS-456) Affected #: 11 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/f2edd58a6d89/ Changeset: f2edd58a6d89 Branch: TOOLS-456 User: rvesse Date: 2015-09-25 14:10:21+00:00 Summary: Add missing shortcuts for rdfServer (TOOLS-456) Affected #: 12 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/3824ed43aed0/ Changeset: 3824ed43aed0 Branch: TOOLS-456 User: rvesse Date: 2015-09-25 14:11:04+00:00 Summary: Update Change Log with TOOLS-455/TOOLS-456 fixes Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/8fe2b5022fae/ Changeset: 8fe2b5022fae User: rvesse Date: 2015-09-25 14:11:36+00:00 Summary: Merge in TOOLS-456 fixes Affected #: 12 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ ------------------------------------------------------------------------------ ------------------------------ _______________________________________________ dotNetRDF-commits mailing list dot...@li... https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits End of dotNetRDF-commits Digest, Vol 30, Issue 1 ************************************************ |
|
From: Rob V. <rv...@do...> - 2015-07-13 21:53:07
|
The build is available now It is actually 1.0.9-prerelease02 because I had some packaging issues with 01 but should be available for you to try out if you wish Rob From: "Nagaraju, Indresh" <Ind...@Ho...> Reply-To: dotNetRDF Developer Discussion and Feature Request <dot...@li...> Date: Monday, 13 July 2015 15:36 To: 'dotNetRDF Developer Discussion and Feature Request' <dot...@li...> Subject: Re: [dotNetRDF-Develop] Stardog 2.2.4 to 3.0 incompatibility > Thanks Rob. We will wait for the prerelease build. > > > From: Rob Vesse [mailto:rv...@do...] > Sent: Friday, July 10, 2015 7:20 PM > To: dotNetRDF Developer Discussion and Feature Request > Subject: Re: [dotNetRDF-Develop] Stardog 2.2.4 to 3.0 incompatibility > > > Indresh > > > > Finally had time to look at this and found that at least with the more recent > versions of Stardog 3 (specifically 3.1.2) this just works out of the box and > I can't reproduce the issue > > > > I made a few slight tweaks for Stardog 3.x support (since you now can't > control reasoning mode at the connection level) but other than that I didn't > have to do anything special > > > > There will be a dotNetRDF 1.0.9-prerelease01 build available on NuGet shortly > if you would like to test against that and confirm whether you still see the > problem > > > > Thanks, > > > > Rob > > > > From: Rob Vesse <rv...@do...> > Reply-To: dotNetRDF Developer Discussion and Feature Request > <dot...@li...> > Date: Tuesday, 7 April 2015 10:08 > To: dotNetRDF Developer Discussion and Feature Request > <dot...@li...> > Subject: Re: [dotNetRDF-Develop] Stardog 2.2.4 to 3.0 incompatibility > > >> >> It is likely a change in the Stardog APIs from 2.x to 3.x that is causing the >> issue >> >> >> >> I personally haven't even downloaded Stardog 3.x yet so have no idea what >> might be causing the issue. One of our other developers has usually handled >> updating the Stardog connectivity more recently but am not sure if he is >> still actively doing this. >> >> >> >> My guess from what you've described is that the way we determine if a graph >> with that name already exists no longer returns an accurate answer for >> Stardog 3.x leading to the spurious clear request. >> >> >> >> Likely this will get fixed for the next release but we can't give you a time >> frame for the fix. Filed as CORE-443 >> (http://dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=443) >> >> >> >> Rob >> >> >> >> From: "Nagaraju, Indresh" <Ind...@Ho...> >> Reply-To: dotNetRDF Developer Discussion and Feature Request >> <dot...@li...> >> Date: Monday, 6 April 2015 07:25 >> To: "dot...@li..." >> <dot...@li...> >> Subject: [dotNetRDF-Develop] Stardog 2.2.4 to 3.0 incompatibility >> >> >>> >>> Hi, >>> >>> We were using the below shown code to add a graph into Stardog (version >>> 2.2.4). The dotNetRdf version used here is 1.0.6. This was working fine and >>> we were able to add the graph. >>> >>> using (StardogConnector stardogServer = >>> newStardogConnector("http://localhost:5820", databaseName, username, >>> password)) >>> { >>> IGraph graph = newGraph(); >>> graph.BaseUri = newUri(graphName); >>> >>> var configuration = >>> newStreamReader(@"C:\data\test.ttl").ReadToEnd(); >>> graph.LoadFromString(configuration); >>> >>> // Save to Stardog >>> stardogServer.SaveGraph(graph); >>> } >>> >>> Now we have upgraded Stardog to version 3.0 and tried to use the same code >>> to add the graph. We are getting an error - Unable to save a Named Graph to >>> the Store as this requires deleting any existing Named Graph with this name >>> which failed, see inner exception for more detail. >>> >>> Here are the list of things that we tried to resolve the issue: >>> >>> · Tried with upgrading to latest dotNetRdf available (1.0.8) with no >>> luck in getting this work >>> >>> >>> >>> · Found out that for Stardog 2.2.4 a graph add request was going >>> while for Stardog 3.0 a graph clear request is been sent in both the >>> versions of dotNetRdf (1.0.6 and 1.0.8) >>> >>> >>> Request generated for Stardog 2.2.4: >>> >>> POST http://localhost:5820/testdb/82bbd2f0-5de9-492b-8615-8b5c43269618/add >>> HTTP/1.1 >>> Accept: */* >>> SD-Connection-String: >>> Content-Type: application/x-trig >>> Authorization: Basic YWRtaW46YWRtaW4= >>> Host: localhost:5820 >>> Content-Length: 53102 >>> Expect: 100-continue >>> >>> <http://www.example.com> { >>> ... >>> } >>> >>> >>> >>> Request generated for Stardog 3.0: >>> >>> POST >>> http://localhost.:5820/testdb/34204d26-9209-46f7-b2db-0f901b0fa3e6/clear/?gr >>> aph-uri=http%3a%2f%2fwww.example.com& HTTP/1.1 >>> Accept: */* >>> SD-Connection-String: >>> Content-Type: application/x-www-form-urlencoded >>> Authorization: Basic YWRtaW46YWRtaW4= >>> Host: localhost.:5820 >>> >>> >>> >>> · Made sure that there is no graph existing already in the database >>> with this name. >>> >>> >>> · Found that this error comes when graph.BaseUri is not null. We >>> forced the BaseUri to be null and tried, this resulted in an add graph >>> request, but received an error - HTTP/1.1 406 Not Acceptable >>> >>> >>> · Same code works fine even now when used with 2.2.4 version of >>> Stardog. >>> >>> >>> >>> · Contacted Stardog team for help and they mentioned that the issue >>> is with the client library that we are using to connect to it (i.e. >>> dotNetRdf). >>> >>> >>> >>> >>> Could you let us know what we are missing here and if this is a defect, >>> could this be part of next version of dotNetRdf? >>> >>> Regards, >>> Indresh >>> ---------------------------------------------------------------------------- >>> -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your >>> own process in accordance with the BPMN 2 standard Learn Process modeling >>> best practices with Bonita BPM through live exercises >>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ >>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF______ >>> _________________________________________ dotNetRDF-develop mailing list >>> dot...@li...https://lists.sourceforge.net/lists/l >>> istinfo/dotnetrdf-develop >> ----------------------------------------------------------------------------- >> - BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your >> own process in accordance with the BPMN 2 standard Learn Process modeling >> best practices with Bonita BPM through live exercises >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF_______ >> ________________________________________ dotNetRDF-develop mailing list >> dot...@li... >> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions > provide you with the tools and support that you need to offload your IT needs > and focus on growing your business. Configured For All Businesses. Start Your > Cloud Today. > https://www.gigenetcloud.com/_______________________________________________ > dotNetRDF-develop mailing list dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop |
|
From: Nagaraju, I. <Ind...@Ho...> - 2015-07-13 13:37:57
|
Thanks Rob. We will wait for the prerelease build. From: Rob Vesse [mailto:rv...@do...] Sent: Friday, July 10, 2015 7:20 PM To: dotNetRDF Developer Discussion and Feature Request Subject: Re: [dotNetRDF-Develop] Stardog 2.2.4 to 3.0 incompatibility Indresh Finally had time to look at this and found that at least with the more recent versions of Stardog 3 (specifically 3.1.2) this just works out of the box and I can't reproduce the issue I made a few slight tweaks for Stardog 3.x support (since you now can't control reasoning mode at the connection level) but other than that I didn't have to do anything special There will be a dotNetRDF 1.0.9-prerelease01 build available on NuGet shortly if you would like to test against that and confirm whether you still see the problem Thanks, Rob From: Rob Vesse <rv...@do...<mailto:rv...@do...>> Reply-To: dotNetRDF Developer Discussion and Feature Request <dot...@li...<mailto:dot...@li...>> Date: Tuesday, 7 April 2015 10:08 To: dotNetRDF Developer Discussion and Feature Request <dot...@li...<mailto:dot...@li...>> Subject: Re: [dotNetRDF-Develop] Stardog 2.2.4 to 3.0 incompatibility It is likely a change in the Stardog APIs from 2.x to 3.x that is causing the issue I personally haven't even downloaded Stardog 3.x yet so have no idea what might be causing the issue. One of our other developers has usually handled updating the Stardog connectivity more recently but am not sure if he is still actively doing this. My guess from what you've described is that the way we determine if a graph with that name already exists no longer returns an accurate answer for Stardog 3.x leading to the spurious clear request. Likely this will get fixed for the next release but we can't give you a time frame for the fix. Filed as CORE-443 (http://dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=443) Rob From: "Nagaraju, Indresh" <Ind...@Ho...<mailto:Ind...@Ho...>> Reply-To: dotNetRDF Developer Discussion and Feature Request <dot...@li...<mailto:dot...@li...>> Date: Monday, 6 April 2015 07:25 To: "dot...@li...<mailto:dot...@li...>" <dot...@li...<mailto:dot...@li...>> Subject: [dotNetRDF-Develop] Stardog 2.2.4 to 3.0 incompatibility Hi, We were using the below shown code to add a graph into Stardog (version 2.2.4). The dotNetRdf version used here is 1.0.6. This was working fine and we were able to add the graph. using (StardogConnector stardogServer = new StardogConnector("http://localhost:5820", databaseName, username, password)) { IGraph graph = newGraph(); graph.BaseUri = new Uri(graphName); var configuration = new StreamReader(@"C:\data\test.ttl").ReadToEnd(); graph.LoadFromString(configuration); // Save to Stardog stardogServer.SaveGraph(graph); } Now we have upgraded Stardog to version 3.0 and tried to use the same code to add the graph. We are getting an error - Unable to save a Named Graph to the Store as this requires deleting any existing Named Graph with this name which failed, see inner exception for more detail. Here are the list of things that we tried to resolve the issue: · Tried with upgrading to latest dotNetRdf available (1.0.8) with no luck in getting this work · Found out that for Stardog 2.2.4 a graph add request was going while for Stardog 3.0 a graph clear request is been sent in both the versions of dotNetRdf (1.0.6 and 1.0.8) Request generated for Stardog 2.2.4: POST http://localhost:5820/testdb/82bbd2f0-5de9-492b-8615-8b5c43269618/add HTTP/1.1 Accept: */* SD-Connection-String: Content-Type: application/x-trig Authorization: Basic YWRtaW46YWRtaW4= Host: localhost:5820 Content-Length: 53102 Expect: 100-continue <http://www.example.com> { ... } Request generated for Stardog 3.0: POST http://localhost.:5820/testdb/34204d26-9209-46f7-b2db-0f901b0fa3e6/clear/?graph-uri=http%3a%2f%2fwww.example.com& HTTP/1.1 Accept: */* SD-Connection-String: Content-Type: application/x-www-form-urlencoded Authorization: Basic YWRtaW46YWRtaW4= Host: localhost.:5820 · Made sure that there is no graph existing already in the database with this name. · Found that this error comes when graph.BaseUri is not null. We forced the BaseUri to be null and tried, this resulted in an add graph request, but received an error - HTTP/1.1 406 Not Acceptable · Same code works fine even now when used with 2.2.4 version of Stardog. · Contacted Stardog team for help and they mentioned that the issue is with the client library that we are using to connect to it (i.e. dotNetRdf). Could you let us know what we are missing here and if this is a defect, could this be part of next version of dotNetRdf? Regards, Indresh ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF_______________________________________________ dotNetRDF-develop mailing list dot...@li...<mailto:dot...@li...>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF_______________________________________________ dotNetRDF-develop mailing list dot...@li...<mailto:dot...@li...> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop |
|
From: Rob V. <rv...@do...> - 2015-07-10 13:50:32
|
Indresh Finally had time to look at this and found that at least with the more recent versions of Stardog 3 (specifically 3.1.2) this just works out of the box and I can't reproduce the issue I made a few slight tweaks for Stardog 3.x support (since you now can't control reasoning mode at the connection level) but other than that I didn't have to do anything special There will be a dotNetRDF 1.0.9-prerelease01 build available on NuGet shortly if you would like to test against that and confirm whether you still see the problem Thanks, Rob From: Rob Vesse <rv...@do...> Reply-To: dotNetRDF Developer Discussion and Feature Request <dot...@li...> Date: Tuesday, 7 April 2015 10:08 To: dotNetRDF Developer Discussion and Feature Request <dot...@li...> Subject: Re: [dotNetRDF-Develop] Stardog 2.2.4 to 3.0 incompatibility > It is likely a change in the Stardog APIs from 2.x to 3.x that is causing the > issue > > I personally haven't even downloaded Stardog 3.x yet so have no idea what > might be causing the issue. One of our other developers has usually handled > updating the Stardog connectivity more recently but am not sure if he is still > actively doing this. > > My guess from what you've described is that the way we determine if a graph > with that name already exists no longer returns an accurate answer for Stardog > 3.x leading to the spurious clear request. > > Likely this will get fixed for the next release but we can't give you a time > frame for the fix. Filed as CORE-443 > (http://dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=443) > > Rob > > From: "Nagaraju, Indresh" <Ind...@Ho...> > Reply-To: dotNetRDF Developer Discussion and Feature Request > <dot...@li...> > Date: Monday, 6 April 2015 07:25 > To: "dot...@li..." > <dot...@li...> > Subject: [dotNetRDF-Develop] Stardog 2.2.4 to 3.0 incompatibility > >> Hi, >> >> We were using the below shown code to add a graph into Stardog (version >> 2.2.4). The dotNetRdf version used here is 1.0.6. This was working fine and >> we were able to add the graph. >> >> using (StardogConnector stardogServer = new >> StardogConnector("http://localhost:5820", databaseName, username, password)) >> { >> IGraph graph = newGraph(); >> graph.BaseUri = new Uri(graphName); >> >> var configuration = new >> StreamReader(@"C:\data\test.ttl").ReadToEnd(); >> graph.LoadFromString(configuration); >> >> // Save to Stardog >> stardogServer.SaveGraph(graph); >> } >> >> Now we have upgraded Stardog to version 3.0 and tried to use the same code to >> add the graph. We are getting an error - Unable to save a Named Graph to the >> Store as this requires deleting any existing Named Graph with this name which >> failed, see inner exception for more detail. >> >> Here are the list of things that we tried to resolve the issue: >> >> · Tried with upgrading to latest dotNetRdf available (1.0.8) with no >> luck in getting this work >> >> >> >> · Found out that for Stardog 2.2.4 a graph add request was going while >> for Stardog 3.0 a graph clear request is been sent in both the versions of >> dotNetRdf (1.0.6 and 1.0.8) >> >> >> Request generated for Stardog 2.2.4: >> >> POST http://localhost:5820/testdb/82bbd2f0-5de9-492b-8615-8b5c43269618/add >> HTTP/1.1 >> Accept: */* >> SD-Connection-String: >> Content-Type: application/x-trig >> Authorization: Basic YWRtaW46YWRtaW4= >> Host: localhost:5820 >> Content-Length: 53102 >> Expect: 100-continue >> >> <http://www.example.com> { >> ... >> } >> >> >> >> Request generated for Stardog 3.0: >> >> POST >> http://localhost.:5820/testdb/34204d26-9209-46f7-b2db-0f901b0fa3e6/clear/?gra >> ph-uri=http%3a%2f%2fwww.example.com& HTTP/1.1 >> Accept: */* >> SD-Connection-String: >> Content-Type: application/x-www-form-urlencoded >> Authorization: Basic YWRtaW46YWRtaW4= >> Host: localhost.:5820 >> >> >> >> · Made sure that there is no graph existing already in the database >> with this name. >> >> >> · Found that this error comes when graph.BaseUri is not null. We >> forced the BaseUri to be null and tried, this resulted in an add graph >> request, but received an error - HTTP/1.1 406 Not Acceptable >> >> >> · Same code works fine even now when used with 2.2.4 version of >> Stardog. >> >> >> >> · Contacted Stardog team for help and they mentioned that the issue is >> with the client library that we are using to connect to it (i.e. dotNetRdf). >> >> >> >> >> Could you let us know what we are missing here and if this is a defect, could >> this be part of next version of dotNetRdf? >> >> Regards, >> Indresh >> ----------------------------------------------------------------------------- >> - BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your >> own process in accordance with the BPMN 2 standard Learn Process modeling >> best practices with Bonita BPM through live exercises >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF_______ >> ________________________________________ dotNetRDF-develop mailing list >> dot...@li...https://lists.sourceforge.net/lists/li >> stinfo/dotnetrdf-develop > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own > process in accordance with the BPMN 2 standard Learn Process modeling best > practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF________ > _______________________________________ dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop |
|
From: <dot...@li...> - 2015-07-06 11:15:39
|
Send dotNetRDF-commits mailing list submissions to dot...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits or, via email, send a message with subject or body 'help' to dot...@li... You can reach the person managing the list at dot...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of dotNetRDF-commits digest..." Today's Topics: 1. commit/dotnetrdf: 2 new changesets (Bitbucket) 2. commit/dotnetrdf: 64 new changesets (Bitbucket) 3. commit/dotnetrdf: rvesse: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #40) (Bitbucket) 4. commit/dotnetrdf: 4 new changesets (Bitbucket) 5. commit/dotnetrdf: rvesse: Merged in MartinLercher/dotnetrdf (pull request #41) (Bitbucket) ---------------------------------------------------------------------- Message: 1 Date: Mon, 01 Jun 2015 10:57:51 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/c49ef7da9fba/ Changeset: c49ef7da9fba User: rvesse Date: 2015-06-01 10:52:30+00:00 Summary: Fix a bug in rdfServer where unsupported configurations were silently ignored Affected #: 15 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/df95e1283cec/ Changeset: df95e1283cec User: rvesse Date: 2015-06-01 10:57:37+00:00 Summary: Note rdfServer fixes in Change Log Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 2 Date: Mon, 06 Jul 2015 08:38:56 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 64 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 64 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/9a9e901b432e/ Changeset: 9a9e901b432e User: magicmoux Date: 2015-03-05 13:23:37+00:00 Summary: Some public opening of the Sparql Query and Pattern APIs Added a ActiveGraph cascaded property to the GraphPattern class Added some helper extension methods to work with GraphPatterns Affected #: 4 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/a01a7ad6c69b/ Changeset: a01a7ad6c69b User: magicmoux Date: 2015-03-05 15:29:48+00:00 Summary: README.md edited online with Bitbucket Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/8ddc5dbb6758/ Changeset: 8ddc5dbb6758 User: magicmoux Date: 2015-03-13 15:49:51+00:00 Summary: Merged dotnetrdf/dotnetrdf into default Affected #: 23 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/cf4adadcb3fe/ Changeset: cf4adadcb3fe User: magicmoux Date: 2015-03-25 15:31:01+00:00 Summary: Merged dotnetrdf/dotnetrdf into default Affected #: 37 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/bd729201c13d/ Changeset: bd729201c13d User: magicmoux Date: 2015-03-05 14:59:12+00:00 Summary: Refactoring for global library organisation Affected #: 250 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/95cc5da21307/ Changeset: 95cc5da21307 User: magicmoux Date: 2015-03-05 15:02:08+00:00 Summary: Adding the base class and first component for the SPARQL evaluation chain Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/d2e6bfc24b74/ Changeset: d2e6bfc24b74 User: magicmoux Date: 2015-03-06 17:02:07+00:00 Summary: Toward a buildable Library Affected #: 72 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/c6288ae38f77/ Changeset: c6288ae38f77 User: magicmoux Date: 2015-03-06 17:02:31+00:00 Summary: Toward a buildable Library Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/eb1e703ca0b9/ Changeset: eb1e703ca0b9 User: magicmoux Date: 2015-03-06 17:06:40+00:00 Summary: Refactored the SPARQL/SPIN command API into a wrapping commands classes Refactored the SPARQL rewriting process into a chain of startegy components First test included as the TransactionalSupportStrategy Affected #: 7 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/86e0c239f5aa/ Changeset: 86e0c239f5aa User: magicmoux Date: 2015-03-06 17:07:44+00:00 Summary: Toward a buildable Library Affected #: 6 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/f0bae33be9a6/ Changeset: f0bae33be9a6 User: magicmoux Date: 2015-04-02 04:47:04+00:00 Summary: Expansion of common features to the BaseModifyCommand API Affected #: 4 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/5a6015a234ce/ Changeset: 5a6015a234ce User: magicmoux Date: 2015-04-02 04:51:30+00:00 Summary: Modification of the Graph pattern to support ActiveGraph property which refers to the real used graph for childGraphPatterns. Added the GraphSpecifiers collection to get all Graph tokens for nested GraphGraphPatterns since variable graph tokens do not appears in the Variables collection. Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/258f14474d86/ Changeset: 258f14474d86 User: magicmoux Date: 2015-04-02 04:53:03+00:00 Summary: Set of GraphPattern extension to help work with them without making the API public. Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/d39f7d987e53/ Changeset: d39f7d987e53 User: magicmoux Date: 2015-04-02 04:57:22+00:00 Summary: Made the Bindings set public Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/2f10d874bfcc/ Changeset: 2f10d874bfcc User: magicmoux Date: 2015-04-02 04:58:47+00:00 Summary: Moved the PatternHelpers into ExternalHelpers Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/732cc079dae1/ Changeset: 732cc079dae1 User: magicmoux Date: 2015-04-03 05:11:22+00:00 Summary: Simplified the writing of graph patterns to avoid too many parenthesis Affected #: 5 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/27e3c4fba45e/ Changeset: 27e3c4fba45e User: magicmoux Date: 2015-04-03 11:32:56+00:00 Summary: Stable for transactional rewriting Affected #: 13 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/86375ac94f60/ Changeset: 86375ac94f60 User: magicmoux Date: 2015-04-03 11:33:45+00:00 Summary: Renamed classes Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/a79428abfd31/ Changeset: a79428abfd31 User: magicmoux Date: 2015-04-03 11:37:51+00:00 Summary: Reassigned events handlers correctly Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/53c3c25f7b8f/ Changeset: 53c3c25f7b8f User: magicmoux Date: 2015-04-03 12:34:19+00:00 Summary: Parameters handling and RdfNull node creation Affected #: 3 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/53bad5935006/ Changeset: 53bad5935006 User: magicmoux Date: 2015-04-03 12:47:36+00:00 Summary: Some minor refactoring and documentation Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/f994ade1eba4/ Changeset: f994ade1eba4 User: magicmoux Date: 2015-04-03 12:50:39+00:00 Summary: Scoping variable correction Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/d7f7299fc7d1/ Changeset: d7f7299fc7d1 User: magicmoux Date: 2015-04-03 12:59:29+00:00 Summary: Event helper rename and remake compilable Affected #: 3 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/d324d3c49cad/ Changeset: d324d3c49cad User: magicmoux Date: 2015-04-04 04:44:23+00:00 Summary: Provide correct handling of pending update graphs for possible command interruption handling Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/eec81913f337/ Changeset: eec81913f337 User: magicmoux Date: 2015-04-04 05:11:26+00:00 Summary: Renaming the API for temporary resource consumer/creators to avoid Affected #: 3 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/b385fca2b372/ Changeset: b385fca2b372 User: magicmoux Date: 2015-04-07 06:45:14+00:00 Summary: Refactored CommandUnit dependences using events. Corrected falgs usage for Connection State property Added GraphsChanged event to the COnnection class Affected #: 5 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/36e04ab16c08/ Changeset: 36e04ab16c08 User: magicmoux Date: 2015-04-07 06:46:58+00:00 Summary: Class refactoring Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/7f466a878591/ Changeset: 7f466a878591 User: magicmoux Date: 2015-04-08 13:00:04+00:00 Summary: Prepare for merge Affected #: 20 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/01d8e32ad1e7/ Changeset: 01d8e32ad1e7 User: magicmoux Date: 2015-04-08 13:01:26+00:00 Summary: Fusion Affected #: 60 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/bf2b94a37b17/ Changeset: bf2b94a37b17 User: magicmoux Date: 2015-04-08 13:52:16+00:00 Summary: Unit tests Affected #: 14 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/fc57884d37c4/ Changeset: fc57884d37c4 User: magicmoux Date: 2015-04-08 13:52:29+00:00 Summary: Unit tests Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/27a8c81c3b27/ Changeset: 27a8c81c3b27 User: magicmoux Date: 2015-04-17 10:58:50+00:00 Summary: Adding a default Sparql 1.1 Service Description getter on StorageProviders classes Affected #: 7 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/c820c695415c/ Changeset: c820c695415c User: magicmoux Date: 2015-04-17 10:59:56+00:00 Summary: Made the BaseModifyCommand GraphUri setter public Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/2ea2ff15c73d/ Changeset: 2ea2ff15c73d User: magicmoux Date: 2015-04-17 11:03:33+00:00 Summary: Refactored NullReference tests into Getters to allow for the SPIN library to directly subclass the baseSparqlServer implementation instead of duplicating it Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/65b712021df0/ Changeset: 65b712021df0 User: magicmoux Date: 2015-04-17 11:19:24+00:00 Summary: Making ISparqlExpression arguments settable Affected #: 43 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/0bb703862027/ Changeset: 0bb703862027 User: magicmoux Date: 2015-04-17 11:20:04+00:00 Summary: Making SparqlQuery objects more usable from outside Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/bc10016a55bb/ Changeset: bc10016a55bb User: magicmoux Date: 2015-04-17 11:20:53+00:00 Summary: Expanding the SparqlParameterizedString class Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/fac3e0cc2158/ Changeset: fac3e0cc2158 User: magicmoux Date: 2015-04-17 11:26:24+00:00 Summary: Removing the forced KeepAlive that was used for testing to use the system defaults Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/ecf7ac1cb7a7/ Changeset: ecf7ac1cb7a7 User: magicmoux Date: 2015-04-17 15:24:11+00:00 Summary: some refactoring Affected #: 10 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/73d041e98ad8/ Changeset: 73d041e98ad8 User: magicmoux Date: 2015-04-17 15:25:41+00:00 Summary: some refactoring Affected #: 3 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/b87df68f4f8b/ Changeset: b87df68f4f8b User: magicmoux Date: 2015-04-17 15:27:14+00:00 Summary: Finally figured how assignments placement can be "preserved" when replacing triplePatterns with GraphPatterns Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/376dcb281a53/ Changeset: 376dcb281a53 User: magicmoux Date: 2015-04-17 15:28:32+00:00 Summary: Preparing for some cleaning before pull request Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/f5d5117fdd43/ Changeset: f5d5117fdd43 User: magicmoux Date: 2015-04-17 16:28:35+00:00 Summary: Cleaning to make compilable and removing old references Affected #: 39 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/b82d73a341a9/ Changeset: b82d73a341a9 User: magicmoux Date: 2015-04-17 16:29:11+00:00 Summary: VS project update Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/b2808f45e3f5/ Changeset: b2808f45e3f5 User: magicmoux Date: 2015-04-17 16:34:51+00:00 Summary: VS project update Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/7af2bd00ea7c/ Changeset: 7af2bd00ea7c User: magicmoux Date: 2015-04-17 16:39:27+00:00 Summary: Cleaning to make compilable and removing old references Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/7bbe635fc26d/ Changeset: 7bbe635fc26d User: magicmoux Date: 2015-04-17 16:44:14+00:00 Summary: Cleaning to make compilable and removing pending references Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/3cc7e8c7a571/ Changeset: 3cc7e8c7a571 User: magicmoux Date: 2015-04-20 16:18:18+00:00 Summary: Simplified and more stable garbage collection of temporary resources Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/d429d265046e/ Changeset: d429d265046e User: magicmoux Date: 2015-04-20 16:18:44+00:00 Summary: Making the strategy work as intended Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/c8dcada3400a/ Changeset: c8dcada3400a User: magicmoux Date: 2015-04-20 16:19:18+00:00 Summary: making the connection ping work until better handling Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/09df3c3ba469/ Changeset: 09df3c3ba469 User: magicmoux Date: 2015-04-20 16:20:03+00:00 Summary: Foring the underlying storage to be updateable and cleaning some todos Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/a29d7840cfbe/ Changeset: a29d7840cfbe User: magicmoux Date: 2015-04-20 16:20:45+00:00 Summary: Some corrections in the core testing suite Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/cc8fc86537b1/ Changeset: cc8fc86537b1 User: magicmoux Date: 2015-04-20 16:22:18+00:00 Summary: Corrections to algebra evaluation for queries with VALUES clauses Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/f38a9513c11d/ Changeset: f38a9513c11d User: magicmoux Date: 2015-04-20 16:23:18+00:00 Summary: Correction for some changes into the RegexOptions Enum on multiple platform compilation Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/5d664fe99ef3/ Changeset: 5d664fe99ef3 User: magicmoux Date: 2015-04-20 16:25:01+00:00 Summary: First add for SPIN library tests in the suite Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/6955bbc59935/ Changeset: 6955bbc59935 User: magicmoux Date: 2015-04-20 16:25:45+00:00 Summary: Removing the initial tests project from the solution Affected #: 5 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/60db751c4718/ Changeset: 60db751c4718 User: magicmoux Date: 2015-04-21 05:09:23+00:00 Summary: Refactor the TransactionLog into a StorageRuntimeMonitor Affected #: 7 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/1858159b0b0f/ Changeset: 1858159b0b0f User: magicmoux Date: 2015-04-21 07:26:32+00:00 Summary: Some last-minute refactoring and code-cleaning before next cycle Affected #: 157 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/58440362d7bf/ Changeset: 58440362d7bf User: magicmoux Date: 2015-04-24 06:00:36+00:00 Summary: Force all variables used in a BindPattern to be in-scope in the Parent GraphPattern (see http://www.w3.org/TR/sparql11-query/#variableScope) Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/1f7cb88ef458/ Changeset: 1f7cb88ef458 User: magicmoux Date: 2015-04-24 07:19:46+00:00 Summary: Some last minute refactoring and comments updates Affected #: 13 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/aaee7d82f733/ Changeset: aaee7d82f733 User: magicmoux Date: 2015-04-24 07:19:59+00:00 Summary: Some last minute refactoring and comments updates Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/22f8203b6a38/ Changeset: 22f8203b6a38 User: magicmoux Date: 2015-04-24 19:30:52+00:00 Summary: Inclusion of (naive still, but there) unit tests for the Spin Library + correctin of multiset index that now should start at 0 Affected #: 7 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/edd30882a258/ Changeset: edd30882a258 User: magicmoux Date: 2015-04-25 06:20:30+00:00 Summary: Commenting about the failing InMemory Spin Tests and give some clues for a possible resolution Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/9d9ecb4ea3fd/ Changeset: 9d9ecb4ea3fd User: magicmoux Date: 2015-04-25 06:22:09+00:00 Summary: Commenting about the failing InMemory Spin Tests and give some clues for a possible resolution Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 3 Date: Mon, 06 Jul 2015 08:38:55 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #40) To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/266585d6ed31/ Changeset: 266585d6ed31 User: rvesse Date: 2015-07-06 08:38:40+00:00 Summary: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #40) Fix for BASE url capture Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 4 Date: Mon, 06 Jul 2015 11:15:27 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 4 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 4 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/85d2652a0461/ Changeset: 85d2652a0461 User: MartinLercher Date: 2015-07-05 14:11:12+00:00 Summary: Bugfix for issue CORE-449 Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e91cf5931469/ Changeset: e91cf5931469 User: MartinLercher Date: 2015-07-05 18:49:27+00:00 Summary: Bugfix for issue CORE-451 Affected #: 3 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/5654a5d3e713/ Changeset: 5654a5d3e713 User: MartinLercher Date: 2015-07-06 10:38:05+00:00 Summary: Bugfix: Types should be <TNodeID, TGraphID> instead of <Guid, Guid> (credits: Rob Vesse) Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e6deaa9d5252/ Changeset: e6deaa9d5252 User: rvesse Date: 2015-07-06 11:15:21+00:00 Summary: Merged in MartinLercher/dotnetrdf (pull request #41) Fixes for issue CORE-449 and CORE-451 Affected #: 4 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 5 Date: Mon, 06 Jul 2015 11:15:29 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Merged in MartinLercher/dotnetrdf (pull request #41) To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e6deaa9d5252/ Changeset: e6deaa9d5252 User: rvesse Date: 2015-07-06 11:15:21+00:00 Summary: Merged in MartinLercher/dotnetrdf (pull request #41) Fixes for issue CORE-449 and CORE-451 Affected #: 4 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ------------------------------ _______________________________________________ dotNetRDF-commits mailing list dot...@li... https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits End of dotNetRDF-commits Digest, Vol 29, Issue 1 ************************************************ |
|
From: Max - M. <ma...@mi...> - 2015-06-01 17:20:46
|
Ok Rob,
Sadly I must agree with you after reviewing the recommendation in depth and
even more sadly here is another SPARQL deception and disappointment here :(
They must have had reasons to define this as is but I feel they breached
the left-join logic join since the left-join may finally behave like a full
outer join on LHS binding errors/unbound value, where they follow the
natural-join logic (empty joined-variable bindings being filtered out)
while dealing with relational-like structures...
2015-06-01 15:37 GMT+02:00 Rob Vesse <rv...@do...>:
> No I don't think so
>
> Consider:
>
> {
> ?s ?p ?o .
> BIND (?o / 0 AS ?example)
> }
>
> ?o is a fixed variable, however regardless of whether it is fixed/floating
> the expression it is involved in may error (or in this example always
> error) and so we always have to treat ?example as a floating variable
>
> That modification will only work for trivial left joins (and sometimes not
> even then if you have FILTERs over the left join), deep left joins will
> almost certainly be broken by that change.
>
> The logic around whether we flow results is based on the logic used by
> Apache Jena ARQ which is pretty much the reference implementation of SPARQL
> since it is maintained by the editor of the SPARQL Query specification.
>
> Rob
>
> From: Max - Micrologiciel <ma...@mi...>
> Reply-To: dotNetRDF Developer Discussion and Feature Request <
> dot...@li...>
> Date: Thursday, 28 May 2015 16:01
> To: dotNetRDF Developer Discussion and Feature Request <
> dot...@li...>
> Subject: Re: [dotNetRDF-Develop] About PR#36
>
> Ok forget this, I just realized I was running the test-case against my
> Sesame Store instead of the InMemory (which effectively handles the join
> example correctly).
> I'll file them a bug request.
>
> Sorry for the time wasted and thanks for your patience.
>
> However for the BIND LHS with left join, the variables I use in the
> expression are also bound from a triplePattern. Here is an example
>
> ex:cmd ex:hasDefaultGraph ?g .
> BIND(IRI(CONCAT("tmp:, STR(?g))) AS ?tmpG)
> OPTIONAL { GRAPH ?tmpG { ...
>
> Could it be safe to say that the BIND variable is floating if any of the
> expression variables is floating and otherwise make it fixed ?
> And modify the CanFlowResultsToRhs l.312 into
>
> if (rhsFloating.Any(v => lhsFloating.Contains(v) /* ||
> lhsFixed.Contains(v) */ )) return false;
>
> This seems to do the trick in my case.
>
> Max.
>
>
>
> 2015-05-28 15:32 GMT+02:00 Rob Vesse <rv...@do...>:
>
>> Comments inline
>>
>>
>> From: Max - Micrologiciel <ma...@mi...>
>> Date: Thursday, 28 May 2015 13:36
>> To: Rob Vesse <rv...@do...>
>> Cc: dotNetRDF Developer Discussion and Feature Request <
>> dot...@li...>
>> Subject: Re: About PR#36
>>
>> Sorry but I missed the conclusion of the demonstration :
>>
>> This to show that after a variable is defined by a BIND statement it
>> should not be considered as a floating variable.
>>
>>
>> However your conclusion about floating variables and BIND is wrong at
>> least according to how we define and use the concept of a floating variable
>> within the Leviathan engine
>>
>> A floating variable is a variable whose value is not guaranteed to be
>> bound which as I pointed out is the exact definition of a BIND variable,
>> the expression could error and so the variable could be unbound
>>
>>
>>
>> To my understanding, the only floating variables to be considered should
>> come from VALUES clauses.
>>
>>
>> Floating variables can come from BIND, OPTIONAL, VALUES, SELECT
>> expressions, aggregates I.e. anywhere where an expression is evaluated or
>> where it is possible to have unbound values
>>
>>
>> Max.
>>
>> 2015-05-28 14:31 GMT+02:00 Max - Micrologiciel <ma...@mi...>:
>>
>>> Rob,
>>>
>>> thanks for the answers.
>>>
>>> Concerning the extend case, I then definitely believe there is a flaw in
>>> our evaluation logic.
>>> *To me, the join operation should behave as it would in relational logic
>>> meaning comparing NULL with NULL will always return false so no result.*
>>>
>>
>> It already does, you seem to be conflating joins with left joins
>> (OPTIONAL) and the two are not the same
>>
>>
>>> Here's my demonstration of the case.
>>>
>>> First about the join evaluation, based on the recommendation we get :
>>>
>>> 1. §18.5 : Join(Ω1, Ω2) = { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2,
>>> and μ1 and μ2 are compatible }
>>> 2. $18.3 : Two solution mappings μ1 and μ2 are compatible if, for
>>> every variable v in dom(μ1) and in dom(μ2), μ1(v) = μ2(v)
>>> Here, μ1(v) = μ2(v) means that μ1(v) and μ2(v) are the same RDF term.
>>>
>>> Inferred from this the join definition would be equivalent to Join(Ω1, Ω
>>> 2) = { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and for each variable v in
>>> intersect(dom(μ1) dom(μ2)) sameterm(μ1(v), μ2(v)) is true }
>>> which means the join
>>>
>>> ?s ?p1 ?o1 .
>>> ?s ?p2 ?o2
>>>
>>> is equivalent to
>>>
>>> ?s1 ?p1 ?o1 .
>>> ?s2 ?p2 ?o2
>>> FILTER (sameterm(s1,s2)
>>>
>>> But we also have :
>>>
>>> 1. $17 Specifically, FILTERs eliminate any solutions that, when
>>> substituted into the expression, either result in an effective boolean
>>> value of false or produce an error.
>>> 2. §17.2 sameterm will produce a type error if any arguments are
>>> unbound
>>>
>>>
>>> Then about the extend case, let's say we have this graph pattern:
>>>
>>> ?s ?p ?o . FILTER(isLiteral(?o))
>>> ?s2 ?p2 ?o2 .
>>>
>>> The evaluation will return a cross join of both triple pattern mutlisets
>>> since according to $18.3, they are compatible because having no common
>>> variable.
>>>
>>> On the other hand, given the following pattern,
>>>
>>> {?s ?p ?o . FILTER(isBlank(?o)) }
>>> BIND (iri(?o) as ?s2) .
>>> ?s2 ?p2 ?o2
>>>
>>> Under your logic, the join would return me the same results since
>>> iri(?o) will produce a type error ?o being a blank node which is not
>>> accepted by the Iri function.
>>>
>>
>> Nowhere did I say this
>>
>> With regards to index joins we were talking specifically about the case
>> of a BIND being on the LHS of an OPTIONAL which is completely different
>> because left joins are not commutative
>>
>> Rob
>>
>>
>>>
>>> I do not agree with this since :
>>>
>>> 1. §10.1 Use of BIND ends the preceding basic graph pattern.
>>> 2. If the evaluation of the expression produces an error, the
>>> variable remains unbound for that solution but the query evaluation
>>> continues.
>>>
>>> Which means to me that in fact we now have to perform a join between the
>>> two mutlisets μ1[?s ?p ?o ?s2] and μ2[?s2 ?p2 ?o2]
>>>
>>>
>>> So still according to §18.5 and §18.3, both multisets are then now
>>> incompatible since they share the ?s2 variable which can not be compared
>>> under the sameterm conditions.
>>>
>>> Thus We should get no result back from the query.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2015-05-28 12:50 GMT+02:00 Rob Vesse <rv...@do...>:
>>>
>>>> Max
>>>>
>>>> Comments inline:
>>>>
>>>> From: Max - Micrologiciel <ma...@mi...>
>>>> Date: Wednesday, 27 May 2015 13:48
>>>> To: Rob Vesse <rv...@do...>
>>>> Subject: About PR#36
>>>>
>>>> Hi Rob,
>>>>
>>>> just been reviewing some comment you made in the #36 PR
>>>> <https://bitbucket.org/dotnetrdf/dotnetrdf/pull-request/36/new-spin-library> about
>>>> a change I made at first with the order of join arguments between the
>>>> query's algebra and any possible BindingPattern.
>>>>
>>>> You wrote :
>>>> "Though I think our handling of VALUES may already be broken in some
>>>> cases anyway e.g. interaction with GROUP BY"
>>>>
>>>> Would you have some example that exposes the problem, so I can have a
>>>> look into it ?
>>>>
>>>>
>>>> If memory serves the problem is that we apply VALUES too soon. It
>>>> should apply after any GROUP BY, HAVING and SELECT expressions but we apply
>>>> it before those. This is a fairly trivial fix which I simply haven't got
>>>> round to because it is a rare enough case that nobody has ever complained
>>>> that it is broken (NB - It's fixed in the new Medusa engine on the 1.9
>>>> branch)
>>>>
>>>>
>>>>
>>>> On the other hand, I do not agree with you when you say that inverting
>>>> the join parameters would break our compliance with the spec : since the
>>>> join operation is normally commutative (and neither does the recommendation
>>>> specifies explicitly in which order the sets are to be joined), we should
>>>> be able to join the arguments in both orders and get the same results .
>>>>
>>>>
>>>> In principal yes, however once you start doing indexed joins this does
>>>> have the potential to break things if you aren't careful though we are
>>>> fairly careful these days so probably doesn't make a difference nowadays
>>>>
>>>> Moreover, evaluating the bindings first could also lead to better
>>>> performances since bound variables injection into the RHS whenever possible
>>>> would lighten the multiset to join with.
>>>>
>>>> There is also an issue I encountered and I'd like to discuss with the
>>>> Extend algebra.
>>>> When used as a left join LHS, it prevents injecting the bound variables
>>>> into the Rhs due to the CanFlowResultsToRhs workings and how the extended
>>>> variable is always treated as floating.
>>>>
>>>>
>>>> Well anything introduced by Extend always has to be treated as floating
>>>> because the expression could produce an error or an unbound value
>>>>
>>>> There are a couple of cases when the expression is a constant value or
>>>> a copy of a variable (provided we know that variable to be fixed) that we
>>>> could special case but otherwise we can't do anything more.
>>>>
>>>> If you are generating Extends simply to introduce constants generating
>>>> Values instead may be a better approach and will benefit from index joins
>>>> as you note.
>>>>
>>>> Rob
>>>>
>>>>
>>>> Perhaps it would be better to discuss these live, if you're available ?
>>>>
>>>> Cheers,
>>>> Max.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> dotNetRDF-develop mailing list
>> dot...@li...
>> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>>
>>
> ------------------------------------------------------------------------------
> _______________________________________________ dotNetRDF-develop mailing
> list dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> dotNetRDF-develop mailing list
> dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>
>
|
|
From: Rob V. <rv...@do...> - 2015-06-01 13:37:57
|
No I don't think so
Consider:
{
?s ?p ?o .
BIND (?o / 0 AS ?example)
}
?o is a fixed variable, however regardless of whether it is fixed/floating
the expression it is involved in may error (or in this example always error)
and so we always have to treat ?example as a floating variable
That modification will only work for trivial left joins (and sometimes not
even then if you have FILTERs over the left join), deep left joins will
almost certainly be broken by that change.
The logic around whether we flow results is based on the logic used by
Apache Jena ARQ which is pretty much the reference implementation of SPARQL
since it is maintained by the editor of the SPARQL Query specification.
Rob
From: Max - Micrologiciel <ma...@mi...>
Reply-To: dotNetRDF Developer Discussion and Feature Request
<dot...@li...>
Date: Thursday, 28 May 2015 16:01
To: dotNetRDF Developer Discussion and Feature Request
<dot...@li...>
Subject: Re: [dotNetRDF-Develop] About PR#36
> Ok forget this, I just realized I was running the test-case against my Sesame
> Store instead of the InMemory (which effectively handles the join example
> correctly).
> I'll file them a bug request.
>
> Sorry for the time wasted and thanks for your patience.
>
> However for the BIND LHS with left join, the variables I use in the
> expression are also bound from a triplePattern. Here is an example
>
> ex:cmd ex:hasDefaultGraph ?g .
> BIND(IRI(CONCAT("tmp:, STR(?g))) AS ?tmpG)
> OPTIONAL { GRAPH ?tmpG { ...
>
> Could it be safe to say that the BIND variable is floating if any of the
> expression variables is floating and otherwise make it fixed ?
> And modify the CanFlowResultsToRhs l.312 into
>
> if (rhsFloating.Any(v => lhsFloating.Contains(v) /* || lhsFixed.Contains(v) */
> )) return false;
>
> This seems to do the trick in my case.
>
> Max.
>
>
>
> 2015-05-28 15:32 GMT+02:00 Rob Vesse <rv...@do...>:
>> Comments inline
>>
>>
>> From: Max - Micrologiciel <ma...@mi...>
>> Date: Thursday, 28 May 2015 13:36
>> To: Rob Vesse <rv...@do...>
>> Cc: dotNetRDF Developer Discussion and Feature Request
>> <dot...@li...>
>> Subject: Re: About PR#36
>>
>>> Sorry but I missed the conclusion of the demonstration :
>>>
>>> This to show that after a variable is defined by a BIND statement it should
>>> not be considered as a floating variable.
>>
>> However your conclusion about floating variables and BIND is wrong at least
>> according to how we define and use the concept of a floating variable within
>> the Leviathan engine
>>
>> A floating variable is a variable whose value is not guaranteed to be bound
>> which as I pointed out is the exact definition of a BIND variable, the
>> expression could error and so the variable could be unbound
>>
>>>
>>>
>>> To my understanding, the only floating variables to be considered should
>>> come from VALUES clauses.
>>
>> Floating variables can come from BIND, OPTIONAL, VALUES, SELECT expressions,
>> aggregates I.e. anywhere where an expression is evaluated or where it is
>> possible to have unbound values
>>
>>>
>>> Max.
>>>
>>> 2015-05-28 14:31 GMT+02:00 Max - Micrologiciel <ma...@mi...>:
>>>> Rob,
>>>>
>>>> thanks for the answers.
>>>>
>>>> Concerning the extend case, I then definitely believe there is a flaw in
>>>> our evaluation logic.
>>>> To me, the join operation should behave as it would in relational logic
>>>> meaning comparing NULL with NULL will always return false so no result.
>>
>> It already does, you seem to be conflating joins with left joins (OPTIONAL)
>> and the two are not the same
>>
>>>>
>>>> Here's my demonstration of the case.
>>>>
>>>> First about the join evaluation, based on the recommendation we get :
>>>> 1. §18.5 : Join(Ω1, Ω2) = { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and μ1
>>>> and μ2 are compatible }
>>>> 2.
>>>> 3. $18.3 : Two solution mappings μ1 and μ2 are compatible if, for every
>>>> variable v in dom(μ1) and in dom(μ2), μ1(v) = μ2(v)
>>>> 4. Here, μ1(v) = μ2(v) means that μ1(v) and μ2(v) are the same RDF term.
>>>> Inferred from this the join definition would be equivalent to Join(Ω1, Ω2)
>>>> = { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and for each variable v in
>>>> intersect(dom(μ1) dom(μ2)) sameterm(μ1(v), μ2(v)) is true }
>>>> which means the join
>>>>
>>>> ?s ?p1 ?o1 .
>>>> ?s ?p2 ?o2
>>>>
>>>> is equivalent to
>>>>
>>>> ?s1 ?p1 ?o1 .
>>>> ?s2 ?p2 ?o2
>>>> FILTER (sameterm(s1,s2)
>>>>
>>>> But we also have :
>>>> 1. $17 Specifically, FILTERs eliminate any solutions that, when substituted
>>>> into the expression, either result in an effective boolean value of false
>>>> or produce an error.
>>>> 2.
>>>> 3. §17.2 sameterm will produce a type error if any arguments are unbound
>>>>
>>>> Then about the extend case, let's say we have this graph pattern:
>>>>
>>>> ?s ?p ?o . FILTER(isLiteral(?o))
>>>> ?s2 ?p2 ?o2 .
>>>>
>>>> The evaluation will return a cross join of both triple pattern mutlisets
>>>> since according to $18.3, they are compatible because having no common
>>>> variable.
>>>>
>>>> On the other hand, given the following pattern,
>>>>
>>>> {?s ?p ?o . FILTER(isBlank(?o)) }
>>>> BIND (iri(?o) as ?s2) .
>>>> ?s2 ?p2 ?o2
>>>>
>>>> Under your logic, the join would return me the same results since iri(?o)
>>>> will produce a type error ?o being a blank node which is not accepted by
>>>> the Iri function.
>>
>> Nowhere did I say this
>>
>> With regards to index joins we were talking specifically about the case of a
>> BIND being on the LHS of an OPTIONAL which is completely different because
>> left joins are not commutative
>>
>> Rob
>>
>>>>
>>>>
>>>> I do not agree with this since :
>>>> 1. §10.1 Use of BIND ends the preceding basic graph pattern.
>>>> 2.
>>>> 3. If the evaluation of the expression produces an error, the variable
>>>> remains unbound for that solution but the query evaluation continues.
>>>> Which means to me that in fact we now have to perform a join between the
>>>> two mutlisets μ1[?s ?p ?o ?s2] and μ2[?s2 ?p2 ?o2]
>>>>>
>>>> So still according to §18.5 and §18.3, both multisets are then now
>>>> incompatible since they share the ?s2 variable which can not be compared
>>>> under the sameterm conditions.
>>>>
>>>> Thus We should get no result back from the query.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2015-05-28 12:50 GMT+02:00 Rob Vesse <rv...@do...>:
>>>>> Max
>>>>>
>>>>> Comments inline:
>>>>>
>>>>> From: Max - Micrologiciel <ma...@mi...>
>>>>> Date: Wednesday, 27 May 2015 13:48
>>>>> To: Rob Vesse <rv...@do...>
>>>>> Subject: About PR#36
>>>>>
>>>>>> Hi Rob,
>>>>>>
>>>>>> just been reviewing some comment you made in the #36 PR
>>>>>> <https://bitbucket.org/dotnetrdf/dotnetrdf/pull-request/36/new-spin-libra
>>>>>> ry> about a change I made at first with the order of join arguments
>>>>>> between the query's algebra and any possible BindingPattern.
>>>>>>
>>>>>> You wrote :
>>>>>> "Though I think our handling of VALUES may already be broken in some
>>>>>> cases anyway e.g. interaction with GROUP BY"
>>>>>>
>>>>>> Would you have some example that exposes the problem, so I can have a
>>>>>> look into it ?
>>>>>
>>>>> If memory serves the problem is that we apply VALUES too soon. It should
>>>>> apply after any GROUP BY, HAVING and SELECT expressions but we apply it
>>>>> before those. This is a fairly trivial fix which I simply haven't got
>>>>> round to because it is a rare enough case that nobody has ever complained
>>>>> that it is broken (NB - It's fixed in the new Medusa engine on the 1.9
>>>>> branch)
>>>>>
>>>>>>
>>>>>>
>>>>>> On the other hand, I do not agree with you when you say that inverting
>>>>>> the join parameters would break our compliance with the spec : since the
>>>>>> join operation is normally commutative (and neither does the
>>>>>> recommendation specifies explicitly in which order the sets are to be
>>>>>> joined), we should be able to join the arguments in both orders and get
>>>>>> the same results .
>>>>>
>>>>> In principal yes, however once you start doing indexed joins this does
>>>>> have the potential to break things if you aren't careful though we are
>>>>> fairly careful these days so probably doesn't make a difference nowadays
>>>>>
>>>>>> Moreover, evaluating the bindings first could also lead to better
>>>>>> performances since bound variables injection into the RHS whenever
>>>>>> possible would lighten the multiset to join with.
>>>>>>
>>>>>> There is also an issue I encountered and I'd like to discuss with the
>>>>>> Extend algebra.
>>>>>> When used as a left join LHS, it prevents injecting the bound variables
>>>>>> into the Rhs due to the CanFlowResultsToRhs workings and how the extended
>>>>>> variable is always treated as floating.
>>>>>
>>>>> Well anything introduced by Extend always has to be treated as floating
>>>>> because the expression could produce an error or an unbound value
>>>>>
>>>>> There are a couple of cases when the expression is a constant value or a
>>>>> copy of a variable (provided we know that variable to be fixed) that we
>>>>> could special case but otherwise we can't do anything more.
>>>>>
>>>>> If you are generating Extends simply to introduce constants generating
>>>>> Values instead may be a better approach and will benefit from index joins
>>>>> as you note.
>>>>>
>>>>> Rob
>>>>>
>>>>>>
>>>>>> Perhaps it would be better to discuss these live, if you're available ?
>>>>>>
>>>>>> Cheers,
>>>>>> Max.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
----------------------------------------------------------------------------->>
-
>>
>> _______________________________________________
>> dotNetRDF-develop mailing list
>> dot...@li...
>> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________ dotNetRDF-develop mailing list
> dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
|
|
From: <dot...@li...> - 2015-05-29 16:27:38
|
Send dotNetRDF-commits mailing list submissions to dot...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits or, via email, send a message with subject or body 'help' to dot...@li... You can reach the person managing the list at dot...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of dotNetRDF-commits digest..." Today's Topics: 1. commit/dotnetrdf: rvesse: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #37) (Bitbucket) 2. commit/dotnetrdf: 2 new changesets (Bitbucket) 3. commit/dotnetrdf: 2 new changesets (Bitbucket) 4. commit/dotnetrdf: rvesse: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #38) (Bitbucket) 5. commit/dotnetrdf: 2 new changesets (Bitbucket) 6. commit/dotnetrdf: rvesse: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #39) (Bitbucket) 7. commit/dotnetrdf: 4 new changesets (Bitbucket) 8. commit/dotnetrdf: 5 new changesets (Bitbucket) 9. commit/dotnetrdf: 2 new changesets (Bitbucket) ---------------------------------------------------------------------- Message: 1 Date: Mon, 18 May 2015 09:58:52 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #37) To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/14f07984f649/ Changeset: 14f07984f649 User: rvesse Date: 2015-05-18 09:58:46+00:00 Summary: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #37) New SparqlParameterizedString implementation Affected #: 2 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 2 Date: Fri, 22 May 2015 14:00:06 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/f5630e3e4db9/ Changeset: f5630e3e4db9 Branch: 1.9 User: rvesse Date: 2015-05-22 13:45:47+00:00 Summary: Remove .Net 3.5 Targets Affected #: 19 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/c923f4e28685/ Changeset: c923f4e28685 Branch: 1.9 User: rvesse Date: 2015-05-22 13:58:42+00:00 Summary: Update various dependencies Affected #: 10 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 3 Date: Tue, 26 May 2015 10:21:39 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e585e64f1936/ Changeset: e585e64f1936 Branch: CORE-445 User: magicmoux Date: 2015-05-26 10:02:17+00:00 Summary: Correction of a wrong index test that will leave out the last character of the SparqlParameterizedString if preceded by a variable or parameter reference. Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/9ab790a52e61/ Changeset: 9ab790a52e61 User: rvesse Date: 2015-05-26 10:21:33+00:00 Summary: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #38) Correction to a bug from PR#37 Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 4 Date: Tue, 26 May 2015 10:21:40 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #38) To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/9ab790a52e61/ Changeset: 9ab790a52e61 User: rvesse Date: 2015-05-26 10:21:33+00:00 Summary: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #38) Correction to a bug from PR#37 Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 5 Date: Tue, 26 May 2015 11:34:19 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/615993ff72ff/ Changeset: 615993ff72ff Branch: CORE-445 User: magicmoux Date: 2015-05-26 10:25:37+00:00 Summary: Correction of a wrong index test that will leave out the last character of the SparqlParameterizedString if preceded by a variable or parameter reference. Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/b1e45c6d24df/ Changeset: b1e45c6d24df User: rvesse Date: 2015-05-26 11:34:14+00:00 Summary: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #39) Fix against regression in SparqlParameterizedString Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 6 Date: Tue, 26 May 2015 11:34:20 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #39) To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/b1e45c6d24df/ Changeset: b1e45c6d24df User: rvesse Date: 2015-05-26 11:34:14+00:00 Summary: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #39) Fix against regression in SparqlParameterizedString Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 7 Date: Fri, 29 May 2015 12:11:51 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 4 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 4 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/b22f4951a19f/ Changeset: b22f4951a19f Branch: 1.9 User: rvesse Date: 2015-05-29 11:24:38+00:00 Summary: Add a .Net 4.0 Client Profile target for Core tests Affected #: 8 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/b9ac9ec3b924/ Changeset: b9ac9ec3b924 Branch: 1.9 User: rvesse Date: 2015-05-29 11:49:03+00:00 Summary: Fix bugs in RDF/XML parsing Affected #: 4 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/6027e3d2184c/ Changeset: 6027e3d2184c Branch: 1.9 User: rvesse Date: 2015-05-29 12:07:12+00:00 Summary: Fix up bugs in parser test suites that were preventing successful runs Affected #: 4 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/2bb69ebb50f8/ Changeset: 2bb69ebb50f8 Branch: 1.9 User: rvesse Date: 2015-05-29 12:10:54+00:00 Summary: Minor tweak to JSON MIME type testing Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 8 Date: Fri, 29 May 2015 16:08:09 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 5 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 5 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/5cba15df52d5/ Changeset: 5cba15df52d5 Branch: 1.9 User: rvesse Date: 2015-05-29 14:36:53+00:00 Summary: Fix up the NAnt build file Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/72bf9fd081a7/ Changeset: 72bf9fd081a7 Branch: 1.9 User: rvesse Date: 2015-05-29 14:37:27+00:00 Summary: Updated license headers to current Copyright Year and correct email address Affected #: 680 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/6303766611bb/ Changeset: 6303766611bb Branch: 1.9 User: rvesse Date: 2015-05-29 15:06:44+00:00 Summary: Work towards getting Alpha NuGet packages ready Affected #: 26 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/508eb038c59f/ Changeset: 508eb038c59f Branch: 1.9 User: rvesse Date: 2015-05-29 15:42:03+00:00 Summary: Refactor NAnt build to reuse more logic Affected #: 6 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/65ca8c591b7d/ Changeset: 65ca8c591b7d Branch: 1.9 User: rvesse Date: 2015-05-29 16:07:34+00:00 Summary: Further refactor NAnt build file into reusable targets Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 9 Date: Fri, 29 May 2015 16:27:30 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/bb41938b2ce5/ Changeset: bb41938b2ce5 Branch: 1.9 User: rvesse Date: 2015-05-29 16:22:32+00:00 Summary: Further improvements to NAnt build file and NuGet packaging for Sparql.Core library Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/f32009e0f7af/ Changeset: f32009e0f7af Branch: 1.9 User: rvesse Date: 2015-05-29 16:27:05+00:00 Summary: Final tweaks to NAnt to allow successful pushes of 1.9 alpha packages Affected #: 2 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ ------------------------------------------------------------------------------ ------------------------------ _______________________________________________ dotNetRDF-commits mailing list dot...@li... https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits End of dotNetRDF-commits Digest, Vol 28, Issue 2 ************************************************ |
|
From: Max - M. <ma...@mi...> - 2015-05-28 15:01:57
|
Ok forget this, I just realized I was running the test-case against my
Sesame Store instead of the InMemory (which effectively handles the join
example correctly).
I'll file them a bug request.
Sorry for the time wasted and thanks for your patience.
However for the BIND LHS with left join, the variables I use in the
expression are also bound from a triplePattern. Here is an example
ex:cmd ex:hasDefaultGraph ?g .
BIND(IRI(CONCAT("tmp:, STR(?g))) AS ?tmpG)
OPTIONAL { GRAPH ?tmpG { ...
Could it be safe to say that the BIND variable is floating if any of the
expression variables is floating and otherwise make it fixed ?
And modify the CanFlowResultsToRhs l.312 into
if (rhsFloating.Any(v => lhsFloating.Contains(v) /* || lhsFixed.Contains(v)
*/ )) return false;
This seems to do the trick in my case.
Max.
2015-05-28 15:32 GMT+02:00 Rob Vesse <rv...@do...>:
> Comments inline
>
>
> From: Max - Micrologiciel <ma...@mi...>
> Date: Thursday, 28 May 2015 13:36
> To: Rob Vesse <rv...@do...>
> Cc: dotNetRDF Developer Discussion and Feature Request <
> dot...@li...>
> Subject: Re: About PR#36
>
> Sorry but I missed the conclusion of the demonstration :
>
> This to show that after a variable is defined by a BIND statement it
> should not be considered as a floating variable.
>
>
> However your conclusion about floating variables and BIND is wrong at
> least according to how we define and use the concept of a floating variable
> within the Leviathan engine
>
> A floating variable is a variable whose value is not guaranteed to be
> bound which as I pointed out is the exact definition of a BIND variable,
> the expression could error and so the variable could be unbound
>
>
>
> To my understanding, the only floating variables to be considered should
> come from VALUES clauses.
>
>
> Floating variables can come from BIND, OPTIONAL, VALUES, SELECT
> expressions, aggregates I.e. anywhere where an expression is evaluated or
> where it is possible to have unbound values
>
>
> Max.
>
> 2015-05-28 14:31 GMT+02:00 Max - Micrologiciel <ma...@mi...>:
>
>> Rob,
>>
>> thanks for the answers.
>>
>> Concerning the extend case, I then definitely believe there is a flaw in
>> our evaluation logic.
>> *To me, the join operation should behave as it would in relational logic
>> meaning comparing NULL with NULL will always return false so no result.*
>>
>
> It already does, you seem to be conflating joins with left joins
> (OPTIONAL) and the two are not the same
>
>
>> Here's my demonstration of the case.
>>
>> First about the join evaluation, based on the recommendation we get :
>>
>> 1. §18.5 : Join(Ω1, Ω2) = { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and
>> μ1 and μ2 are compatible }
>> 2. $18.3 : Two solution mappings μ1 and μ2 are compatible if, for
>> every variable v in dom(μ1) and in dom(μ2), μ1(v) = μ2(v)
>> Here, μ1(v) = μ2(v) means that μ1(v) and μ2(v) are the same RDF term.
>>
>> Inferred from this the join definition would be equivalent to Join(Ω1, Ω2)
>> = { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and for each variable v in
>> intersect(dom(μ1) dom(μ2)) sameterm(μ1(v), μ2(v)) is true }
>> which means the join
>>
>> ?s ?p1 ?o1 .
>> ?s ?p2 ?o2
>>
>> is equivalent to
>>
>> ?s1 ?p1 ?o1 .
>> ?s2 ?p2 ?o2
>> FILTER (sameterm(s1,s2)
>>
>> But we also have :
>>
>> 1. $17 Specifically, FILTERs eliminate any solutions that, when
>> substituted into the expression, either result in an effective boolean
>> value of false or produce an error.
>> 2. §17.2 sameterm will produce a type error if any arguments are
>> unbound
>>
>>
>> Then about the extend case, let's say we have this graph pattern:
>>
>> ?s ?p ?o . FILTER(isLiteral(?o))
>> ?s2 ?p2 ?o2 .
>>
>> The evaluation will return a cross join of both triple pattern mutlisets
>> since according to $18.3, they are compatible because having no common
>> variable.
>>
>> On the other hand, given the following pattern,
>>
>> {?s ?p ?o . FILTER(isBlank(?o)) }
>> BIND (iri(?o) as ?s2) .
>> ?s2 ?p2 ?o2
>>
>> Under your logic, the join would return me the same results since iri(?o)
>> will produce a type error ?o being a blank node which is not accepted by
>> the Iri function.
>>
>
> Nowhere did I say this
>
> With regards to index joins we were talking specifically about the case of
> a BIND being on the LHS of an OPTIONAL which is completely different
> because left joins are not commutative
>
> Rob
>
>
>>
>> I do not agree with this since :
>>
>> 1. §10.1 Use of BIND ends the preceding basic graph pattern.
>> 2. If the evaluation of the expression produces an error, the
>> variable remains unbound for that solution but the query evaluation
>> continues.
>>
>> Which means to me that in fact we now have to perform a join between the
>> two mutlisets μ1[?s ?p ?o ?s2] and μ2[?s2 ?p2 ?o2]
>>
>>
>> So still according to §18.5 and §18.3, both multisets are then now
>> incompatible since they share the ?s2 variable which can not be compared
>> under the sameterm conditions.
>>
>> Thus We should get no result back from the query.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2015-05-28 12:50 GMT+02:00 Rob Vesse <rv...@do...>:
>>
>>> Max
>>>
>>> Comments inline:
>>>
>>> From: Max - Micrologiciel <ma...@mi...>
>>> Date: Wednesday, 27 May 2015 13:48
>>> To: Rob Vesse <rv...@do...>
>>> Subject: About PR#36
>>>
>>> Hi Rob,
>>>
>>> just been reviewing some comment you made in the #36 PR
>>> <https://bitbucket.org/dotnetrdf/dotnetrdf/pull-request/36/new-spin-library> about
>>> a change I made at first with the order of join arguments between the
>>> query's algebra and any possible BindingPattern.
>>>
>>> You wrote :
>>> "Though I think our handling of VALUES may already be broken in some
>>> cases anyway e.g. interaction with GROUP BY"
>>>
>>> Would you have some example that exposes the problem, so I can have a
>>> look into it ?
>>>
>>>
>>> If memory serves the problem is that we apply VALUES too soon. It
>>> should apply after any GROUP BY, HAVING and SELECT expressions but we apply
>>> it before those. This is a fairly trivial fix which I simply haven't got
>>> round to because it is a rare enough case that nobody has ever complained
>>> that it is broken (NB - It's fixed in the new Medusa engine on the 1.9
>>> branch)
>>>
>>>
>>>
>>> On the other hand, I do not agree with you when you say that inverting
>>> the join parameters would break our compliance with the spec : since the
>>> join operation is normally commutative (and neither does the recommendation
>>> specifies explicitly in which order the sets are to be joined), we should
>>> be able to join the arguments in both orders and get the same results .
>>>
>>>
>>> In principal yes, however once you start doing indexed joins this does
>>> have the potential to break things if you aren't careful though we are
>>> fairly careful these days so probably doesn't make a difference nowadays
>>>
>>> Moreover, evaluating the bindings first could also lead to better
>>> performances since bound variables injection into the RHS whenever possible
>>> would lighten the multiset to join with.
>>>
>>> There is also an issue I encountered and I'd like to discuss with the
>>> Extend algebra.
>>> When used as a left join LHS, it prevents injecting the bound variables
>>> into the Rhs due to the CanFlowResultsToRhs workings and how the extended
>>> variable is always treated as floating.
>>>
>>>
>>> Well anything introduced by Extend always has to be treated as floating
>>> because the expression could produce an error or an unbound value
>>>
>>> There are a couple of cases when the expression is a constant value or a
>>> copy of a variable (provided we know that variable to be fixed) that we
>>> could special case but otherwise we can't do anything more.
>>>
>>> If you are generating Extends simply to introduce constants generating
>>> Values instead may be a better approach and will benefit from index joins
>>> as you note.
>>>
>>> Rob
>>>
>>>
>>> Perhaps it would be better to discuss these live, if you're available ?
>>>
>>> Cheers,
>>> Max.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> dotNetRDF-develop mailing list
> dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>
>
|
|
From: Rob V. <rv...@do...> - 2015-05-28 13:33:06
|
Comments inline
From: Max - Micrologiciel <ma...@mi...>
Date: Thursday, 28 May 2015 13:36
To: Rob Vesse <rv...@do...>
Cc: dotNetRDF Developer Discussion and Feature Request
<dot...@li...>
Subject: Re: About PR#36
> Sorry but I missed the conclusion of the demonstration :
>
> This to show that after a variable is defined by a BIND statement it should
> not be considered as a floating variable.
However your conclusion about floating variables and BIND is wrong at least
according to how we define and use the concept of a floating variable within
the Leviathan engine
A floating variable is a variable whose value is not guaranteed to be bound
which as I pointed out is the exact definition of a BIND variable, the
expression could error and so the variable could be unbound
>
>
> To my understanding, the only floating variables to be considered should come
> from VALUES clauses.
Floating variables can come from BIND, OPTIONAL, VALUES, SELECT expressions,
aggregates I.e. anywhere where an expression is evaluated or where it is
possible to have unbound values
>
> Max.
>
> 2015-05-28 14:31 GMT+02:00 Max - Micrologiciel <ma...@mi...>:
>> Rob,
>>
>> thanks for the answers.
>>
>> Concerning the extend case, I then definitely believe there is a flaw in our
>> evaluation logic.
>> To me, the join operation should behave as it would in relational logic
>> meaning comparing NULL with NULL will always return false so no result.
It already does, you seem to be conflating joins with left joins (OPTIONAL)
and the two are not the same
>>
>> Here's my demonstration of the case.
>>
>> First about the join evaluation, based on the recommendation we get :
>> 1. §18.5 : Join(Ω1, Ω2) = { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and μ1 and
>> μ2 are compatible }
>> 2.
>> 3. $18.3 : Two solution mappings μ1 and μ2 are compatible if, for every
>> variable v in dom(μ1) and in dom(μ2), μ1(v) = μ2(v)
>> 4. Here, μ1(v) = μ2(v) means that μ1(v) and μ2(v) are the same RDF term.
>> Inferred from this the join definition would be equivalent to Join(Ω1, Ω2) =
>> { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and for each variable v in
>> intersect(dom(μ1) dom(μ2)) sameterm(μ1(v), μ2(v)) is true }
>> which means the join
>>
>> ?s ?p1 ?o1 .
>> ?s ?p2 ?o2
>>
>> is equivalent to
>>
>> ?s1 ?p1 ?o1 .
>> ?s2 ?p2 ?o2
>> FILTER (sameterm(s1,s2)
>>
>> But we also have :
>> 1. $17 Specifically, FILTERs eliminate any solutions that, when substituted
>> into the expression, either result in an effective boolean value of false or
>> produce an error.
>> 2.
>> 3. §17.2 sameterm will produce a type error if any arguments are unbound
>>
>> Then about the extend case, let's say we have this graph pattern:
>>
>> ?s ?p ?o . FILTER(isLiteral(?o))
>> ?s2 ?p2 ?o2 .
>>
>> The evaluation will return a cross join of both triple pattern mutlisets
>> since according to $18.3, they are compatible because having no common
>> variable.
>>
>> On the other hand, given the following pattern,
>>
>> {?s ?p ?o . FILTER(isBlank(?o)) }
>> BIND (iri(?o) as ?s2) .
>> ?s2 ?p2 ?o2
>>
>> Under your logic, the join would return me the same results since iri(?o)
>> will produce a type error ?o being a blank node which is not accepted by the
>> Iri function.
Nowhere did I say this
With regards to index joins we were talking specifically about the case of a
BIND being on the LHS of an OPTIONAL which is completely different because
left joins are not commutative
Rob
>>
>>
>> I do not agree with this since :
>> 1. §10.1 Use of BIND ends the preceding basic graph pattern.
>> 2.
>> 3. If the evaluation of the expression produces an error, the variable
>> remains unbound for that solution but the query evaluation continues.
>> Which means to me that in fact we now have to perform a join between the two
>> mutlisets μ1[?s ?p ?o ?s2] and μ2[?s2 ?p2 ?o2]
>>>
>> So still according to §18.5 and §18.3, both multisets are then now
>> incompatible since they share the ?s2 variable which can not be compared
>> under the sameterm conditions.
>>
>> Thus We should get no result back from the query.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2015-05-28 12:50 GMT+02:00 Rob Vesse <rv...@do...>:
>>> Max
>>>
>>> Comments inline:
>>>
>>> From: Max - Micrologiciel <ma...@mi...>
>>> Date: Wednesday, 27 May 2015 13:48
>>> To: Rob Vesse <rv...@do...>
>>> Subject: About PR#36
>>>
>>>> Hi Rob,
>>>>
>>>> just been reviewing some comment you made in the #36 PR
>>>> <https://bitbucket.org/dotnetrdf/dotnetrdf/pull-request/36/new-spin-library
>>>> > about a change I made at first with the order of join arguments between
>>>> the query's algebra and any possible BindingPattern.
>>>>
>>>> You wrote :
>>>> "Though I think our handling of VALUES may already be broken in some cases
>>>> anyway e.g. interaction with GROUP BY"
>>>>
>>>> Would you have some example that exposes the problem, so I can have a look
>>>> into it ?
>>>
>>> If memory serves the problem is that we apply VALUES too soon. It should
>>> apply after any GROUP BY, HAVING and SELECT expressions but we apply it
>>> before those. This is a fairly trivial fix which I simply haven't got round
>>> to because it is a rare enough case that nobody has ever complained that it
>>> is broken (NB - It's fixed in the new Medusa engine on the 1.9 branch)
>>>
>>>>
>>>>
>>>> On the other hand, I do not agree with you when you say that inverting the
>>>> join parameters would break our compliance with the spec : since the join
>>>> operation is normally commutative (and neither does the recommendation
>>>> specifies explicitly in which order the sets are to be joined), we should
>>>> be able to join the arguments in both orders and get the same results .
>>>
>>> In principal yes, however once you start doing indexed joins this does have
>>> the potential to break things if you aren't careful though we are fairly
>>> careful these days so probably doesn't make a difference nowadays
>>>
>>>> Moreover, evaluating the bindings first could also lead to better
>>>> performances since bound variables injection into the RHS whenever possible
>>>> would lighten the multiset to join with.
>>>>
>>>> There is also an issue I encountered and I'd like to discuss with the
>>>> Extend algebra.
>>>> When used as a left join LHS, it prevents injecting the bound variables
>>>> into the Rhs due to the CanFlowResultsToRhs workings and how the extended
>>>> variable is always treated as floating.
>>>
>>> Well anything introduced by Extend always has to be treated as floating
>>> because the expression could produce an error or an unbound value
>>>
>>> There are a couple of cases when the expression is a constant value or a
>>> copy of a variable (provided we know that variable to be fixed) that we
>>> could special case but otherwise we can't do anything more.
>>>
>>> If you are generating Extends simply to introduce constants generating
>>> Values instead may be a better approach and will benefit from index joins as
>>> you note.
>>>
>>> Rob
>>>
>>>>
>>>> Perhaps it would be better to discuss these live, if you're available ?
>>>>
>>>> Cheers,
>>>> Max.
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>
|
|
From: Max - M. <ma...@mi...> - 2015-05-28 12:38:29
|
Rob,
thanks for the answers.
Concerning the extend case, I then definitely believe there is a flaw in
our evaluation logic.
*To me, the join operation should behave as it would in relational logic
meaning comparing NULL with NULL will always return false so no result.*
Here's my demonstration of the case.
First about the join evaluation, based on the recommendation we get :
1. §18.5 : Join(Ω1, Ω2) = { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and μ1
and μ2 are compatible }
2. $18.3 : Two solution mappings μ1 and μ2 are compatible if, for every
variable v in dom(μ1) and in dom(μ2), μ1(v) = μ2(v)
Here, μ1(v) = μ2(v) means that μ1(v) and μ2(v) are the same RDF term.
Inferred from this the join definition would be equivalent to Join(Ω1, Ω2)
= { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and for each variable v in
intersect(dom(μ1) dom(μ2)) sameterm(μ1(v), μ2(v)) is true }
which means the join
?s ?p1 ?o1 .
?s ?p2 ?o2
is equivalent to
?s1 ?p1 ?o1 .
?s2 ?p2 ?o2
FILTER (sameterm(s1,s2)
But we also have :
1. $17 Specifically, FILTERs eliminate any solutions that, when
substituted into the expression, either result in an effective boolean
value of false or produce an error.
2. §17.2 sameterm will produce a type error if any arguments are unbound
Then about the extend case, let's say we have this graph pattern:
?s ?p ?o . FILTER(isLiteral(?o))
?s2 ?p2 ?o2 .
The evaluation will return a cross join of both triple pattern mutlisets
since according to $18.3, they are compatible because having no common
variable.
On the other hand, given the following pattern,
{?s ?p ?o . FILTER(isBlank(?o)) }
BIND (iri(?o) as ?s2) .
?s2 ?p2 ?o2
Under your logic, the join would return me the same results since iri(?o)
will produce a type error ?o being a blank node which is not accepted by
the Iri function.
I do not agree with this since :
1. §10.1 Use of BIND ends the preceding basic graph pattern.
2. If the evaluation of the expression produces an error, the variable
remains unbound for that solution but the query evaluation continues.
Which means to me that in fact we now have to perform a join between the
two mutlisets μ1[?s ?p ?o ?s2] and μ2[?s2 ?p2 ?o2]
So still according to §18.5 and §18.3, both multisets are then now
incompatible since they share the ?s2 variable which can not be compared
under the sameterm conditions.
Thus We should get no result back from the query.
2015-05-28 12:50 GMT+02:00 Rob Vesse <rv...@do...>:
> Max
>
> Comments inline:
>
> From: Max - Micrologiciel <ma...@mi...>
> Date: Wednesday, 27 May 2015 13:48
> To: Rob Vesse <rv...@do...>
> Subject: About PR#36
>
> Hi Rob,
>
> just been reviewing some comment you made in the #36 PR
> <https://bitbucket.org/dotnetrdf/dotnetrdf/pull-request/36/new-spin-library> about
> a change I made at first with the order of join arguments between the
> query's algebra and any possible BindingPattern.
>
> You wrote :
> "Though I think our handling of VALUES may already be broken in some
> cases anyway e.g. interaction with GROUP BY"
>
> Would you have some example that exposes the problem, so I can have a look
> into it ?
>
>
> If memory serves the problem is that we apply VALUES too soon. It should
> apply after any GROUP BY, HAVING and SELECT expressions but we apply it
> before those. This is a fairly trivial fix which I simply haven't got
> round to because it is a rare enough case that nobody has ever complained
> that it is broken (NB - It's fixed in the new Medusa engine on the 1.9
> branch)
>
>
>
> On the other hand, I do not agree with you when you say that inverting the
> join parameters would break our compliance with the spec : since the join
> operation is normally commutative (and neither does the recommendation
> specifies explicitly in which order the sets are to be joined), we should
> be able to join the arguments in both orders and get the same results .
>
>
> In principal yes, however once you start doing indexed joins this does
> have the potential to break things if you aren't careful though we are
> fairly careful these days so probably doesn't make a difference nowadays
>
> Moreover, evaluating the bindings first could also lead to better
> performances since bound variables injection into the RHS whenever possible
> would lighten the multiset to join with.
>
> There is also an issue I encountered and I'd like to discuss with the
> Extend algebra.
> When used as a left join LHS, it prevents injecting the bound variables
> into the Rhs due to the CanFlowResultsToRhs workings and how the extended
> variable is always treated as floating.
>
>
> Well anything introduced by Extend always has to be treated as floating
> because the expression could produce an error or an unbound value
>
> There are a couple of cases when the expression is a constant value or a
> copy of a variable (provided we know that variable to be fixed) that we
> could special case but otherwise we can't do anything more.
>
> If you are generating Extends simply to introduce constants generating
> Values instead may be a better approach and will benefit from index joins
> as you note.
>
> Rob
>
>
> Perhaps it would be better to discuss these live, if you're available ?
>
> Cheers,
> Max.
>
>
>
>
>
>
|
|
From: Max - M. <ma...@mi...> - 2015-05-28 12:36:33
|
Sorry but I missed the conclusion of the demonstration :
This to show that after a variable is defined by a BIND statement it should
not be considered as a floating variable.
To my understanding, the only floating variables to be considered should
come from VALUES clauses.
Max.
2015-05-28 14:31 GMT+02:00 Max - Micrologiciel <ma...@mi...>:
> Rob,
>
> thanks for the answers.
>
> Concerning the extend case, I then definitely believe there is a flaw in
> our evaluation logic.
> *To me, the join operation should behave as it would in relational logic
> meaning comparing NULL with NULL will always return false so no result.*
>
> Here's my demonstration of the case.
>
> First about the join evaluation, based on the recommendation we get :
>
> 1. §18.5 : Join(Ω1, Ω2) = { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and μ
> 1 and μ2 are compatible }
> 2. $18.3 : Two solution mappings μ1 and μ2 are compatible if, for
> every variable v in dom(μ1) and in dom(μ2), μ1(v) = μ2(v)
> Here, μ1(v) = μ2(v) means that μ1(v) and μ2(v) are the same RDF term.
>
> Inferred from this the join definition would be equivalent to Join(Ω1, Ω2)
> = { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and for each variable v in
> intersect(dom(μ1) dom(μ2)) sameterm(μ1(v), μ2(v)) is true }
> which means the join
>
> ?s ?p1 ?o1 .
> ?s ?p2 ?o2
>
> is equivalent to
>
> ?s1 ?p1 ?o1 .
> ?s2 ?p2 ?o2
> FILTER (sameterm(s1,s2)
>
> But we also have :
>
> 1. $17 Specifically, FILTERs eliminate any solutions that, when
> substituted into the expression, either result in an effective boolean
> value of false or produce an error.
> 2. §17.2 sameterm will produce a type error if any arguments are
> unbound
>
>
> Then about the extend case, let's say we have this graph pattern:
>
> ?s ?p ?o . FILTER(isLiteral(?o))
> ?s2 ?p2 ?o2 .
>
> The evaluation will return a cross join of both triple pattern mutlisets
> since according to $18.3, they are compatible because having no common
> variable.
>
> On the other hand, given the following pattern,
>
> {?s ?p ?o . FILTER(isBlank(?o)) }
> BIND (iri(?o) as ?s2) .
> ?s2 ?p2 ?o2
>
> Under your logic, the join would return me the same results since iri(?o)
> will produce a type error ?o being a blank node which is not accepted by
> the Iri function.
>
> I do not agree with this since :
>
> 1. §10.1 Use of BIND ends the preceding basic graph pattern.
> 2. If the evaluation of the expression produces an error, the variable
> remains unbound for that solution but the query evaluation continues.
>
> Which means to me that in fact we now have to perform a join between the
> two mutlisets μ1[?s ?p ?o ?s2] and μ2[?s2 ?p2 ?o2]
>
>
> So still according to §18.5 and §18.3, both multisets are then now
> incompatible since they share the ?s2 variable which can not be compared
> under the sameterm conditions.
>
> Thus We should get no result back from the query.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 2015-05-28 12:50 GMT+02:00 Rob Vesse <rv...@do...>:
>
>> Max
>>
>> Comments inline:
>>
>> From: Max - Micrologiciel <ma...@mi...>
>> Date: Wednesday, 27 May 2015 13:48
>> To: Rob Vesse <rv...@do...>
>> Subject: About PR#36
>>
>> Hi Rob,
>>
>> just been reviewing some comment you made in the #36 PR
>> <https://bitbucket.org/dotnetrdf/dotnetrdf/pull-request/36/new-spin-library> about
>> a change I made at first with the order of join arguments between the
>> query's algebra and any possible BindingPattern.
>>
>> You wrote :
>> "Though I think our handling of VALUES may already be broken in some
>> cases anyway e.g. interaction with GROUP BY"
>>
>> Would you have some example that exposes the problem, so I can have a
>> look into it ?
>>
>>
>> If memory serves the problem is that we apply VALUES too soon. It should
>> apply after any GROUP BY, HAVING and SELECT expressions but we apply it
>> before those. This is a fairly trivial fix which I simply haven't got
>> round to because it is a rare enough case that nobody has ever complained
>> that it is broken (NB - It's fixed in the new Medusa engine on the 1.9
>> branch)
>>
>>
>>
>> On the other hand, I do not agree with you when you say that inverting
>> the join parameters would break our compliance with the spec : since the
>> join operation is normally commutative (and neither does the recommendation
>> specifies explicitly in which order the sets are to be joined), we should
>> be able to join the arguments in both orders and get the same results .
>>
>>
>> In principal yes, however once you start doing indexed joins this does
>> have the potential to break things if you aren't careful though we are
>> fairly careful these days so probably doesn't make a difference nowadays
>>
>> Moreover, evaluating the bindings first could also lead to better
>> performances since bound variables injection into the RHS whenever possible
>> would lighten the multiset to join with.
>>
>> There is also an issue I encountered and I'd like to discuss with the
>> Extend algebra.
>> When used as a left join LHS, it prevents injecting the bound variables
>> into the Rhs due to the CanFlowResultsToRhs workings and how the extended
>> variable is always treated as floating.
>>
>>
>> Well anything introduced by Extend always has to be treated as floating
>> because the expression could produce an error or an unbound value
>>
>> There are a couple of cases when the expression is a constant value or a
>> copy of a variable (provided we know that variable to be fixed) that we
>> could special case but otherwise we can't do anything more.
>>
>> If you are generating Extends simply to introduce constants generating
>> Values instead may be a better approach and will benefit from index joins
>> as you note.
>>
>> Rob
>>
>>
>> Perhaps it would be better to discuss these live, if you're available ?
>>
>> Cheers,
>> Max.
>>
>>
>>
>>
>>
>>
>
|
|
From: Rob V. <rv...@do...> - 2015-05-28 10:51:34
|
Max Comments inline: From: Max - Micrologiciel <ma...@mi...> Date: Wednesday, 27 May 2015 13:48 To: Rob Vesse <rv...@do...> Subject: About PR#36 > Hi Rob, > > just been reviewing some comment you made in the #36 PR > <https://bitbucket.org/dotnetrdf/dotnetrdf/pull-request/36/new-spin-library> > about a change I made at first with the order of join arguments between the > query's algebra and any possible BindingPattern. > > You wrote : > "Though I think our handling of VALUES may already be broken in some cases > anyway e.g. interaction with GROUP BY" > > Would you have some example that exposes the problem, so I can have a look > into it ? If memory serves the problem is that we apply VALUES too soon. It should apply after any GROUP BY, HAVING and SELECT expressions but we apply it before those. This is a fairly trivial fix which I simply haven't got round to because it is a rare enough case that nobody has ever complained that it is broken (NB - It's fixed in the new Medusa engine on the 1.9 branch) > > > On the other hand, I do not agree with you when you say that inverting the > join parameters would break our compliance with the spec : since the join > operation is normally commutative (and neither does the recommendation > specifies explicitly in which order the sets are to be joined), we should be > able to join the arguments in both orders and get the same results . In principal yes, however once you start doing indexed joins this does have the potential to break things if you aren't careful though we are fairly careful these days so probably doesn't make a difference nowadays > Moreover, evaluating the bindings first could also lead to better performances > since bound variables injection into the RHS whenever possible would lighten > the multiset to join with. > > There is also an issue I encountered and I'd like to discuss with the Extend > algebra. > When used as a left join LHS, it prevents injecting the bound variables into > the Rhs due to the CanFlowResultsToRhs workings and how the extended variable > is always treated as floating. Well anything introduced by Extend always has to be treated as floating because the expression could produce an error or an unbound value There are a couple of cases when the expression is a constant value or a copy of a variable (provided we know that variable to be fixed) that we could special case but otherwise we can't do anything more. If you are generating Extends simply to introduce constants generating Values instead may be a better approach and will benefit from index joins as you note. Rob > > Perhaps it would be better to discuss these live, if you're available ? > > Cheers, > Max. > > > > > |
|
From: Ron M. Z. <ro...@ze...> - 2015-05-25 02:11:33
|
+1 On Mon, May 18, 2015 at 3:26 PM, Tomasz Pluskiewicz < tom...@gm...> wrote: > +1 here too. I don't think 3.5 is relevant enough any more. > > Tom > > > On 2015-05-15 13:26, Rob Vesse wrote: > > All > > How would people feel about dropping .Net 3.5 support in future releases > (not immediately but at some point in the future)? > > With the 1.9 branch I'm trying to refactor the APIs to use more modern > .Net APIs where possible and in some cases simple useful APIs (e.g. > INotifyCollectionChanged) simply don't exist. I'd rather reduce the number > of targets we have down to just the following: > > > - .Net 4.0 > - .Net 4.0 Client Profile > - .Net PCL (Exact profile supported may change over time) > > Thoughts? > > Rob > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight.http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > > _______________________________________________ > dotNetRDF-develop mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > |
|
From: Max - M. <ma...@mi...> - 2015-05-22 21:37:35
|
Hi Rob and all,
Glad to see you merged the PR for the CORE-445 issue.
While still working on the pending SPIN PR merge and new features, I need
adding a presentation layer (i.e. template engine) to the library. It may
be most possibly SWP-based (to stay in scope), but it depends on potential
licencing issues (any opinion welcome here).
Regardless of the technology, there are some issues due to SPARQL caveats
and simple performance considerations relating to the workings and classic
use-cases of template engines :
- most templates involve hierarchical data presentation which would
require sub queries
- nested subsequent query evaluation tends to become expensive the more
data you get to display
- event when limiting results, subsequent queries requiring variable
restrictions involving blank nodes are node possible in SPARQL
After analysis, I believe it is possible to build an efficient template
engine under the following conditions:
- templates must be pre-compiled to discover any possible subsequent
fetching requirements (dependencies on blank nodes, expressions/variables
output...)
- subsequent queries involved in the template must be merged into a
single query while the results must be dispatched to the relevant display
and flow control
- templates must be converted into an .NET processable form (either
using legacy .NET databound controls or using any template engine like
razor, mustache... that can feed on the result
My questions are:
does anyone know of an accessible (licence-wise) and
simple/elegant/easy/whatever template syntax that can be used with semantic
data ?
Subsequently, does anyone know where SWP stands since TopBraid's
vocabularies are public but with no explicit licence/copyright attached ?
And last but not least : would anyone be game to work on this with me ?
Thanks for any help/proposition/advice/reference.
Cheers,
Max.
|
|
From: Tomasz P. <tom...@gm...> - 2015-05-18 19:26:31
|
+1 here too. I don't think 3.5 is relevant enough any more. Tom On 2015-05-15 13:26, Rob Vesse wrote: > All > > How would people feel about dropping .Net 3.5 support in future > releases (not immediately but at some point in the future)? > > With the 1.9 branch I'm trying to refactor the APIs to use more modern > .Net APIs where possible and in some cases simple useful APIs (e.g. > INotifyCollectionChanged) simply don't exist. I'd rather reduce the > number of targets we have down to just the following: > > * .Net 4.0 > * .Net 4.0 Client Profile > * .Net PCL (Exact profile supported may change over time) > > Thoughts? > > Rob > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop |
|
From: <dot...@li...> - 2015-05-18 09:59:01
|
Send dotNetRDF-commits mailing list submissions to dot...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits or, via email, send a message with subject or body 'help' to dot...@li... You can reach the person managing the list at dot...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of dotNetRDF-commits digest..." Today's Topics: 1. commit/dotnetrdf: 2 new changesets (Bitbucket) 2. commit/dotnetrdf: rvesse: Prepare for next dev cycle (Bitbucket) 3. commit/dotnetrdf: tpluscode: Merge with default (Bitbucket) 4. commit/dotnetrdf: 6 new changesets (Bitbucket) 5. commit/dotnetrdf: rvesse: Revert incorrect merge (Bitbucket) 6. commit/dotnetrdf: 3 new changesets (Bitbucket) 7. commit/dotnetrdf: rvesse: Further expand IGraph contract test coverage, add new IGraphCapabilities API and refactor tests to check for necessary capabilities, add ReadOnlyGraph as a decorator over graphs (Bitbucket) 8. commit/dotnetrdf: rvesse: Move advanced graph operations (isomorphism, sub-graph, difference) out into extension methods to simplify the IGraph interface (Bitbucket) 9. commit/dotnetrdf: 6 new changesets (Bitbucket) ---------------------------------------------------------------------- Message: 1 Date: Fri, 20 Mar 2015 13:01:04 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/f8e62a039251/ Changeset: f8e62a039251 User: rvesse Date: 2015-03-20 12:40:47+00:00 Summary: Prepare for 1.0.8 release Affected #: 34 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/2f2c04caaf52/ Changeset: 2f2c04caaf52 User: rvesse Date: 2015-03-20 13:00:24+00:00 Summary: Added tag 1.0.8, 108 for changeset f8e62a039251 Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 2 Date: Fri, 20 Mar 2015 14:57:48 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Prepare for next dev cycle To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/ef4c8c60b64f/ Changeset: ef4c8c60b64f User: rvesse Date: 2015-03-20 14:57:22+00:00 Summary: Prepare for next dev cycle Affected #: 34 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 3 Date: Thu, 30 Apr 2015 13:12:29 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: tpluscode: Merge with default To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/adf34b5b2dad/ Changeset: adf34b5b2dad Branch: fluent-query User: tpluscode Date: 2013-07-31 16:35:18+00:00 Summary: Merge with default Affected #: 58 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 4 Date: Fri, 01 May 2015 16:41:17 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 6 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 6 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/144387d38466/ Changeset: 144387d38466 User: rvesse Date: 2015-03-12 09:49:16+00:00 Summary: Prep for another pre-release build Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/21108901ab2c/ Changeset: 21108901ab2c Branch: CORE-442 User: rvesse Date: 2015-04-07 16:32:41+00:00 Summary: Add test cases that demonstrate CORE-442 Affected #: 4 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/537a8a24bd33/ Changeset: 537a8a24bd33 Branch: CORE-442 User: rvesse Date: 2015-05-01 14:20:05+00:00 Summary: Further tests and experimental changes around CORE-442 Affected #: 4 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/9461c1da6bd5/ Changeset: 9461c1da6bd5 Branch: 1.9 User: rvesse Date: 2015-05-01 16:01:42+00:00 Summary: Remove old events API in favour of using INotifyCollectionChanged, currently only reimplemented for Triple collections Affected #: 18 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/8cfcf5ebddae/ Changeset: 8cfcf5ebddae Branch: 1.9 User: rvesse Date: 2015-05-01 16:35:25+00:00 Summary: Add a new Trie indexed triple collection Affected #: 7 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/a51c9cff068b/ Changeset: a51c9cff068b User: rvesse Date: 2015-05-01 16:40:41+00:00 Summary: Merge branch heads Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 5 Date: Fri, 01 May 2015 16:45:31 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Revert incorrect merge To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/dc3d3acd7457/ Changeset: dc3d3acd7457 User: rvesse Date: 2015-05-01 16:45:13+00:00 Summary: Revert incorrect merge Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 6 Date: Fri, 08 May 2015 12:06:30 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 3 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 3 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/9bb2be6e079e/ Changeset: 9bb2be6e079e Branch: 1.9 User: rvesse Date: 2015-05-05 19:29:55+00:00 Summary: Write BaseGraph back up with the new IEventedGraph API, add some unit tests for events Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/669da53b3cc7/ Changeset: 669da53b3cc7 Branch: 1.9 User: rvesse Date: 2015-05-06 20:36:24+00:00 Summary: Expand IEventedGraph interface, add support to WrapperGraph Affected #: 4 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/eb42c81c61be/ Changeset: eb42c81c61be Branch: 1.9 User: rvesse Date: 2015-05-08 12:06:11+00:00 Summary: Start to flesh out INodeFactory contract tests more, adjust and fix implementations appropriately Affected #: 24 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 7 Date: Fri, 08 May 2015 15:59:04 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Further expand IGraph contract test coverage, add new IGraphCapabilities API and refactor tests to check for necessary capabilities, add ReadOnlyGraph as a decorator over graphs To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e11461f6dde4/ Changeset: e11461f6dde4 Branch: 1.9 User: rvesse Date: 2015-05-08 15:58:16+00:00 Summary: Further expand IGraph contract test coverage, add new IGraphCapabilities API and refactor tests to check for necessary capabilities, add ReadOnlyGraph as a decorator over graphs Affected #: 77 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 8 Date: Fri, 15 May 2015 11:42:35 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Move advanced graph operations (isomorphism, sub-graph, difference) out into extension methods to simplify the IGraph interface To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/1a6b4a48504b/ Changeset: 1a6b4a48504b Branch: 1.9 User: rvesse Date: 2015-05-15 11:42:11+00:00 Summary: Move advanced graph operations (isomorphism, sub-graph, difference) out into extension methods to simplify the IGraph interface Affected #: 16 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 9 Date: Mon, 18 May 2015 09:58:52 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 6 new changesets To: dot...@li... Message-ID: <201...@ap...> Content-Type: text/plain; charset="utf-8" 6 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/78a6e56a5c9b/ Changeset: 78a6e56a5c9b Branch: CORE-445 User: magicmoux Date: 2015-05-05 06:07:16+00:00 Summary: new SparqlParametrizedString implementation Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/18afe3591eeb/ Changeset: 18afe3591eeb Branch: CORE-445 User: magicmoux Date: 2015-05-05 06:08:22+00:00 Summary: Fusion avec default Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/c7384dcded49/ Changeset: c7384dcded49 Branch: CORE-445 User: magicmoux Date: 2015-05-05 06:22:46+00:00 Summary: Pushing the right file... Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/0f2bb70dafab/ Changeset: 0f2bb70dafab Branch: CORE-445 User: magicmoux Date: 2015-05-05 13:47:48+00:00 Summary: Added handling for single-quote literals Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/100c1e15326c/ Changeset: 100c1e15326c Branch: CORE-445 User: magicmoux Date: 2015-05-09 06:42:25+00:00 Summary: Removed the _placeHolders collection which is not really needed Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/14f07984f649/ Changeset: 14f07984f649 User: rvesse Date: 2015-05-18 09:58:46+00:00 Summary: Merged in magicmoux/dotnetrdf/CORE-445 (pull request #37) New SparqlParameterizedString implementation Affected #: 2 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ------------------------------ _______________________________________________ dotNetRDF-commits mailing list dot...@li... https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits End of dotNetRDF-commits Digest, Vol 28, Issue 1 ************************************************ |
|
From: Max - M. <ma...@mi...> - 2015-05-18 09:39:20
|
+1 too 2015-05-18 9:47 GMT+02:00 Khalil Ahmed <ka...@ne...>: > +1 from me! > > On Fri, May 15, 2015 at 12:26 PM, Rob Vesse <rv...@do...> wrote: > > All > > > > How would people feel about dropping .Net 3.5 support in future releases > > (not immediately but at some point in the future)? > > > > With the 1.9 branch I'm trying to refactor the APIs to use more modern > .Net > > APIs where possible and in some cases simple useful APIs (e.g. > > INotifyCollectionChanged) simply don't exist. I'd rather reduce the > number > > of targets we have down to just the following: > > > > .Net 4.0 > > .Net 4.0 Client Profile > > .Net PCL (Exact profile supported may change over time) > > > > Thoughts? > > > > Rob > > > > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > > Widest out-of-the-box monitoring support with 50+ applications > > Performance metrics, stats and reports that give you Actionable Insights > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > _______________________________________________ > > 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 > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > |
|
From: Khalil A. <ka...@ne...> - 2015-05-18 08:15:15
|
+1 from me! On Fri, May 15, 2015 at 12:26 PM, Rob Vesse <rv...@do...> wrote: > All > > How would people feel about dropping .Net 3.5 support in future releases > (not immediately but at some point in the future)? > > With the 1.9 branch I'm trying to refactor the APIs to use more modern .Net > APIs where possible and in some cases simple useful APIs (e.g. > INotifyCollectionChanged) simply don't exist. I'd rather reduce the number > of targets we have down to just the following: > > .Net 4.0 > .Net 4.0 Client Profile > .Net PCL (Exact profile supported may change over time) > > Thoughts? > > Rob > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > 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: Rob V. <rv...@do...> - 2015-05-15 11:27:11
|
All How would people feel about dropping .Net 3.5 support in future releases (not immediately but at some point in the future)? With the 1.9 branch I'm trying to refactor the APIs to use more modern .Net APIs where possible and in some cases simple useful APIs (e.g. INotifyCollectionChanged) simply don't exist. I'd rather reduce the number of targets we have down to just the following: * .Net 4.0 * .Net 4.0 Client Profile * .Net PCL (Exact profile supported may change over time) Thoughts? Rob |
|
From: Max - M. <ma...@mi...> - 2015-05-05 06:39:01
|
Hi Rob, I finally could solve my branching issue so I finally sent a separate pull request for the new SparqlParameterizedString implementation. Max. 2015-05-04 10:46 GMT+02:00 Max - Micrologiciel <ma...@mi...>: > Hi Rob, > > Well, my first try at branching and I think I messed up my repo... (too > old for this s** ;) ) > Bitbucket won't let me create a new branch in my repository and I don't > have time to address this now. So I'll let you handle this, > > I join the new implementation of the SparqlParametrizedString along with a > basic test suite. > > You'll see that I abandoned the Regex approach within ToString and > replaced it with lightweight string processing on command text updates. > This also allows not to capture any constant SPARQL parameter- or > variable-like patterns (in-text language tags, @ or ? patterns in string > literals and Iris...) should they occur. > > You may want to check the _invalidIRICharacters and quote handling are > correct. > > After some tries, I dropped the cache idea since look-ups were too > consuming. > That surely came from the way I handled this but caching is not my forte > so I'll leave this part to anybody willing to handle this. > The performance boost is however already consequent since a ~170kB command > with 3k variables was processed by the original implementation in ~20s on > my machine. The test suite drops down to <10ms on average. > > > Cheers, > Max. > > > > |
|
From: Max - M. <ma...@mi...> - 2015-05-04 09:14:03
|
/*
dotNetRDF is free and open source software licensed under the MIT License
-----------------------------------------------------------------------------
Copyright (c) 2009-2012 dotNetRDF Project (dot...@li...)
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is furnished
to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Text.RegularExpressions;
using VDS.RDF.Parsing;
using VDS.RDF.Parsing.Handlers;
using VDS.RDF.Query.Patterns;
using VDS.RDF.Update;
using VDS.RDF.Writing.Formatting;
namespace VDS.RDF.Query
{
/// <summary>
/// A SPARQL Parameterized String is a String that can contain parameters in the same fashion as a SQL command string
/// </summary>
/// <remarks>
/// <para>
/// This is intended for use in applications which may want to dynamically build SPARQL queries/updates where user input may comprise individual values in the triples patterns and the applications want to avoid SPARQL injection attacks which change the meaning of the query/update
/// </para>
/// <para>
/// It works broadly in the same way as a SqlCommand would in that you specify a string with paramters specified in the form <strong>@name</strong> and then use various set methods to set the actual values that should be used. The values are only substituted for parameters when you actually call the <see cref="SparqlParameterizedString.ToString">ToString()</see> method to get the final string representation of the command. E.g.
/// </para>
/// <code>
/// SparqlParameterizedString queryString = new SparqlParameterizedString();
/// queryString.CommandText = @"SELECT * WHERE
/// {
/// ?s a @type .
/// }";
/// queryString.SetUri("type", new Uri("http://example.org/myType"));
/// Console.WriteLine(queryString.ToString());
/// </code>
/// <para>
/// Would result in the following being printed to the Console:
/// </para>
/// <code>
/// SELECT * WHERE
/// {
/// ?s a <http://example.org/myType>
/// }
/// </code>
/// <para>
/// Calling a Set method to set a parameter that has already been set changes that value and the new value will be used next time you call <see cref="SparqlParameterizedString.ToString">ToString()</see> - this may be useful if you plan to execute a series of queries/updates using a series of values since you need not instantiate a completely new parameterized string each time
/// </para>
/// <para>
/// This class was added to a library based on a suggestion by Alexander Sidorov and ideas from slides from <a href="http://www.slideshare.net/Morelab/sparqlrdqlsparul-injection">Slideshare</a> by Almedia et al
/// </para>
/// <para>
/// <strong>PERFORMANCE TIPS:</strong> if building the command text incrementaly, avoid using <c> CommandText += </c> and use the AppendSubQuery or Append methods instead
/// </para>
/// </remarks>
public class SparqlParameterizedString
{
private static char[] _invalidIRICharacters = " >\"{}|^`[]".ToCharArray();
private static readonly IGraph _g = new NonIndexedGraph();
private static readonly SparqlFormatter _emptyFormatter = new SparqlFormatter();
private INamespaceMapper _nsmap = new NamespaceMapper(true);
private List<String> _commandText = new List<String>();
private HashSet<int> _placeHolders = new HashSet<int>();
private readonly Dictionary<String, INode> _parameters = new Dictionary<string, INode>();
private readonly Dictionary<String, INode> _variables = new Dictionary<string, INode>();
private SparqlFormatter _formatter;
private ISparqlQueryProcessor _queryProcessor;
private ISparqlUpdateProcessor _updateProcessor;
private static Regex ValidParameterNamePattern = new Regex("^@?[\\w\\-_]+$", RegexOptions.IgnoreCase);
private static Regex ValidVariableNamePattern = new Regex("^[?$]?[\\w\\-_]+$", RegexOptions.IgnoreCase);
private static Regex PreambleCapturePattern = new Regex("(BASE|PREFIX\\s+([\\w\\-_]+):)\\s*<([^>]+)>", RegexOptions.IgnoreCase);
/// <summary>
/// Creates a new empty parameterized String
/// </summary>
public SparqlParameterizedString()
{
_formatter = new SparqlFormatter(_nsmap);
}
/// <summary>
/// Creates a new parameterized String
/// </summary>
/// <param name="command">Command Text</param>
public SparqlParameterizedString(String command)
: this()
{
this.CommandText = command;
}
/// <summary>
/// Gets/Sets the Namespace Map that is used to prepend PREFIX declarations to the command
/// </summary>
public INamespaceMapper Namespaces
{
get
{
return this._nsmap;
}
set
{
if (value != null) this._nsmap = value;
}
}
/// <summary>
/// Gets/Sets the Base URI which will be used to prepend BASE declarations to the command
/// </summary>
public Uri BaseUri { get; set; }
/// <summary>
/// Gets/Sets the parameterized Command Text
/// </summary>
public virtual String CommandText
{
get
{
#if NET40 || SILVERLIGHT || WINDOWS_PHONE
return String.Join("", _commandText);
#else
return String.Join("", _commandText.ToArray());
#endif
}
set
{
ResetText();
PreprocessText(TrimPreamble(value)); // TODO deprecate the _command field and replace it with the join of _cache
}
}
#region Sparql extension methods
/// <summary>
/// Appends the given query as a sub-query to the existing command text, any prefixes in the sub-query are moved to the parent query
/// </summary>
/// <param name="query">Query</param>
public void AppendSubQuery(SparqlQuery query)
{
PreprocessText(TrimPreamble(_emptyFormatter.Format(new SubQueryPattern(query))));
// NOTE: the namespaces are already updated through during the TrimPreambule call
}
/// <summary>
/// Appends the given query as a sub-query to the existing command text, any prefixes in the sub-query are moved to the parent query but any parameter/variable assignments will be lost
/// </summary>
/// <param name="query">Query</param>
public void AppendSubQuery(SparqlParameterizedString query)
{
// TODO shouldn't we ensure that the text is wrapped in { } to get a correct subquery pattern ?
// this may cause compatibility issues though
Append(query);
}
/// <summary>
/// Appends the given text to the existing command text, any prefixes in the sub-query are moved to the parent query but any parameter/variable assignments will be lost
/// </summary>
/// <param name="text">Text</param>
public void Append(SparqlParameterizedString text)
{
// Merges the instances caches and placeholders
int offset = _commandText.Count;
_placeHolders.UnionWith(text._placeHolders.Select(index => index + offset));
_commandText.AddRange(text._commandText);
// Update the namespaces
_nsmap.Import(text.Namespaces);
}
/// <summary>
/// Appends the given text to the existing command text, any prefixes in the command are moved to the parent query
/// </summary>
/// <param name="text">Text</param>
public void Append(String text)
{
PreprocessText(TrimPreamble(text));
}
#endregion
/// <summary>
/// Gets/Sets the Query processor which is used when you call the <see cref="SparqlParameterizedString.ExecuteQuery()">ExecuteQuery()</see> method
/// </summary>
public ISparqlQueryProcessor QueryProcessor
{
get
{
return this._queryProcessor;
}
set
{
this._queryProcessor = value;
}
}
/// <summary>
/// Gets/Sets the Query processor which is used when you call the <see cref="SparqlParameterizedString.ExecuteUpdate()">ExecuteUpdate()</see> method
/// </summary>
public ISparqlUpdateProcessor UpdateProcessor
{
get
{
return this._updateProcessor;
}
set
{
this._updateProcessor = value;
}
}
/// <summary>
/// Gets an enumeration of the Variables for which Values have been set
/// </summary>
public IEnumerable<KeyValuePair<String, INode>> Variables
{
get
{
return this._variables;
}
}
/// <summary>
/// Gets an enumeration of the Parameters for which Values have been set
/// </summary>
public IEnumerable<KeyValuePair<String, INode>> Parameters
{
get
{
return this._parameters;
}
}
#region Parameters and Variables assignment methods
/// <summary>
/// Clears all set Parameters and Variables
/// </summary>
public virtual void Clear()
{
this.ClearParameters();
this.ClearVariables();
}
/// <summary>
/// Clears all set Parameters
/// </summary>
public virtual void ClearParameters()
{
this._parameters.Clear();
}
/// <summary>
/// Clears all set Variables
/// </summary>
public virtual void ClearVariables()
{
this._variables.Clear();
}
/// <summary>
/// Sets the Value of a Parameter
/// </summary>
/// <param name="name">Parameter Name</param>
/// <param name="value">Value</param>
/// <remarks>
/// Can be used in derived classes to set the value of parameters if the derived class defines additional methods for adding values for parameters
/// </remarks>
public void SetParameter(String name, INode value)
{
if (value == null)
{
UnsetParameter(name);
return;
}
//Only allow the setting of valid parameter names
if (!ValidParameterNamePattern.IsMatch(name)) throw new FormatException("The parameter name '" + name + "' is not a valid parameter name, parameter names must consist only of alphanumeric characters and hypens/underscores");
//OPT: Could ensure that the parameter name actually appears in the command?
name = !Char.IsLetterOrDigit(name[0]) ? name.Substring(1) : name;
//Finally can set/update parameter value
this._parameters[name] = value;
}
/// <summary>
/// Removes a previously set value for a Parameter
/// </summary>
/// <param name="name">Parameter Name</param>
/// <remarks>
/// There is generally no reason to do this since you can just set a parameters value to change it
/// </remarks>
public void UnsetParameter(String name)
{
if (name == null) return;
name = !Char.IsLetterOrDigit(name[0]) ? name.Substring(1) : name;
this._parameters.Remove(name);
}
/// <summary>
/// Removes a previously set value for a Variable
/// </summary>
/// <param name="name">Variable Name</param>
/// <remarks>
/// May be useful if you have a skeleton query/update into which you sometimes substitute values for variables but don't always do so
/// </remarks>
public void UnsetVariable(String name)
{
if (name == null) return;
name = !Char.IsLetterOrDigit(name[0]) ? name.Substring(1) : name;
this._variables.Remove(name);
}
/// <summary>
/// Sets the Value of a Variable
/// </summary>
/// <param name="name">Variable Name</param>
/// <param name="value">Value</param>
public virtual void SetVariable(String name, INode value)
{
if (value == null)
{
UnsetVariable(name);
return;
}
//Only allow the setting of valid variable names
if (!ValidVariableNamePattern.IsMatch(name)) throw new FormatException("The variable name '" + name + "' is not a valid variable name, variable names must consist only of alphanumeric characters and hyphens/underscores");
//OPT: Could ensure that the variable name actually appears in the command?
name = !Char.IsLetterOrDigit(name[0]) ? name.Substring(1) : name;
this._variables[name] = value;
}
/// <summary>
/// Sets the Parameter to an Integer Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
public void SetLiteral(String name, int value)
{
this.SetParameter(name, value.ToLiteral(_g));
}
/// <summary>
/// Sets the Parameter to an Integer Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
public void SetLiteral(String name, long value)
{
this.SetParameter(name, value.ToLiteral(_g));
}
/// <summary>
/// Sets the Parameter to an Integer Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
public void SetLiteral(String name, short value)
{
this.SetParameter(name, value.ToLiteral(_g));
}
/// <summary>
/// Sets the Parameter to a Decimal Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
public void SetLiteral(String name, decimal value)
{
this.SetParameter(name, value.ToLiteral(_g));
}
/// <summary>
/// Sets the Parameter to a Float Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
public void SetLiteral(String name, float value)
{
this.SetParameter(name, value.ToLiteral(_g));
}
/// <summary>
/// Sets the Parameter to a Double Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
public void SetLiteral(String name, double value)
{
this.SetParameter(name, value.ToLiteral(_g));
}
/// <summary>
/// Sets the Parameter to a Date Time Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
public void SetLiteral(String name, DateTime value)
{
this.SetLiteral(name, value, true);
}
/// <summary>
/// Sets the Parameter to a Date Time Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
/// <param name="precise">Whether to preserve precisely i.e. include fractional seconds</param>
public void SetLiteral(String name, DateTime value, bool precise)
{
this.SetParameter(name, value.ToLiteral(_g, precise));
}
/// <summary>
/// Sets the Parameter to a Date Time Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
public void SetLiteral(String name, DateTimeOffset value)
{
this.SetLiteral(name, value, true);
}
/// <summary>
/// Sets the Parameter to a Date Time Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
/// <param name="precise">Whether to preserve precisely i.e. include fractional seconds</param>
public void SetLiteral(String name, DateTimeOffset value, bool precise)
{
this.SetParameter(name, value.ToLiteral(_g, precise));
}
/// <summary>
/// Sets the Parameter to a Duration Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
public void SetLiteral(String name, TimeSpan value)
{
this.SetParameter(name, value.ToLiteral(_g));
}
/// <summary>
/// Sets the Parameter to a Boolean Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
public void SetLiteral(String name, bool value)
{
this.SetParameter(name, value.ToLiteral(_g));
}
/// <summary>
/// Sets the Parameter to an Untyped Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
public void SetLiteral(String name, String value)
{
if (value == null) throw new ArgumentNullException("value", "Cannot set a Literal to be null");
this.SetParameter(name, new LiteralNode(_g, value));
}
/// <summary>
/// Sets the Parameter to a Typed Literal
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
/// <param name="datatype">Datatype URI</param>
public void SetLiteral(String name, String value, Uri datatype)
{
if (value == null) throw new ArgumentNullException("value", "Cannot set a Literal to be null");
this.SetParameter(name, datatype == null ? new LiteralNode(_g, value) : new LiteralNode(_g, value, datatype));
}
/// <summary>
/// Sets the Parameter to a Literal with a Language Specifier
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Integer</param>
/// <param name="lang">Language Specifier</param>
public void SetLiteral(String name, String value, String lang)
{
if (value == null) throw new ArgumentNullException("value", "Cannot set a Literal to be null");
if (lang == null) throw new ArgumentNullException("lang", "Cannot set a Literal to have a null Language");
this.SetParameter(name, new LiteralNode(_g, value, lang));
}
/// <summary>
/// Sets the Parameter to a URI
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">URI</param>
public void SetUri(String name, Uri value)
{
if (value == null) throw new ArgumentNullException("value", "Cannot set a URI to be null");
this.SetParameter(name, new UriNode(_g, value));
}
/// <summary>
/// Sets the Parameter to be a Blank Node with the given ID
/// </summary>
/// <param name="name">Parameter</param>
/// <param name="value">Node ID</param>
/// <remarks>
/// Only guarantees that the Blank Node ID will not clash with any other Blank Nodes added by other calls to this method or it's overload which generates anonymous Blank Nodes. If the base query text into which you are inserting parameters contains Blank Nodes then the IDs generated here may clash with those IDs.
/// </remarks>
public void SetBlankNode(String name, String value)
{
if (value == null) throw new ArgumentNullException("value", "Cannot set a Blank Node to have a null ID");
if (value.Equals(String.Empty)) throw new ArgumentException("Cannot set a Blank Node to have an empty ID", "value");
this.SetParameter(name, _g.CreateBlankNode(value));
}
/// <summary>
/// Sets the Parameter to be a new anonymous Blank Node
/// </summary>
/// <param name="name">Parameter</param>
/// <remarks>
/// Only guarantees that the Blank Node ID will not clash with any other Blank Nodes added by other calls to this method or it's overload which takes an explicit Node ID. If the base query text into which you are inserting parameters contains Blank Nodes then the IDs generated here may clash with those IDs.
/// </remarks>
public void SetBlankNode(String name)
{
this.SetParameter(name, _g.CreateBlankNode());
}
#endregion
#region Runtime Evaluation
/// <summary>
/// Executes this command as a query
/// </summary>
/// <returns></returns>
public SparqlResultSet ExecuteQuery()
{
SparqlResultSet rset = new SparqlResultSet();
this.ExecuteQuery(null, new ResultSetHandler(rset));
return rset;
}
/// <summary>
/// Executes this command as a query
/// </summary>
/// <param name="rdfHandler">RDF Handler</param>
/// <param name="resultsHandler">Results Handler</param>
public void ExecuteQuery(IRdfHandler rdfHandler, ISparqlResultsHandler resultsHandler)
{
if (this._queryProcessor == null) throw new RdfQueryException("Cannot call ExecuteQuery() when the QueryProcessor property has not been set");
SparqlQueryParser parser = new SparqlQueryParser();
SparqlQuery q = parser.ParseFromString(this.ToString());
this._queryProcessor.ProcessQuery(rdfHandler, resultsHandler, q);
}
/// <summary>
/// Executes this command as an update
/// </summary>
public void ExecuteUpdate()
{
if (this._updateProcessor == null) throw new SparqlUpdateException("Cannot call ExecuteUpdate() when the UpdateProcessor property has not been set");
SparqlUpdateParser parser = new SparqlUpdateParser();
SparqlUpdateCommandSet cmds = parser.ParseFromString(this.ToString());
this._updateProcessor.ProcessCommandSet(cmds);
}
#endregion
#region Command text processing and Serialization
/// <summary>
/// Clears the preprocessing structures
/// </summary>
private void ResetText()
{
this._placeHolders.Clear();
this._commandText.Clear();
}
/// <summary>
/// Trims out the SPARQL preamble (BASE and PREFIX definitions) from the command text
/// </summary>
/// <remarks>
/// This is done so the instance can be directly merged into another SparqlParameterizedString through the Append methods
/// </remarks>
private String TrimPreamble(String value)
{
int commandStart = 0;
foreach (Match preambleItem in PreambleCapturePattern.Matches(value))
{
if (preambleItem.Groups[1].Value.ToUpper().StartsWith("BASE"))
{
this.BaseUri = UriFactory.Create(preambleItem.Groups[1].Value);
this.Namespaces.AddNamespace("", this.BaseUri);
}
else
{
this.Namespaces.AddNamespace(preambleItem.Groups[2].Value, UriFactory.Create(preambleItem.Groups[3].Value));
}
commandStart = preambleItem.Index + preambleItem.Length;
}
return value.Substring(commandStart);
}
/// <summary>
/// Provides some fast string exploration to determine valid parameter/variable placeholders and leave out any constant SPARQL ambiguous patterns (language tags, parameter- or variable-like patterns in IRIs or in string literals...)
/// </summary>
private void PreprocessText(String value)
{
bool inIri = false;
bool inLiteral = false;
bool inLongLiteral = false;
bool escaping = false;
StringBuilder currentSegment = new StringBuilder();
for (int i = 0, l = value.Length; i < l; i++)
{
char c = value[i];
switch (c)
{
case '\\':
if (inLiteral)
{
escaping = !escaping;
}
break;
case '"':
if (!inLiteral)
{
inLiteral = true;
if (i < l - 2 && value[i + 1] == c && value[i + 2] == c)
{
inLongLiteral = true;
currentSegment.Append(c, 2);
i += 2;
}
}
else if (!escaping)
{
if (!inLongLiteral)
{
inLiteral = false;
}
else if (i < l - 2 && value[i + 1] == c && value[i + 2] == c)
{
inLongLiteral = false;
currentSegment.Append(c, 2);
i += 2;
}
}
break;
case '<':
// toggle whether me may start a Iri or break one
inIri = !inIri;
break;
case '@':
case '$':
case '?':
if (!inLiteral && !inIri)
{
if (c == '@' && i > 0 && value[i - 1] == '"')
{
// encountered a language tag => do nothing
}
else if (c == '?' && i < l && !Char.IsLetterOrDigit(value[i + 1]))
{
// must be a propertyPath ? modifier => do nothing
}
else
{
// Start variable or parameter capture
_commandText.Add(currentSegment.ToString());
#if NET40 || SILVERLIGHT || WINDOWS_PHONE
currentSegment.Clear();
#else
currentSegment = new StringBuilder();
#endif
currentSegment.Append(c);
// Capture the identifier
for (int idCharIndex = i + 1; idCharIndex < l; idCharIndex++)
{
char idc = value[idCharIndex];
i = idCharIndex;
//check that the character is in valid identifier range
if (Char.IsLetterOrDigit(idc) || idc == '-' || idc == '_')
{
currentSegment.Append(idc);
}
else
{
break;
}
}
// stop the capture and tag a placeHolder
// TODO should we check that the identifier is not empty, just to be sure ?
String assignment = currentSegment.ToString();
_placeHolders.Add(_commandText.Count);//, assignment);
_commandText.Add(assignment);
#if NET40 || SILVERLIGHT || WINDOWS_PHONE
currentSegment.Clear();
#else
currentSegment = new StringBuilder();
#endif
// Add the last character found (if any) to the new segment, since it is not part of the variable or parameter name
if (i<l-1) currentSegment.Append(value[i]);
// nothing more to do here
continue;
}
}
break;
default:
if (inIri)
{
// check wether the character is a valid in IRIs
// TODO validate that the char array is correct
if (Char.IsControl(c) || _invalidIRICharacters.Contains(c))
{
inIri = false;
}
}
break;
}
currentSegment.Append(c);
}
_commandText.Add(currentSegment.ToString());
}
/// <summary>
/// Returns the actual Query/Update String with parameter and variable values inserted
/// </summary>
/// <returns></returns>
public override string ToString()
{
StringBuilder output = new StringBuilder();
// First prepend Base declaration
if (this.BaseUri != null)
{
output.AppendLine("BASE <" + this._formatter.FormatUri(this.BaseUri) + ">");
}
// Next prepend any Namespace Declarations
foreach (String prefix in this._nsmap.Prefixes)
{
output.AppendLine("PREFIX " + prefix + ": <" + this._formatter.FormatUri(this._nsmap.GetNamespaceUri(prefix)) + ">");
}
//Then append the text with variable and parameters replaced by their values if set
for (int i = 0, l = _commandText.Count; i < l; i++)
{
if (!_placeHolders.Contains(i)) {
output.Append(_commandText[i]);
}
else
{
String assignment = _commandText[i];
String name = assignment.Substring(1);
INode value = null;
switch (_commandText[i][0])
{
case '@':
this._parameters.TryGetValue(name, out value);
if (value != null)
{
output.Append(this._formatter.Format(value));
}
else
{
output.Append(assignment);
}
break;
default:
this._variables.TryGetValue(name, out value);
if (value != null)
{
output.Append(this._formatter.Format(value));
}
else
{
output.Append(assignment);
}
break;
}
}
}
return output.ToString();
}
#endregion
}
}
|
|
From: Max - M. <ma...@mi...> - 2015-04-27 16:05:28
|
Hi all, Sorry for the late reply but it's been quite hectic the past months. I finally could resolve or work around some of the issues I raised in the previous mails so I'm glad to announce that after all this time a much improved implementation has just been proposed. Hopefully, the pull request won't stay long in merging and replace the first experimental version.(? ;P ) Though there is still much work to do to reach a stable v1 state, the new API should be much more easier to work with both configuration-wise and extension-wise. It's been developped/tested against a dotNetRDF InMemory and Sesame storage (I didn't have the spare time or energy to deploy other RDF engines on my machine) so feedback would be most welcome here. Currently, some InMemory tests are expected to fail due to issues in the Leviathan engine. I'll try to address those with Rob asap. In a user POV, the library is expected to work as any standard IUpdateableStorageProvider, making all SPIN-related features transparent. In a developper/contributor POV, I'll try to provide some architecture/design/milestones documentation as soon as I can, so please feel free to ask any question meanwhile. Cheers, Max. |
48 messages has been excluded from this view by a project administrator.
