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
Turtle Star #299
Turtle Star #299
Conversation
Sorry for the delay getting round to this - Jena had a release which Comments in two areas : the parser and about RDF*. Turtle parser The Turtle parser in jena-core only exists for legacy and support some Parsing happens in RIOT org.apache.jena.riot.lang.LangTurtle. It is a If you are interested, we can add the tokens for RDF*, it takes some care There is an example of plumbing in a new language in ExRIOT5.java. RDF* and RDF RDF* has the notion of a triple id: each triple has a unique id which makes it different to reification. An RDF* grah can be written in RDF and the result and back in again by using exactly one for a It is not possible to RDF-merge to such graphs - that would end up with two bnode-reificiations and statements in one graph about the triple will not RDF*-merge with the statements in the other graph (which is the whole point of RDF reification). Merging needs to respect the additional RDF* data model.
My understanding of RDF* is that this is one triple SPARQL The |
Thanks @mschroeder-github for taking the initiative of writing an RDF* parser for Jena! @afs Before responding to some of your comments, I should mentioned that I am still actively working on RDF* and SPARQL* even if I am having hardly any time for writing code in my new position. Anyways, I have recently published a paper with formal results about RDF*/SPARQL*. Additionally, two weeks ago I presented the approach as a poster in ISWC 2017 and won the "peoples' choice best poster award" for it. Now, to your comments: You are right, an RDF* graph is not an RDF graph, but it can be transformed into an RDF graph (by applying the RDF reification vocabulary or some other pure-RDF approach such as singleton properties or single-triple named graphs). The aforementioned paper provides the formal mappings for such transformations and shows that these mappings have desirable properties (they are information preserving and query result preserving). However, you are not right when you write that "RDF* has the notion of a triple id." There is no such notion in RDF* (unless you consider the triples themselves as triple identifiers). Regarding your example that you introduce when you write about merging, you are right: these are two RDF* triples that have the same subject and this subject happens to be the triple ( In your comment related to SPARQL you write that the In general, I understand your response to this PR as a positive attitude towards supporting RDF* syntax (and SPARQL* syntax?) in Jena, plus a suggestion to implement this support as part of RIOT instead of the jena-core Turtle parser. Correct? |
Executing SPARQL over the id-specific standard RDF representation of RDF*, could be done with without needing to modify the core algebra by expansion of For With that, I think an extension can go in a separate maven module as a pure extension. (This is by thinking about it, not coding it.) |
Thanks Andy! I agree with what you write. Do you think there is a chance for such a separate maven module to become part of the official family of Apache Jena maven modules? |
Every chance if the Jena committers and PMC agree. Developing as a separate module, outside Jena, to start with helps the work by not getting entangled in timing and release issues of Jena releases. It also helps creates the community focused on the work. The Jena project releases all modules in a single release process every 3 or 4 months. Users tend to expect continuity across releases. While getting started, a module If there are Jena changes needed (adding a new RDF term type (Do note - the Jena project is not a source of maintenance and support for contributions. Depending on complexity, that might be something to discuss nearer the time). |
PR #327 adds an RDFTerm for a triple. |
Apache Jena 3.6.0 is out and has |
Great Andy, thanks! I will check it out after the holidays. (I'm a bit overloaded here at the moment) |
I finally have implemented a Turtle* parser that hooks into Jena's RIOT parser framework and uses the |
Ah, one more thing: @afs, would it be possible to extend the |
@hartig - I'm ambivalent on changing How about changing Jena so the (Incidently, this would be good to anyway for "generalized RDF" as defined in RDF 1.1)
|
+1 on keeping the "default" check as-is, but making the choice of calling it / changing it available via a wrapper. |
I agree. Making While we are at it, can you add another constructor to
...and then modify the existing constructor as follows:
|
That does not work because the
Could you send in a pull request please? |
In my implementation it would have worked because it is wrapping the earlier-created Anyways, I understand that you want a more flexible solution.
Will do. |
Add the PR #418 |
Looks like we're done here for now with parsers at https://github.com/RDFstar/RDFstarTools/ . |
Agreed. |
Turtle parser extention for Turtle* as suggested in Foundations of an Alternative Approach to Reification in RDF (Section 3.3).
I copied the javacc grammar definition from
turtle.jj
and add the changes toturtle-star.jj
.Javacc generates all the classes in package
org.apache.jena.n3.turtlestar.parser
.The
RDFReaderFImpl
is extended with theTurtleStarReader
reader, so one can read Turtle* with the following code:In short, the Turtle* syntax
results in the following RDF model:
A more complex example is: