[GitHub] jena issue #299: Turtle Star
Github user hartig commented on the issue: https://github.com/apache/jena/pull/299 Agreed. ---
[GitHub] jena issue #299: Turtle Star
Github user afs commented on the issue: https://github.com/apache/jena/pull/299 Looks like we're done here for now with parsers at https://github.com/RDFstar/RDFstarTools/ . ---
[GitHub] jena issue #299: Turtle Star
Github user hartig commented on the issue: https://github.com/apache/jena/pull/299 Add the PR #418 ---
[GitHub] jena issue #299: Turtle Star
Github user hartig commented on the issue: https://github.com/apache/jena/pull/299 > That does not work because the `ParserProfileStd` supplied to `TurtleStarReaderRIOT` has already been created, which is why the suggestion is to use a forwarding proxy object (the wrapper) with public access to the "check" operations. In my implementation it would have worked because it is wrapping the earlier-created `ParserProfileStd` passed to the constructor of my `LangTurtle` specialization; see line 59 in https://github.com/RDFstar/RDFstarTools/blob/master/src/main/java/se/liu/ida/rdfstar/tools/parser/lang/LangTurtleStar.java#L59 Anyways, I understand that you want a more flexible solution. > Could you send in a pull request please? Will do. ---
[GitHub] jena issue #299: Turtle Star
Github user hartig commented on the issue:
https://github.com/apache/jena/pull/299
I agree. Making `checkTriple` protected in `ParserProfileStd` would be an
even better idea. Please do it.
While we are at it, can you add another constructor to `TurtleShell` that
allows me to pass my own `NodeFormatter` (in addition to the other arguments
that are passed to the existing constructor)?
This extension would allow me to develop a `TurtleStarWriter` simply by
using `TurtleShell` instead of having to create a copy of it.
I mean, in terms of source code, my proposal is to add the following new
constructor:
```
protected TurtleShell(IndentedWriter out, PrefixMap pmap, String baseURI,
NodeFormatter nodeFmt, Context context) {
this.out = out ;
if ( pmap == null )
pmap = PrefixMapFactory.emptyPrefixMap() ;
this.prefixMap = pmap ;
this.baseURI = baseURI ;
this.nodeFmt = nodeFmt ;
}
```
...and then modify the existing constructor as follows:
```
protected TurtleShell(IndentedWriter out, PrefixMap pmap, String baseURI,
Context context) {
this(out, pmap, baseURI, createNodeFormatter(pmap,baseURI,context),
context) ;
}
static public NodeFormatter createNodeFormatter(PrefixMap pmap, String
baseURI, Context context) {
if ( context != null && context.isTrue(RIOT.multilineLiterals) )
return new NodeFormatterTTL_MultiLine(baseURI, pmap,
NodeToLabel.createScopeByDocument()) ;
else
return new NodeFormatterTTL(baseURI, pmap,
NodeToLabel.createScopeByDocument()) ;
}
```
---
[GitHub] jena issue #299: Turtle Star
Github user ajs6f commented on the issue: https://github.com/apache/jena/pull/299 +1 on keeping the "default" check as-is, but making the choice of calling it / changing it available via a wrapper. ---
[GitHub] jena issue #299: Turtle Star
Github user afs commented on the issue:
https://github.com/apache/jena/pull/299
@hartig - I'm ambivalent on changing `ParserProfileStd` because that
guarantee on `checkTriple` (and `checkQuad`) checks a condition that a lot of
code assumes is valid and does not check again. Hence the "Std".
How about changing Jena so the `checkTriple` is publicly accessible and
also adding, in Jena, `ParserProfileWrapper` so that operations can be
intercepted and changed?
(Incidently, this would be good to anyway for "generalized RDF" as defined
in RDF 1.1)
```
TurtleStarReaderRIOT(Lang lang, ParserProfile parserProfile) {
this.lang = lang;
this.parserProfile = new ParserProfileRDFStar(parserProfile);
}
```
```
public class ParserProfileRDFStar extends ParserProfileWrapper {
public ParserProfileRDFStar(ParserProfile parserProfile) {
super(parserProfile); }
@Override public void checkTriple(...
@Override public void checkQuad(...
}
```
---
[GitHub] jena issue #299: Turtle Star
Github user hartig commented on the issue: https://github.com/apache/jena/pull/299 Ah, one more thing: @afs, would it be possible to extend the `checkTriple` method of `ParserProfileStd` to permit the subject and the object of a triple to be `Node_Triple`? This is the only thing that breaks my Turtle* parser extension. The only workaround for me at the moment is to use the parser framework with "checking" disabled. ---
[GitHub] jena issue #299: Turtle Star
Github user hartig commented on the issue: https://github.com/apache/jena/pull/299 I finally have implemented a Turtle* parser that hooks into Jena's RIOT parser framework and uses the `Node_Triple` class that @afs had added to Jena in PR #327. Find the code at https://github.com/RDFstar/RDFstarTools Thanks again all for your efforts! I think we now can close this PR here. ---
[GitHub] jena issue #299: Turtle Star
Github user hartig commented on the issue: https://github.com/apache/jena/pull/299 Great Andy, thanks! I will check it out after the holidays. (I'm a bit overloaded here at the moment) ---
[GitHub] jena issue #299: Turtle Star
Github user afs commented on the issue: https://github.com/apache/jena/pull/299 @mschroeder-github, @hartig Apache Jena 3.6.0 is out and has `Node_Triple` for you. Feedback etc welcome - this is an experimental feature and can be revised. Note - this does not mean parsers or writers handle it natively. ---
[GitHub] jena issue #299: Turtle Star
Github user afs commented on the issue: https://github.com/apache/jena/pull/299 PR #327 adds an RDFTerm for a triple. ---
[GitHub] jena issue #299: Turtle Star
Github user afs commented on the issue: https://github.com/apache/jena/pull/299 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 `rdfstar` may want to release as and when contributors and code are ready, have flexibility to release new version rapidly, change designs, and put API around RDF*graphs (RDF*-merge for example). Relying on PRs to Jena is going to be a burden for that community initially. If there are Jena changes needed (adding a new RDF term type `Node_Triple` for example), PRs to get them in focused on the needs can be done. (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). ---
[GitHub] jena issue #299: Turtle Star
Github user hartig commented on the issue: https://github.com/apache/jena/pull/299 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? ---
[GitHub] jena issue #299: Turtle Star
Github user afs commented on the issue: https://github.com/apache/jena/pull/299 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 `<<:s :p :o>>` in BGPs. For `BIND(<<:s :p :o>> AS ?t)` (from earlier work - it has gone now?) it can be done with a custom function `:findTriple(:s :p :o)` to return the reification bnode but it must be a single match (a good reason for not having or restricting it to ground s/p/o.). 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.) ---
[GitHub] jena issue #299: Turtle Star
Github user hartig commented on the issue: https://github.com/apache/jena/pull/299 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*](http://olafhartig.de/files/Hartig_AMW2017_RDFStar.pdf). 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 (`:s`,`:p`,`:o`). In your comment related to SPARQL you write that the `<< >>` syntax has been discussed in the SPARQL WG. Was this discussion related to reification or was the idea of the `<< >>` syntax in this discussion for something else? 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? ---
[GitHub] jena issue #299: Turtle Star
Github user afs commented on the issue: https://github.com/apache/jena/pull/299 Sorry for the delay getting round to this - Jena had a release which takes time. It would be interesting to see some support for RDF*. Comments in two areas : the parser and about RDF*. **Turtle parser** The Turtle parser in jena-core only exists for legacy and support some tests. It isn't the normal Turtle parser, and isn't spec compliant. Parsing happens in RIOT org.apache.jena.riot.lang.LangTurtle. It is a custom (hand written parser) with its own tokenizer for speed. If you are interested, we can add the tokens for RDF*, it takes some care because this is the same tokenizer as used for N-Triples and so speed-critical. We may need o split of an N-Triples/N-quads tokenizer but that wouldn't be such a bad thing anyway. There is an example of plumbing in a new language in [EXRIOT5.java](https://github.com/apache/jena/blob/master/jena-arq/src-examples/arq/examples/riot/ExRIOT_5.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 triple and the process can be reversed. This equates to the triple id of RDF* with information in the strict RDF graph. It's not a general RDF graph. 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. Example: ``` << :s :p :o >> :addedBy "Alice" . << :s :p :o >> :addedBy "Bob" . ``` My understanding of RDF* is that this is one triple `td = :s :p :o` with two triples with the same subject. `td :addedBy "Alice" . td :addedBy "Bob" .`. **SPARQL** The `<< >>` syntax has a long history - it was first used in early SPARQL discussions but never made it to the final stages. It may only existed on the mailing list; teh WG decided not to have reification syntax. However, there are some remains in the SPARQL grammar in ARQ. ---
