From: Peter K. <pk...@ka...> - 2014-12-11 20:04:17
|
Thanks Rob. I’ll have a pull request to fix this immediate bug when I get the chance. I’ll try to throw together a test project to test the portable package against WinRT and/or Windows Phone 8.1 RT, as well as the minor change to enable WinRT on Windows Phone as a target. I have to admit I don’t really understand all the portable target stuff, but I guess I’ll have to learn it sometime. I’ll also dig in and make a change to the nuspec file to make it work on Universal apps (as well as the existing types), and I guess I’ll have to do the same for VDS.Common (which I wasn’t using, apparently). A quick check tells me that the only profile that supports universal apps supports only Silverlight 5, not 4. If that’s going to be a problem, I might be biting off more than I can chew, at least in the short term. If you’re looking for someone to actively manage the portable builds, that’s probably not me, as my interest and time waxes and wanes. But I’ve been on this list for a couple of years now, so I’ll try to monitor it and help out when I can. Peter Sent from Windows Mail From: Rob Vesse<mailto:rv...@do...> Sent: Thursday, December 11, 2014 05:10 To: dot...@li...<mailto:dot...@li...> Peter Question 1 It is not the query processor but the ISparqlDataset that is used to wrap the ITripleStore instance for SPARQL execution which adds the empty default graph. The SPARQL specification says queries and updates operate over a dataset which always has at least an empty default graph and possibly some named graphs so it makes logic easier elsewhere to always ensure an empty default graph is present Question 2 Yes though if it is the default graph then that could probably be omitted. In general many RDF/SPARQL systems won't necessarily support empty graphs explicitly (particularly quad oriented systems) so it would not be unreasonable to omit empty graphs entirely. Question 3 Yes it should, please submit a fix if you have time Question 4 Not necessarily, going back to Question 2 not all systems support empty graphs explicitly. Longer term I intend for dotNetRDF to become one of them so I would just ignore empty graphs in the TriX input, the DOM based parsing mode used on non-portable platforms likely already does just this. If everything is working on more platforms than we currently support it would be great to have a pull request that expands our supported .Net builds/portable profile. Personally I don't have the time/energy to keep track of all the multitude of profiles that MS keep introducing (which IMO is the single worst thing they ever did to .Net) so if you have some time to do so that'd be much appreciated. Rob From: Peter Kahle <pk...@ka...<mailto:pk...@ka...>> Reply-To: dotNetRDF Developer Discussion and Feature Request <dot...@li...<mailto:dot...@li...>> Date: Wednesday, 10 December 2014 03:32 To: "dot...@li...<mailto:dot...@li...>" <dot...@li...<mailto:dot...@li...>> Subject: [dotNetRDF-Develop] TriXWriter/Reader and Empty Graphs Hi Folks, In playing around testing against WinRT/WP 8.1 (CORE-429 ), I’ve found what I think is a bug somewhere in the portable version of the TriXWriter/Parser stack (or possibly in the SPARQL engine), but I don’t really know where to go poking to fix it. I’m querying against a TripleStore with two named graphs. This works fine, but when calling “new LeviathanQueryProcessor(myTripleStore)”, a new default graph (with a null Uri) is added to the store. Then, when I go to save the store using TriXWriter, it writes “<graph />” as the third graph element. This seems to be correct behavior to me, or at least potentially correct. Unfortunately, when I go to load the file, I see: VDS.RDF.Parsing.RdfParseException was unhandled by user code HResult=-2146233088 Message=[Source XML] Unexpected </TriX> encountered, either <triple> elements or a </graph> was expected Source=dotNetRDF EndLine=-1 EndPosition=-1 HasPositionInformation=false StartLine=-1 StartPosition=-1 StackTrace: at VDS.RDF.Parsing.TriXParser.TryParseGraph(XmlReader reader, IRdfHandler handler) at VDS.RDF.Parsing.TriXParser.TryParseGraphset(XmlReader reader, IRdfHandler handler) at VDS.RDF.Parsing.TriXParser.Load(IRdfHandler handler, TextReader input) at VDS.RDF.Parsing.TriXParser.Load(ITripleStore store, TextReader input) at TripleNote.Store.<LoadStore>d__14.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() at TripleNote.Store.<test>d__0.MoveNext() InnerException: I’m guessing this is where the problem lies, and that the correct behavior is to check if we’ve got a blank element in the TriXParser.TryParseGraph. The questions are: 1. Should LeviathanQueryProcessor add a default graph to the TripleStore? 2. Should an empty graph be written by the TriXWriter? 3. Should an empty graph be accepted by the TriXParser? I think yes. 4. If so, should it result in an empty graph in the TripleStore? This would require a change to IRdfHandler to handle this case. Incidentally, while I’m not testing it in any organized manner, all of this is working in WinRT and WP8.1 WinRT apps (a universal app, actually), including reading, writing, querying, and asserting triples. Peter Sent from Windows Mail ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ dotNetRDF-develop mailing list dot...@li...<mailto:dot...@li...> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop |