move `@smessie/eye-js` logic upstream

[jeswr]

See #5 (comment).

@smessie - I want to make sure you are comfortable with moving that code here first. If you are it would be great if you could create a PR with the code; if you're too busy I can do it myself.

[smessie]

Yes I can do that. The main reason that I created a separate package is because I wanted to make an easy drop-in replacement for my eye-mock making it easy for the developer to switch between them based on if they want it to run in the browser or on a server.
You are probably more looking towards a method name in line with the current ones rather than n3reasoner. If this assumption is right, I can choose a name more in line with the others and maybe do a PR later on after I did some more research into a uniform reasoner interface.

[jeswr]

after I did some more research into a uniform reasoner interface.

Note: rdfjs/types#26. To be perfectly frank I don't see a uniform interface existing for a while due to the large amount of variations in rule profiles; and also based on the fact that only a limited number being RDF/JS compatible (the only ones I know of I wrote):

• N3 Reasoner Class rdfjs/N3.js#296
• https://github.com/comunica/comunica-feature-reasoning

I think the best that we can do is be like the https://github.com/rdfjs/N3.js/ and create the best interface we can to meet current requirements; and that interface can then be used to drive spec decisions down the line.

[smessie]

I'm not sure if we think of the same when I say a uniform reasoner interface, so I'll try to clarify what I mean.

with a uniform reasoner face, I want to make a high level interface to define how developers can interact with any kind of reasoner, being it eye on a server, eye in the browser, roxi, ...
That protocol defines how you should pass the input and what you'll get as output. Anything in between that on how to produce that output is up to the reasoner to decide.

A simple example could be that we define it to be https://{baseUrl}?data={data-as-string-or-url-ref}&query={data-as-string-or-url-ref} or the corresponding JS interface let result = await reason(dataBlob,queryBlob)

It's about how you interact with those reasoners, not about what specific data or rules you pass along.

Later on, this could be extended with more advanced features and how you pass those to the reasoner, e.g. to get information about the specifics of the reasoner or to specify some reasoner specific configurations.

[jeswr]

It's about how you interact with those reasoners, not about what specific data or rules you pass along

I fully agree with what you're saying; and if we are talking at the level of strings/blobs for the universal interface then we are fine.

My main point is that if we want to interoperate well with the rest of the RDF/JS ecosystem then we really should have a universal/standardized interface that uses RDF/JS Quads as input/output rather than blobs (i.e. similar to the current basicQuery function); and at some point we may wish to further standardize the form that RDF/JS rules are passed around in rather than just encoding the rules in sets of quads.

[jeswr]

🎉 This issue has been resolved in version 2.10.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release
• v2.10.0

Your semantic-release bot 📦🚀