[GitHub] jena issue #473: Extendable versions of classes for printing result sets
Github user hartig commented on the issue:
https://github.com/apache/jena/pull/473
> Where and how are you wanting to output text format?
Where? In the command line tool for executing SPARQL* queries (see
[`ExecuteSPARQLStar` in
RDFstarTools](https://github.com/RDFstar/RDFstarTools/blob/master/src/main/java/se/liu/ida/rdfstar/tools/ExecuteSPARQLStar.java)).
How? As it is done by the `TextOutput` class in Jena, plus added support
for the case in which the `Node` for a variable is of type `Node_Triple` (which
is possible in results of SPARQL* queries). In this case, the triple wrapped by
that `Node_Triple` should be printed Turtle*-style, i.e., enclosed within `<<`
and `>>`. I have already implemented the necessary extension of the
`TextOutput` class: see [`TextOutputStar` in
RDFstarTools](https://github.com/RDFstar/RDFstarTools/blob/master/src/main/java/se/liu/ida/rdfstar/tools/sparqlstar/resultset/TextOutputStar.java).
> `QueryExecutils.outputResultSet` handles it - making
`ResultSetFormatter.output(OutputStream, ResultSet, ResultsFormat)` could do
the same (lookup properly for first-class results formats, and have some
adapter code to handle the other ways) is one way. Would that work or you?
Not really I think. I am indirectly using `QueryExecUtils.outputResultSet`
already. That is, my command line tool for executing SPARQL* queries
(`ExecuteSPARQLStar`) ends up in exactly that method, simply because
`ExecuteSPARQLStar` extends `arq.query` (which uses
`QueryExecUtils.executeQuery(Prologue, QueryExecution, ResultsFormat)`). Then,
`QueryExecUtils.outputResultSet` calls `ResultSetFormatter.out(OutputStream,
ResultSet, Prologue)`.
The problem is that all of these are static methods and there is no way for
me to specify which `TextOutput` object should be used by
`ResultSetFormatter.out(OutputStream, ResultSet, Prologue)`. I want it to use
my `TextOutputStar` (see above) instead of `TextOutput`.
So, again, I think the easiest solution would be if my command line tool
for executing SPARQL* queries (`ExecuteSPARQLStar`) could simply call a
to-be-created method of `ResultsFormat` that allows my program to add something
to `ResultsFormat.mapResultsFormatToLang`. Then, my program would simply add
`ResultsFormat.FMT_TEXT` -> `ResultSetLang.SPARQLResultSetText` (which would be
used only within the context of my program), and `ResultsWriter` would find and
use my `ResultSetWriterFactory` (which is created and registered in
[`ResultSetWritersSPARQLStar`](https://github.com/RDFstar/RDFstarTools/blob/master/src/main/java/se/liu/ida/rdfstar/tools/sparqlstar/resultset/ResultSetWritersSPARQLStar.java)).
Hence, all that would be needed is to add the following code to the
`ResultsFormat` class of Jena.
```
public static void addResultsFormatToLangPair(ResultsFormat fmt, Lang lang)
{
mapResultsFormatToLang.put(fmt, lang) ;
}
```
I believe such a method can be helpful for other use cases as well (e.g.,
assume someone wants to introduce a new result format language). What do you
say?
---
[GitHub] jena issue #473: Extendable versions of classes for printing result sets
Github user hartig commented on the issue: https://github.com/apache/jena/pull/473 Thanks Andy!! I will be waiting for Jena 3.10 to use this in my code. What about the other point mentioned in my initial comment in this PR? You have been hesitant to add `ResultsFormat.FMT_TEXT` to `mapResultsFormatToLang` directly in the Jena code base. Is that still the case? If it is, as an alternative I proposed to introduce a new method for adding something to `mapResultsFormatToLang` from external code (like mine). Does this sound reasonable? If it does, I can create another PR for it. ---
[GitHub] jena issue #473: Extendable versions of classes for printing result sets
Github user hartig commented on the issue: https://github.com/apache/jena/pull/473 > When Jena 3.9.0 is completed, I can come back and look at this PR. In principle, there is no reason not have have them extensible. Sounds good. Thanks! > What syntax are you using for TSV extensions? My idea was to simply extend the TSV format that you have in Jena with a possibility to also represent `Node_Triple` objects (as solution mappings in SPARQL* may map variables not only to URIs, literals, and bnodes, but also to triples). > On the question of mapping `ResultsFormat.FMT_TEXT`: IIRC it is because text is only an output format and not an input format (but then CSV is also only an output format). I see. If you are hesitant to add `ResultsFormat.FMT_TEXT` to `mapResultsFormatToLang` directly in the Jena code base, my alternative proposal of introducing a method for adding something to `mapResultsFormatToLang` from external code (like mine) would work for me too. ---
[GitHub] jena pull request #473: Extendable versions of classes for printing result s...
GitHub user hartig opened a pull request: https://github.com/apache/jena/pull/473 Extendable versions of classes for printing result sets This PR modifies the classes `CSVOutput` and `TSVOutput` to make it possible to extend them and override their behavior in subclasses. I want to implement such subclasses for my SPARQL* extension of Jena. A related question: Is there a reason why the mapping from `ResultsFormat` objects to `ResultSetLang`object (i.e., the [`mapResultsFormatToLang` in `ResultsFormat.java`](https://github.com/apache/jena/blob/aef35ee50eef9e0820d23d5ba184906b177a5c15/jena-arq/src/main/java/org/apache/jena/sparql/resultset/ResultsFormat.java#L190)) does not map `ResultsFormat.FMT_TEXT` to `ResultSetLang.SPARQLResultSetText`? Without this, the command line program `arq.query` falls back to the old `ResultSetWriter` and there is no elegant way for my SPARQL* extension of this program to use my SPARQL*-aware version of `ResultSetWriter` for text output. Hence, it would be great to add the following line into code that sets up `mapResultsFormatToLang`. ``` mapResultsFormatToLang.put(ResultsFormat.FMT_TEXT, ResultSetLang.SPARQLResultSetText) ; ``` Alternatively, the could be a method that can be used for adding something to `mapResultsFormatToLang`. If you are fine with any of these two options, I would like to add it to this PR. You can merge this pull request into a Git repository by running: $ git pull https://github.com/hartig/jena master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jena/pull/473.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #473 commit ce453fe9a930ce060c662360dfb4e17a8c6e03fc Author: Olaf Hartig Date: 2018-09-30T09:32:35Z Merge pull request #1 from apache/master update this fork to reflect the latest version of the original commit 3ea4a230610fea61ff288dc15e5ce8f4ae36924e Author: Olaf Hartig Date: 2018-09-30T18:53:08Z changed the access modifier of both 'output' and 'csvSafe' to be protected commit a8550192ed39c899687764fd9beda410a2560542 Author: Olaf Hartig Date: 2018-09-30T18:59:09Z added method createNodeFormatter() which can be overridden in subclasses commit ea7b430b825636595e92aebe7366d27b8ddcf47c Author: Olaf Hartig Date: 2018-09-30T19:00:09Z removed irrelevant comment ---
[GitHub] jena issue #299: Turtle Star
Github user hartig commented on the issue: https://github.com/apache/jena/pull/299 Agreed. ---
[GitHub] jena issue #418: pass a custom NodeFormatter to TurtleShell
Github user hartig commented on the issue: https://github.com/apache/jena/pull/418 @afs thanks for merging this PR, and also for your work on #416. Now I will be waiting eagerly for v.3.8.0 ;-) ---
[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 #418: pass a custom NodeFormatter to TurtleShell
Github user hartig commented on the issue: https://github.com/apache/jena/pull/418 This PR provides the extension proposed in https://github.com/apache/jena/pull/299#issuecomment-386918751 ---
[GitHub] jena pull request #418: pass a custom NodeFormatter to TurtleShell
GitHub user hartig opened a pull request: https://github.com/apache/jena/pull/418 pass a custom NodeFormatter to TurtleShell ⦠added another constructor that can be used to You can merge this pull request into a Git repository by running: $ git pull https://github.com/hartig/jena master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jena/pull/418.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #418 commit 8be9c26941253706bfd04fb7601330206b37098c Author: Olaf Hartig <olaf.hartig@...> Date: 2018-05-09T12:53:28Z added another constructor that can be used to pass a custom NodeFormatter to TurtleShell ---
[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 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 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 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? ---
