-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add RDFJS support (and update N3.js) #35
Comments
All for it. Not sure if we want to do it from C++ or JavaScript. I think the latter, so we can pass in different libs. |
True. But this would mean that, in JS, we have to loop over the result and convert the triples with for example rdf-string. Or is that not the case? |
Yeah we want to avoid that. I think the C code should emit monomorphic structured objects of the shape |
@rubensworks has made a valid remark about the |
We could achieve this by injecting a Prototype. However, we may want to consider looping after all, as this would allow us to use custom Data Factories. |
maybe something along these lines: https://github.com/nodejs/nan/blob/master/doc/methods.md#api_nan_set_prototype_method? Of course, we don't want c++ everytime |
@mielvds That's not right, that would be So we just pass in the prototype (maybe on init), and then set it on created objects. |
yes, that's it! |
@mielvds @rubensworks @RubenVerborgh
I've got the impression we've reached consensus about doing this in C++ to avoid looping over the results. I assume that means that we won't support passing different datafactory libs?
I might be missing something here. The above is not rdfjs right? Shouldnt termtype be Related to this: we'll have to do some term parsing in c++ to extract the language and type of literals. I'm assuming that using a full-fledged parser (such as serd) is overkill and would only add an extra HDT-Node dependency. Instead, we should parse the term ourselves, similar to how we do that here (only simpler, considering we can assume the term is valid)
Nice, good to see this as a reference. In our case, the equals method for terms should look something like this: function equals(lhs,rhs) {
return lhs.termType === rhs.termType && lhs.value === rhs.value && lhs.language === rhs.language && lhs.type === rhs.type
} Considering we're returning quads, we'd need to take care of returning RDFJS quads as well. Additionally, we need to pass a prototype for the quad itself, with its own equality function. |
It's not; the idea was to communicate an array of primitive types from C to JS, such that we don't repeatedly need to invoke JS constructors from C. |
What would be the argument against having an interface like this? |
👍 If consumers still want a custom datafactory, they can always just loop afterwards themselves. |
Yeah, but the idea is not the pass the returned C object directly to consumers. It's not a valid RDF/JS object currently. Rather, the values returned from C would be used in JS-land to properly instantiate objects with the right factory. And for that, an |
Can nan do this instantiation (via the a.o. |
What is the downside of returning an RDF/JS object from C instead? (given that the equals function is defined in JS)
Were you thinking about something in particular for instantiating these objects? |
How will we attach that
Looping actually; should not be that expensive given that the objects are perfectly predictable. Perhaps an array of 4 elements could even be better; we'd need performance measurements (should performance be an issue).
It's the JS/C crossings that are expensive and should be avoided. |
Isnt that what you discussed here? #35 (comment) |
That might do it indeed; but I have concerns about the performance of mixed C/JS-instantiated objects. But this could be the easiest route to try. That said, it would not be compatible with arbitrary RDF/JS factories. But good enough to start, and see what baseline performance this affords us. |
Not sure if the following useful, but I mention it here just in case. |
If what you're looking for is a baseline, and you suspect looping is more efficient than creating these objects in c, wouldn't the easiest baseline be an implementation where we only touch the js part? Ie, create the terms and quads by looping over the results, and extract the literal datatype/language tags in js? |
Actually… yes 🙂 |
I guess this issue can be closed now that #44 has been merged? |
What your take on this?
I guess this would mean changing the C++ code to return a different object structure and change
addTriples
toaddQuads
inbin/hdt
, but not much more.The text was updated successfully, but these errors were encountered: