[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.
[ https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396186#comment-16396186 ] ASF GitHub Bot commented on JENA-632: - Github user kinow commented on the issue: https://github.com/apache/jena/pull/114 Going to check how to get the correct values with JSON. Great catch, as I was using just Strings. But shouldn't be too hard. Will also include the initial tests with the next changes, covering both previous features, and the conversion from the table you provided :-) Thanks! > Generate JSON from SPARQL directly. > --- > > Key: JENA-632 > URL: https://issues.apache.org/jira/browse/JENA-632 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ, Fuseki >Reporter: Andy Seaborne >Assignee: Bruno P. Kinoshita >Priority: Minor > Labels: java, javacc > Time Spent: 0.5h > Remaining Estimate: 0h > > The capability to generate JSON directly from a SPARQL (or extended SPARQL) > query would enable the creation of JSON data API over published linked data. > This project would cover: > # Design and publication of a design. > # Refinement of design based on community feed > # Implementation, including testing. > # Refinement of implementation based on community feed > Skills required: Java, some parser work, design and discussion with the user > community, basic understanding of HTTP and content negotiation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] jena issue #114: JENA-632: Generate JSON from SPARQL directly
Github user kinow commented on the issue: https://github.com/apache/jena/pull/114 Going to check how to get the correct values with JSON. Great catch, as I was using just Strings. But shouldn't be too hard. Will also include the initial tests with the next changes, covering both previous features, and the conversion from the table you provided :-) Thanks! ---
[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.
[ https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396107#comment-16396107 ] ASF GitHub Bot commented on JENA-632: - Github user afs commented on the issue: https://github.com/apache/jena/pull/114 Tests? > Generate JSON from SPARQL directly. > --- > > Key: JENA-632 > URL: https://issues.apache.org/jira/browse/JENA-632 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ, Fuseki >Reporter: Andy Seaborne >Assignee: Bruno P. Kinoshita >Priority: Minor > Labels: java, javacc > Time Spent: 0.5h > Remaining Estimate: 0h > > The capability to generate JSON directly from a SPARQL (or extended SPARQL) > query would enable the creation of JSON data API over published linked data. > This project would cover: > # Design and publication of a design. > # Refinement of design based on community feed > # Implementation, including testing. > # Refinement of implementation based on community feed > Skills required: Java, some parser work, design and discussion with the user > community, basic understanding of HTTP and content negotiation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (JENA-632) Generate JSON from SPARQL directly.
[
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395357#comment-16395357
]
Andy Seaborne edited comment on JENA-632 at 3/12/18 9:50 PM:
-
Github user afs commented on the issue:
[https://github.com/apache/jena/pull/114]
I applied 114.patch locally and it integrated just fine.
I tried `JSON
{ "s": ?s , "p": ?p , "o" : ?o }
WHERE
{ ?s ?p ?o }
` on data
```
:s \:p 123 .
:s \:p "abc" .
:s \:p "def"@en .
```
and got:
```
[
{ "o" : "123^^http://www.w3.org/2001/XMLSchema#integer; }
,
{ "o" : "abc" }
,
{ "o" : "def@en" }
]
```
I think we should use a more aggressive version of the conversion from RDF
term to JS used in the upcoming [JS custom
Functions]([http://jena.staging.apache.org/documentation/query/javascript-functions.html#arguments-and-function-results]),
code
[https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/function/js/NV.java].
That works on `NodeValue`s to make functions more natural to write and is
two-way.
For JSON-SELECT we only need a one way conversion and getting info out even if
it is some string is better IMO.
|RDF|Javascript|
|||
|String|String|
|XSD numeric|JSON number|
|XSD boolean|boolean|
|String@lang|String, no lang|
|URI|String|
|"lex"^^SomeDatatype|String, no datatype|
|Unbound|JSON null|
If the app wants RDF term details, it can use `application/result-set+json`.
This feature provides provides a simpler, more JSONy view of the data for
consuming RDF-unaware applications.
was (Author: githubbot):
Github user afs commented on the issue:
https://github.com/apache/jena/pull/114
I applied 114.patch locally and it integrated just fine.
I tried `JSON { "s": ?s , "p": ?p , "o" : ?o } WHERE { ?s ?p ?o }` on data
```
:s :p 123 .
:s :p "abc" .
:s :p "def"@en .
```
and got:
```
[ { "o" : "123^^http://www.w3.org/2001/XMLSchema#integer; } ,
{ "o" : "abc" } ,
{ "o" : "def@en" }
]
```
I think we should use a more aggressive version of the conversion from RDF
term to JS used in the upcoming [JS custom
Functions](http://jena.staging.apache.org/documentation/query/javascript-functions.html#arguments-and-function-results),
code
https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/function/js/NV.java.
That works on `NodeValue`s to make functions more natural to write and is
two-way.
For JSON-SELECT we only need a one way conversion and getting info out even
if it is some string is better IMO.
| RDF | Javascript |
| | |
| String | String |
| XSD numeric | JSON number |
| XSD boolean | boolean |
| String@lang | String, no lang |
| URI | String |
| "lex"^^SomeDatatype | String, no datatype |
| Unbound | JSON null |
If the app wants RDF term details, it can use
`application/result-set+json`. This feature provides provides a simpler, more
JSONy view of the data for consuming RDF-unaware applications.
> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Labels: java, javacc
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL)
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user
> community, basic understanding of HTTP and content negotiation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] jena issue #114: JENA-632: Generate JSON from SPARQL directly
Github user afs commented on the issue: https://github.com/apache/jena/pull/114 Tests? ---
[jira] [Commented] (JENA-1488) SelectiveFoldingFilter for jena-text
[ https://issues.apache.org/jira/browse/JENA-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395391#comment-16395391 ] Osma Suominen commented on JENA-1488: - The DefinedFilter solution sounds like the best from my perspective too. I'd still prefer the SelectiveFoldingFilter to live in the Jena codebase (for reasons of convenience stated above). > SelectiveFoldingFilter for jena-text > > > Key: JENA-1488 > URL: https://issues.apache.org/jira/browse/JENA-1488 > Project: Apache Jena > Issue Type: Improvement > Components: Text >Affects Versions: Jena 3.6.0 >Reporter: Osma Suominen >Assignee: Bruno P. Kinoshita >Priority: Major > > Currently there's some support for accent folding in jena-text, because > Lucene provides an ASCIIFoldingFilter. When this filter is enabled, a search > for "deja vu" will match the literal "déjà vu" in the data. > But we can't use it here at the National Library of Finland (for Finto.fi / > Skosmos), because it folds too much! In the Finnish alphabet, in addition to > the Latin a-z (which are in ASCII) we use the letters åäö and these should > not be folded to ASCII. So we need a Lucene analyzer that can be configured > with an exclude list, something like > > new SelectiveFoldingFilter(String excludeChars) > > and that can be also be configured via the Jena assembler just like other > analyzers supported by jena-text. > > This was also briefly discussed on the skosmos-users mailing list: > [https://groups.google.com/d/msg/skosmos-users/x3zR_uRBQT0/Q90-O_iDAQAJ] > Apparently Norwegians have the same problem... > I've discussed this with [~kinow] and he has some initial code to implement > this feature, so I think we can turn this into a PR fairly soon. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1506) Add configurable filters and tokenizers
[
https://issues.apache.org/jira/browse/JENA-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395387#comment-16395387
]
Osma Suominen commented on JENA-1506:
-
Sounds good! The minimum for JENA-1488 would be to have a facility for defining
a filter with parameters set via the assembler.
> Add configurable filters and tokenizers
> ---
>
> Key: JENA-1506
> URL: https://issues.apache.org/jira/browse/JENA-1506
> Project: Apache Jena
> Issue Type: New Feature
> Components: Text
>Affects Versions: Jena 3.7.0
>Reporter: Code Ferret
>Priority: Major
>
> In support of [Jena-1488|https://issues.apache.org/jira/browse/JENA-1488],
> this issue proposes to add a feature to allow including defined filters and
> tokenizers, similar to {{DefinedAnalyzer}}, for the {{ConfigurableAnalyzer}},
> allowing configurable arguments such as the {{excludeChars}}. I've looked at
> {{ConfigurableAnalyzer}} and its assembler and it should be straightforward.
> I would add tokenizer and filter definitions to {{TextIndexLucene}} similar
> to the support for adding analyzers:
> {code:java}
> text:defineFilters (
> [ text:defineFilter <#foo> ;
> text:filter [
> a text:GenericFilter ;
> text:class "fi.finto.FoldingFilter" ;
> text:params (
> [ text:paramName "excludeChars" ;
> text:paramType text:TypeString ;
> text:paramValue "whatevercharstoexclude" ]
> )
> ] ;
> ]
> )
> {code}
> {{GenericFilterAssembler}} and {{GenericTokenizerAssmbler}} would make use of
> much of the code in {{GenericAnalyzerAssembler}}. The changes to
> {{ConfigurableAnalyzer}} and {{ConfigurableAnalyzerAssembler}} are
> straightforward and mostly involve retaining the resource URI rather than
> extracting the localName.
> Such an addition will make it easy to create new tokenizers and filters that
> could be dropped in by just adding the classes onto the jena/fuseki classpath
> or by referring to ones already included in Jena (via Lucene or otherwise)
> and putting the appropriate assembler bits in the configuration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] jena issue #114: JENA-632: Generate JSON from SPARQL directly
Github user afs commented on the issue:
https://github.com/apache/jena/pull/114
I applied 114.patch locally and it integrated just fine.
I tried `JSON { "s": ?s , "p": ?p , "o" : ?o } WHERE { ?s ?p ?o }` on data
```
:s :p 123 .
:s :p "abc" .
:s :p "def"@en .
```
and got:
```
[ { "o" : "123^^http://www.w3.org/2001/XMLSchema#integer; } ,
{ "o" : "abc" } ,
{ "o" : "def@en" }
]
```
I think we should use a more aggressive version of the conversion from RDF
term to JS used in the upcoming [JS custom
Functions](http://jena.staging.apache.org/documentation/query/javascript-functions.html#arguments-and-function-results),
code
https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/function/js/NV.java.
That works on `NodeValue`s to make functions more natural to write and is
two-way.
For JSON-SELECT we only need a one way conversion and getting info out even
if it is some string is better IMO.
| RDF | Javascript |
| | |
| String | String |
| XSD numeric | JSON number |
| XSD boolean | boolean |
| String@lang | String, no lang |
| URI | String |
| "lex"^^SomeDatatype | String, no datatype |
| Unbound | JSON null |
If the app wants RDF term details, it can use
`application/result-set+json`. This feature provides provides a simpler, more
JSONy view of the data for consuming RDF-unaware applications.
---
[jira] [Updated] (JENA-1506) Add configurable filters and tokenizers
[
https://issues.apache.org/jira/browse/JENA-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Code Ferret updated JENA-1506:
--
Description:
In support of [Jena-1488|https://issues.apache.org/jira/browse/JENA-1488], this
issue proposes to add a feature to allow including defined filters and
tokenizers, similar to {{DefinedAnalyzer}}, for the {{ConfigurableAnalyzer}},
allowing configurable arguments such as the {{excludeChars}}. I've looked at
{{ConfigurableAnalyzer}} and its assembler and it should be straightforward.
I would add tokenizer and filter definitions to {{TextIndexLucene}} similar to
the support for adding analyzers:
{code:java}
text:defineFilters (
[ text:defineFilter <#foo> ;
text:filter [
a text:GenericFilter ;
text:class "fi.finto.FoldingFilter" ;
text:params (
[ text:paramName "excludeChars" ;
text:paramType text:TypeString ;
text:paramValue "whatevercharstoexclude" ]
)
] ;
]
)
{code}
{{GenericFilterAssembler}} and {{GenericTokenizerAssmbler}} would make use of
much of the code in {{GenericAnalyzerAssembler}}. The changes to
{{ConfigurableAnalyzer}} and {{ConfigurableAnalyzerAssembler}} are
straightforward and mostly involve retaining the resource URI rather than
extracting the localName.
Such an addition will make it easy to create new tokenizers and filters that
could be dropped in by just adding the classes onto the jena/fuseki classpath
or by referring to ones already included in Jena (via Lucene or otherwise) and
putting the appropriate assembler bits in the configuration.
was:
In support of Jena-1488, this issue proposes to add a feature to allow
including defined filters and tokenizers, similar to {{DefinedAnalyzer}}, for
the {{ConfigurableAnalyzer}}, allowing configurable arguments such as the
{{excludeChars}}. I've looked at {{ConfigurableAnalyzer}} and its assembler and
it should be straightforward.
I would add tokenizer and filter definitions to {{TextIndexLucene}} similar to
the support for adding analyzers:
{code:java}
text:defineFilters (
[ text:defineFilter <#foo> ;
text:filter [
a text:GenericFilter ;
text:class "fi.finto.FoldingFilter" ;
text:params (
[ text:paramName "excludeChars" ;
text:paramType text:TypeString ;
text:paramValue "whatevercharstoexclude" ]
)
] ;
]
)
{code}
{{GenericFilterAssembler}} and {{GenericTokenizerAssmbler}} would make use of
much of the code in {{GenericAnalyzerAssembler}}. The changes to
{{ConfigurableAnalyzer}} and {{ConfigurableAnalyzerAssembler}} are
straightforward and mostly involve retaining the resource URI rather than
extracting the localName.
Such an addition will make it easy to create new tokenizers and filters that
could be dropped in by just adding the classes onto the jena/fuseki classpath
or by referring to ones already included in Jena (via Lucene or otherwise) and
putting the appropriate assembler bits in the configuration.
> Add configurable filters and tokenizers
> ---
>
> Key: JENA-1506
> URL: https://issues.apache.org/jira/browse/JENA-1506
> Project: Apache Jena
> Issue Type: New Feature
> Components: Text
>Affects Versions: Jena 3.7.0
>Reporter: Code Ferret
>Priority: Major
>
> In support of [Jena-1488|https://issues.apache.org/jira/browse/JENA-1488],
> this issue proposes to add a feature to allow including defined filters and
> tokenizers, similar to {{DefinedAnalyzer}}, for the {{ConfigurableAnalyzer}},
> allowing configurable arguments such as the {{excludeChars}}. I've looked at
> {{ConfigurableAnalyzer}} and its assembler and it should be straightforward.
> I would add tokenizer and filter definitions to {{TextIndexLucene}} similar
> to the support for adding analyzers:
> {code:java}
> text:defineFilters (
> [ text:defineFilter <#foo> ;
> text:filter [
> a text:GenericFilter ;
> text:class "fi.finto.FoldingFilter" ;
> text:params (
> [ text:paramName "excludeChars" ;
> text:paramType text:TypeString ;
> text:paramValue "whatevercharstoexclude" ]
> )
> ] ;
> ]
> )
> {code}
> {{GenericFilterAssembler}} and {{GenericTokenizerAssmbler}} would make use of
> much of the code in {{GenericAnalyzerAssembler}}. The changes to
> {{ConfigurableAnalyzer}} and {{ConfigurableAnalyzerAssembler}} are
> straightforward and mostly involve retaining the resource URI rather than
> extracting the localName.
> Such an addition will make it easy
[jira] [Created] (JENA-1506) Add configurable filters and tokenizers
Code Ferret created JENA-1506:
-
Summary: Add configurable filters and tokenizers
Key: JENA-1506
URL: https://issues.apache.org/jira/browse/JENA-1506
Project: Apache Jena
Issue Type: New Feature
Components: Text
Affects Versions: Jena 3.7.0
Reporter: Code Ferret
In support of Jena-1488, this issue proposes to add a feature to allow
including defined filters and tokenizers, similar to {{DefinedAnalyzer}}, for
the {{ConfigurableAnalyzer}}, allowing configurable arguments such as the
{{excludeChars}}. I've looked at {{ConfigurableAnalyzer}} and its assembler and
it should be straightforward.
I would add tokenizer and filter definitions to {{TextIndexLucene}} similar to
the support for adding analyzers:
{code:java}
text:defineFilters (
[ text:defineFilter <#foo> ;
text:filter [
a text:GenericFilter ;
text:class "fi.finto.FoldingFilter" ;
text:params (
[ text:paramName "excludeChars" ;
text:paramType text:TypeString ;
text:paramValue "whatevercharstoexclude" ]
)
] ;
]
)
{code}
{{GenericFilterAssembler}} and {{GenericTokenizerAssmbler}} would make use of
much of the code in {{GenericAnalyzerAssembler}}. The changes to
{{ConfigurableAnalyzer}} and {{ConfigurableAnalyzerAssembler}} are
straightforward and mostly involve retaining the resource URI rather than
extracting the localName.
Such an addition will make it easy to create new tokenizers and filters that
could be dropped in by just adding the classes onto the jena/fuseki classpath
or by referring to ones already included in Jena (via Lucene or otherwise) and
putting the appropriate assembler bits in the configuration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (JENA-1501) Add systemd unit file for Fuseki
[ https://issues.apache.org/jira/browse/JENA-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Osma Suominen resolved JENA-1501. - Resolution: Fixed Merged the unit file and documentation. All done. > Add systemd unit file for Fuseki > > > Key: JENA-1501 > URL: https://issues.apache.org/jira/browse/JENA-1501 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.6.0 >Reporter: Osma Suominen >Assignee: Osma Suominen >Priority: Major > Fix For: Jena 3.7.0 > > > As discussed on the users mailing list, we could add a systemd unit file for > Fuseki to make it easier to set it up on systemd based Linux installations. > I will make a PR soon. > Ping [~jneubert] who originally requested this -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JENA-1501) Add systemd unit file for Fuseki
[ https://issues.apache.org/jira/browse/JENA-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Osma Suominen updated JENA-1501: Fix Version/s: Jena 3.7.0 > Add systemd unit file for Fuseki > > > Key: JENA-1501 > URL: https://issues.apache.org/jira/browse/JENA-1501 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.6.0 >Reporter: Osma Suominen >Assignee: Osma Suominen >Priority: Major > Fix For: Jena 3.7.0 > > > As discussed on the users mailing list, we could add a systemd unit file for > Fuseki to make it easier to set it up on systemd based Linux installations. > I will make a PR soon. > Ping [~jneubert] who originally requested this -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1501) Add systemd unit file for Fuseki
[ https://issues.apache.org/jira/browse/JENA-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394915#comment-16394915 ] ASF GitHub Bot commented on JENA-1501: -- Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/375 > Add systemd unit file for Fuseki > > > Key: JENA-1501 > URL: https://issues.apache.org/jira/browse/JENA-1501 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.6.0 >Reporter: Osma Suominen >Assignee: Osma Suominen >Priority: Major > > As discussed on the users mailing list, we could add a systemd unit file for > Fuseki to make it easier to set it up on systemd based Linux installations. > I will make a PR soon. > Ping [~jneubert] who originally requested this -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1501) Add systemd unit file for Fuseki
[ https://issues.apache.org/jira/browse/JENA-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394912#comment-16394912 ] ASF subversion and git services commented on JENA-1501: --- Commit a85333a8c821927eb4a58463859b5f6caa2d94e4 in jena's branch refs/heads/master from [~osma] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=a85333a ] JENA-1501: add systemd unit file for Fuseki > Add systemd unit file for Fuseki > > > Key: JENA-1501 > URL: https://issues.apache.org/jira/browse/JENA-1501 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.6.0 >Reporter: Osma Suominen >Assignee: Osma Suominen >Priority: Major > > As discussed on the users mailing list, we could add a systemd unit file for > Fuseki to make it easier to set it up on systemd based Linux installations. > I will make a PR soon. > Ping [~jneubert] who originally requested this -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1501) Add systemd unit file for Fuseki
[ https://issues.apache.org/jira/browse/JENA-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394914#comment-16394914 ] ASF subversion and git services commented on JENA-1501: --- Commit 0597a7b718482bf94963e546f17301da3b08c2ba in jena's branch refs/heads/master from [~osma] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=0597a7b ] JENA-1501: add note about systemd unit file > Add systemd unit file for Fuseki > > > Key: JENA-1501 > URL: https://issues.apache.org/jira/browse/JENA-1501 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.6.0 >Reporter: Osma Suominen >Assignee: Osma Suominen >Priority: Major > > As discussed on the users mailing list, we could add a systemd unit file for > Fuseki to make it easier to set it up on systemd based Linux installations. > I will make a PR soon. > Ping [~jneubert] who originally requested this -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] jena pull request #375: JENA-1501: add systemd unit file for Fuseki
Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/375 ---
[jira] [Commented] (JENA-1501) Add systemd unit file for Fuseki
[ https://issues.apache.org/jira/browse/JENA-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394913#comment-16394913 ] ASF subversion and git services commented on JENA-1501: --- Commit 93a29c702b353b8102de6c1f838435abc3b16ff5 in jena's branch refs/heads/master from [~osma] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=93a29c7 ] JENA-1501: clarify usage instructions > Add systemd unit file for Fuseki > > > Key: JENA-1501 > URL: https://issues.apache.org/jira/browse/JENA-1501 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.6.0 >Reporter: Osma Suominen >Assignee: Osma Suominen >Priority: Major > > As discussed on the users mailing list, we could add a systemd unit file for > Fuseki to make it easier to set it up on systemd based Linux installations. > I will make a PR soon. > Ping [~jneubert] who originally requested this -- This message was sent by Atlassian JIRA (v7.6.3#76005)
