Adrian, I'm not against JS per se, I'm against reinventing the bike, wasting effort and using imperative tech where declarative could do.
RDF/JS is a great initiative, as an RDF API for JS was lacking. Is it anything specific to JS though? Hardly, it's just OO interfaces and implementations. Something that Jena had for decades. What is missing is IMO an RDF graph store and a compatible SPARQL processor that run in the browser. I haven't tried Comunica yet, but I hope it fills that gap, as well as node-quadstore [1]. Even so, these projects are in their very early days, compared to a massive effort put over the years into Jena's compliance, features, bugfixes, optimizations etc. You would probably agree that we are not likely to see an OWL API or a reasoner in a JS framework any time soon? RDF and SPARQL software is not really language-dependent, and transpiling and cross-compiling techniques are quite advanced these days, so why not try to bring (parts of) Jena's time-tested codebase to the browser? Which would be virtually for free, if it's possible at all -- which is what I was wondering about. Maybe the performance would suck, I don't know. I'm personally excited about the upcoming Saxon-JS 2.0 [2]. It's a native JS implementation of XSLT 3.0 processor. JS is useful here as it's not used for the end-to-end implementation, but rather to implement a processor for a declarative technology. [1] https://github.com/beautifulinteractions/node-quadstore [2] http://www.saxonica.com/saxon-js/index.xml On Fri, May 15, 2020 at 7:54 PM Adrian Gschwend <[email protected]> wrote: > > On 15.05.20 12:39, Martynas Jusevičius wrote: > > Hi > > > RDF JavaScript frameworks are still ~20 years behind Java. So this had > > me thinking for a while -- instead of reinventing the wheel, would it > > be possible to transpile Jena to TypeScript or JavaScript? > > When my colleague sees that I answer your post he will complain that I > "feed the troll" but I'll give it a try anyway as some in here might > have missed what happened in the JS world the past few years. > > The goal of a JavaScript ecosystem for should be to be as close to what > JavaScript/Web developers expect as possible. You might not necessarily > like that but that's a sensible choice for attracting new people to RDF. > > Within the RDFJS effort, we managed to define a standard interface for > RDF and build tooling around it. Have a look at > > https://rdf.js.org/ > > You will find multiple implementations and abstractions on top of these > interface definitions. > > We @Zazuko build additional abstractions on top of it, for example the > RDF-Ext stack. See an introduction to it here > > https://zazuko.com/get-started/developers/ > > and an overview of libraries here > > https://github.com/rdf-ext/rdf-ext > > Most recently we re-factored Holgers SHACL reference implementation to > match these interfaces: > > https://github.com/zazuko/rdf-validate-shacl > > A great base for doing additional work is Comunica, a modular framework > for querying the web. It also provides stores & SPARQL interfaces on top: > > https://comunica.linkeddatafragments.org/ > > Quoting from your intro phrase: > > > RDF JavaScript frameworks are still ~20 years behind Java. > > I know that you Martynas do not give a f-ck about anything that is not > Java and/or XML but let me ask the question anyway: What exactly would > you like to do in JavaScript that should be done in JavaScript and > cannot be done in it right now? > > We @Zazuko are happily using JavaScript in Frontend & Backend (Node) and > rely on things like Fuseki or Stardog that are both written in Java on > the backend. > > We are also experimenting with WASM for things where it does not make > sense for various reason to approach the problem in JavaScript itself. > > But I really fail to see the point of having a full "Jena" API in > JavaScript, however that would look like. > > regards > > Adrian >
