search

rdf-elixir / rdf-ex

An implementation of RDF for Elixir
https://rdf-elixir.dev/
MIT License
94 stars 8 forks source link

TriG support #3

Closed mitchellvanw closed 1 week ago

mitchellvanw commented 5 years ago

Hi,

I really appreciate you invested the time in writing and maintaining this library; it looks great.

I wonder if you've considered supporting TriG? If so, I'd gladly make a PR containing this functionality or assist you in any meaningful way to accomplish this.

Thanks!

marcelotto commented 5 years ago

It's on my todo list, but to be honest there are much more things with higher priority currently from my perspective. On the serialization format front, for example, JSON-LD 1.1, RDFa and CSVW. But currently, I'm quite busy with finishing the SPARQL engine in SPARQL.ex. So, a PR would be highly appreciated. I'll put together an implementation plan until tomorrow (I'm working on this project beside my day job).

marcelotto commented 5 years ago

Ok, having a Turtle implementation already, it shouldn't be too hard. The problem is that the Turtle parser is written with leex and yecc, the Erlang-embedded compiler generators and its grammars are not very composable. When I implemented these grammars, NimbleParsec, which I would use today wasn't available yet, unfortunately. I already had this problem with N-Quads and in the end, duplicated the N-Triples grammar with the needed variations. Given the simplicity of these grammars, I considered that not a too heavy maintenance burden.

In the case of Turtle and TriG I am not that sure if that's the way to go. Since TriG is effectively a subset of Turtle, there would be another implementation option in this case: we could use a shared TriG grammar and semantic analyzer (the functions in the RDF.Serialization.Decoder interpreting the AST by translating them to the RDF.ex data structures) and introduce an internal option which signifies the source language and would lead to syntax errors during semantic analysis of TriG expressions on a Turtle document.

For the RDF.Serialization.Encoder a similar technique would be required, since we don't want to duplicate the translation code here either, but differentiate the handling of RDF.Datasets depending on an option. On the Turtle encoder, this option might also allow simply ignoring the graph names and serializing all statements of the dataset without the graph context.