Menu
▾
▴
Re: [dotNetRDF-develop] [dotNetRDF-bugs] Bugs, problems, ideas, questions
|
From: Rob V. <rv...@do...> - 2010-02-22 11:45:02
|
Hi Alexander
2 & 4 - Ok I see your points here. I have adjusted the API so that it
takes IEnumerable<Triple> instead as of revision 626
5 - It would be better to parse the query but Virtuoso's SPARQL syntax is so
complex and extended that it is impractical to do so. I have an idea for a
way that might give more accurate query type detection in some (but still
not all) cases but I probably won't implement that for the next release
since it'll require some reworking of my SPARQL parser.
6 - From a licensing point of view I'm thinking that the Lesser GPL would be
suitable for commercial licensing. The Lesser GPL allows you to use the
library as-is in a commercial product and doesn't require you to open source
your code or allow users to redistribute your code (obviously they can still
redistributed dotNetRDF as it's still free software). If you change the
library directly then you are required to publish the changed library under
the LGPL but if you are just building stuff on top of the library then that
code can stay closed source. In order to grant you such a license there
will be a nominal license fee since it is my intention that the library
remain under the full GPL - I'm discussing with colleagues what this fee
should be. Or we may decide to move to a different license such as the BSD
license which would make it easier for people to use the API in commercial
products.
With regards to RDFa support there is an RDFa parser in the repository which
will be part of the next release which will hopefully be in the next two
weeks or so. There is also an updated HtmlWriter class which embeds the RDFa
representing the Triples it is displaying in an HTML table.
Basically I have done everything I wanted to do for the next release but
there have been some serious issues with Virtuoso 6 support which are due to
bugs in Virtuoso 6 and it's ADO.Net provider which I have been trying to
resolve with the help of my contacts at OpenLink. Until I can confirm that
their fixes work with the latest versions of my code I can't do an official
release.
Rob Vesse
From: Alexander Sidorov [mailto:ale...@gm...]
Sent: 22 February 2010 09:18
To: rv...@do...
Cc: dotNetRDF Bug Report tracking and resolution;
dot...@li...
Subject: Re: [dotNetRDF-bugs] Bugs, problems, ideas, questions
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
|
