Re: [dotNetRDF-bugs] Bugs, problems, ideas, questions

[Alexander S. <ale...@gm...>]

Hi Rob,

2. It is unreal for me to load graph, modify it and then save, because my
graph may be very and very big. What I just need is to delete or add some
triples, that's why I use Update graph method.

4. I'm not sure if I understood you right... but it looks like you don't
need to implement one more overload: you just need to change List to
IEnumerable. Generally it is a good approach to use the lowest type in
hierarchy you can (GoF book tells a lot about it). And if you are buffering
triples in lists, changin UpdateGraph method signature to IEnumerable won't
change you code logic as List implements IEnumerable.

I agree that overhead is not so much, but nevertheless I don't see any
reason to keep List variables there: UpdateGraph method implementation
doesn't need any functionality except IEnumerable provides.

5. Yes, it would be better to parse the query and check it more accurate.

6. The one reason is that I want to use dotnetRDF in my commercial project.
Also I wanted to implement RDFa publishing tool. But I read in your twitter
that you have the same plans too (haven't you started?). So we could make it
together. But as I said, first of all, I need the ability to use this code
at commercial project.

Regards,
Alexander

2010/2/21 Rob Vesse <rv...@do...>

> Hi Alexander
>
> Thanks for reporting the bugs and contributing your ideas.
>
> 1 - I have fixed this as suggested as of revision 625
>
> 2 - The UpdateGraph is intended primarily for use internally by the API, it
> happens to be a public method since it's an interface method.  It's designed
> to combine the two operations since from an IO point of view there
> operations are typically achieved via the same mechanism.  It's intended use
> is for persisting changes to Graphs as they happen, if you are making a
> fixed number/predetermined changes to a Graph then it's typically best to
> load it using the LoadGraph() method, change it then persist it back to the
> store using the SaveGraph() method.
>
> 3 - I have altered the implementation of the UpdateGraph method in all
> existing IGenericIOManager implementations so they accept null arguments for
> either list as of revision 625
>
> 4 - UpdateGraph uses lists since as I said wrt point 2 it's designed
> primarily for internal usage.  Where it's used internally we're buffering
> triples that are to be added/removed in lists and then persisting them in a
> bulk operation for efficiency purposes.  I may add an additional overload in
> the future which accepts IEnumerable<Triple> but I don't really see the
> need.
>
> With the example you gave why not just use the SaveGraph() method instead -
> I assume you're adding to an existing Graph and want to preserve what's
> already in the Graph in Virtuoso?
>
> Creating a list doesn't really have that much overhead associated with it,
> typically the triples are stored in a dictionary/hash table anyway.
> Converting an enumerable to a list doesn't actually use that much memory
> since you aren't physically copying the triples you're only creating copies
> of the references to the triples (total overhead roughly 2/4 bytes per
> triple - depends on whether you're running 32/64 bit system)
>
> 5 - Fix is applied as of revision 625 - the fix is still slightly
> unsatisfactory since what if the query is something like ASK WHERE {?select
> ?p ?o} that will be flagged as a select query when it is not.
>
> 6 - I will get back to you about licensing, I have another similar question
> from another user and I need to look into compatibility of different
> licenses before I can answer your question.  Is there any particular reason
> why you don't like the GPL?
>
> Rob Vesse
>
> ------------------------------
> *From*: "Alexander Sidorov" <ale...@gm...>
> *Sent*: Saturday, February 20, 2010 8:57 PM
> *To*: dot...@li...
> *Subject*: [dotNetRDF-bugs] Bugs, problems, ideas, questions
>
>
> Hello!
>
> 1. VirtuosoManager.LoadNode method doesn't work correctly with queries that
> contain OPTIONAL clause. Such queries return DbNull for result sets at which
> optional variables are not set. I have just added one more "else if" and it
> works nice:
>             else if (n is DBNull)
>             {
>                 temp = null;
>             }
> 2. Why not to split UpdateGraph method to AddToGraph and RemoveFromGraph
> methods? I think it would be more convenient for most usecases.
>
> 3. Method UpdateGraph (at least in VirtuosoManager) throws exception when
> removals variable is null. That's why I have to pass empty list to make my
> addition-only UpdateGraph call work. I think it would be nice to make this
> query work with additions or/and removals equal to null.
>
> 4. Why does method UpdateGraph has List<Triple> but not IEnumerable<Triple>
> parameters? It is inconvenient, for example, when I would like to save
> graph's triples:
>
>             Graph graph = new Graph();
>             RdfXmlParser parser = new RdfXmlParser();
>             parser.Load(graph, fileName);
>
>             this._virtuosoManager.
> UpdateGraph(graphUri, *graph.Triples.ToList()*, new
> List<VDS.RDF.Triple>());
>
> I have to create the list and it makes my code less efficient (imagine big
> graph).
>
> 5. VirtuosoManager.Query method contains the following code:
>
>                 else if (results.Rows.Count == 1 && results.Columns.Count
> == 1)
>                 {
>                     //Single Row and Column implies ASK/DESCRIBE/CONSTRUCT
> results
>
> I have some SELECT-queries that return one variable and sometimes one
> result. And because of the previous code my results are lost (because I
> expect my variable, but not variable called Result. I think it would be nice
> to make simple check (just search ask, describe or construct words in the
> query) to determine is this SELECT-query or not.
>
> 6. Is there any way to get dotnetRDF library (*only library*) without any
> GPL dependencies under BSD or similar license?
>
> That's all for today :)
>
> Regards,
> Alexander
>
>