submit to https://awesomelists.top about awesome-semantic-web

[zacharywhitley]

Thanks for the feedback and I'm glad you find the list helpful. There has been so much great work on semantic web tech but it has always been scattered about. I started a list as just a way to keep track of it all myself. Publishing it on sindresorhus/awesome has been not the to-do list for a while. It's the first issue I opened. #4 There's some criteria for adding it to the list. Some of which are easily verified and mostly complete. Others are somewhat more vague and I just need to accept that it will never be perfect and just submit it.

Btw, I think that XSPARQL was a real missed opportunity for the semantic web. I find the code base to be somewhat convoluted and difficult to maintain and the complexity and lack of adoption of Xquery didn't help. I've sometimes toyed with the idea of rewriting it or possibly porting it over to SirixDB https://github.com/sirixdb/sirix

[justin2004]

@zacharywhitley what made you mention XSPARQL? did @VladimirAlexiev work on it?

i think sparql-anything might do something like you were looking for in XSPARQL. i opened #168 and i linked the associated paper which is pretty persuasive, i find.

[zacharywhitley]

@VladimirAlexiev had submitted a few patches to XSparql. Thanks for the link. I'll definitely check it out.

[zacharywhitley]

It is very interesting but from my quick scan it only does what xsparql referred to as lifting but does not do lowering. There are a few things that do lifting like RML but I don't know many ways to do the lowering and it's a shame because it cuts the semantic web off from a much larger IT ecosystem. I think this was a conceit on the part of the semantic web community that once everyone realized how great the semantic web was they would simply abandon what they were doing and adopt a semantic web stack.

I'll go as far as saying that xsparql was brilliant and the only down side was the combined complexity of two, not well known, query languages and it didn't help that xquery went off the rails in terms of complexity and xml fell out of general favor.

[justin2004]

I think this was a conceit on the part of the semantic web community that once everyone realized how great the semantic web was they would simply abandon what they were doing and adopt a semantic web stack.

that turned out to be true for me. i wouldn't start a project and not recommend using RDF.

[justin2004]

@zacharywhitley do you think RDF serialized as json-ld constitutes lowering?

[carenini]

I know that I'm out of topic, but in case you're interested in lowering we implemented it by embedding SPARQL queries in Apache Velocity templates. Here you can find an example https://github.com/cefriel/chimera/blob/master/chimera-example/src/main/resources/template-stops.vm . We didn't write any specific paper about it but it works :-)

[zacharywhitley]

@zacharywhitley do you think RDF serialized as json-ld constitutes lowering?

Only if you can control the shape of the result. ie. you can hand it to someone developing a react front end and say, "Just ignore the @context part" I know that JSON-LD has framing but when I went to look into day I came across a post suggesting a few examples to learn it or, to paraphrase, "Look at the spec if you're a masochist". I find it funny that RDF is a graph and json is a tree which is a type of graph and it's such a pain to generate it.

That reminded me, there's also STTL, SPARQL Template Transformations https://ns.inria.fr/sparql-template/ but I always found them to be somewhat awkward and XSLTish.

[zacharywhitley]

I know that I'm out of topic, but in case you're interested in lowering we implemented it by embedding SPARQL queries in Apache Velocity templates. Here you can find an example https://github.com/cefriel/chimera/blob/master/chimera-example/src/main/resources/template-stops.vm . We didn't write any specific paper about it but it works :-)

That's what I'd be looking for but it would be nice to have something that ties more closely into the database and query planner so you could evaluate it in a single performant query rather than dozens of small inefficient ones. RDF databases are already bad enough.

[justin2004]

you can hand it to someone developing a react front end and say, "Just ignore the @context part"

we tried that (using some json-ld framing) but the main problem we encountered was that in the graph subgraphs can be shared but when converted to a tree a shared subgraph only gets put in one part of the tree and the other parts just get a reference. we didn't look hard but we didn't find a json-ld framing option to say "don't use any references in the resultant tree. that is, copy all shared subgraphs to each part of the tree."

[VladimirAlexiev]

SPARQL Generate is the next version of STL and is very powerful, as versatile as xsparql.
However I find the learning curve higher.

XSPARQL is brilliant but the codebase a bit buggy on spots... also not fully documented. I added some fixes to the grammar and see this http://rawgit2.com/VladimirAlexiev/xsparql/master/doc/grammar-nonterminals.xhtml.

Btw we're doing right now some Electrical stuff with xsparq, see https://transparency.ontotext.com/#semantic-etl-lifting.

If you want shaped and nested JSON, consider using GraphQL (SPARQL is not good at producing nested structures), and see our Ontotext Platform, which does that.