[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394092#comment-16394092
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/114
  
Done, and ready for review again.


> 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

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/114
  
Done, and ready for review again.


---

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394091#comment-16394091
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/114
  
Rebased!

Tested the `ARQParser` main method (which is added here, but I find very 
handy for quickly testing it, but happy to remove if others prefer). And got 
the following:

```
Enter input: JSON { "name": ?name } WHERE { ?name ?a ?b } LIMIT 3


log4j:WARN No appenders could be found for logger (Jena).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for 
more info.
Parsed query successfully!
---

Enter input: 
```

Then did a `mvn install -DskipTests -Pdev`, and copied 
`apache-jena-fuseki-3.7.0-SNAPSHOT.tar.gz` elsewhere. Unpacked it, and started 
`fuseki-server`.

Used an in-memory dataset in Fuseki2, loading the `books.ttl` example 
shipped with Jena code.

Finally, used the query found in the JIRA ticket to retrieve the JSON 
result:

```
PREFIX purl: 
PREFIX w3:  
PREFIX :  

JSON {
"author": ?author, 
"title": ?title 
}
WHERE 
{
?book purl:creator ?author .
?book purl:title ?title . 
FILTER (?author = 'J.K. Rowling')
}
```
And here's the output:

```
[ { 
  "author" : "J.K. Rowling" ,
  "title" : "Harry Potter and the Deathly Hallows"
}
{ 
  "author" : "J.K. Rowling" ,
  "title" : "Harry Potter and the Philosopher's Stone"
}
{ 
  "author" : "J.K. Rowling" ,
  "title" : "Harry Potter and the Order of the Phoenix"
}
{ 
  "author" : "J.K. Rowling" ,
  "title" : "Harry Potter and the Half-Blood Prince"
}
 ]
```

Going to push-force onto this branch now, so the pull request should be 
rebased onto the latest changes in a couple minutes.


> 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

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/114
  
Rebased!

Tested the `ARQParser` main method (which is added here, but I find very 
handy for quickly testing it, but happy to remove if others prefer). And got 
the following:

```
Enter input: JSON { "name": ?name } WHERE { ?name ?a ?b } LIMIT 3


log4j:WARN No appenders could be found for logger (Jena).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for 
more info.
Parsed query successfully!
---

Enter input: 
```

Then did a `mvn install -DskipTests -Pdev`, and copied 
`apache-jena-fuseki-3.7.0-SNAPSHOT.tar.gz` elsewhere. Unpacked it, and started 
`fuseki-server`.

Used an in-memory dataset in Fuseki2, loading the `books.ttl` example 
shipped with Jena code.

Finally, used the query found in the JIRA ticket to retrieve the JSON 
result:

```
PREFIX purl: 
PREFIX w3:  
PREFIX :  

JSON {
"author": ?author, 
"title": ?title 
}
WHERE 
{
?book purl:creator ?author .
?book purl:title ?title . 
FILTER (?author = 'J.K. Rowling')
}
```
And here's the output:

```
[ { 
  "author" : "J.K. Rowling" ,
  "title" : "Harry Potter and the Deathly Hallows"
}
{ 
  "author" : "J.K. Rowling" ,
  "title" : "Harry Potter and the Philosopher's Stone"
}
{ 
  "author" : "J.K. Rowling" ,
  "title" : "Harry Potter and the Order of the Phoenix"
}
{ 
  "author" : "J.K. Rowling" ,
  "title" : "Harry Potter and the Half-Blood Prince"
}
 ]
```

Going to push-force onto this branch now, so the pull request should be 
rebased onto the latest changes in a couple minutes.


---

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394074#comment-16394074
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/114
  
Rebasing again, now manually, testing in Eclipse. Previous branch before 
the GitHub rebase archived at https://github.com/kinow/jena/tree/JENA-632-3


> 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

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/114
  
Rebasing again, now manually, testing in Eclipse. Previous branch before 
the GitHub rebase archived at https://github.com/kinow/jena/tree/JENA-632-3


---

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393592#comment-16393592
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/114
  
Rebased using GitHub's interface :tada:  (never used it before, hope didn't 
make any silly mistakes :-) ).

Good points @afs ! I noticed the existing SPARQL to JSON result writers, so 
adjusted a bit the code to use that.

Now when I try to rebase against the master branch I get a bunch of 
conflicts, but GitHub web interface seems to indicate it's all good. I was 
trying to find a simple way to rebase it, but if I can't fix the conflicts and 
compile & test it, I'll just revert to what was before and then just manually 
rebase :)


> 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

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/114
  
Rebased using GitHub's interface :tada:  (never used it before, hope didn't 
make any silly mistakes :-) ).

Good points @afs ! I noticed the existing SPARQL to JSON result writers, so 
adjusted a bit the code to use that.

Now when I try to rebase against the master branch I get a bunch of 
conflicts, but GitHub web interface seems to indicate it's all good. I was 
trying to find a simple way to rebase it, but if I can't fix the conflicts and 
compile & test it, I'll just revert to what was before and then just manually 
rebase :)


---

[jira] [Commented] (JENA-1495) Covariant return type for Model's PrefixMapping methods.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393536#comment-16393536
 ] 

ASF GitHub Bot commented on JENA-1495:
--

Github user afs commented on the issue:

https://github.com/apache/jena/pull/368
  
Closing this PR. I see these commits in the codebase under different SHA1 
ids (b8b482ecaa and 036ebce8ed).

@jaco0646 - thanks!


> Covariant return type for Model's PrefixMapping methods.
> 
>
> Key: JENA-1495
> URL: https://issues.apache.org/jira/browse/JENA-1495
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.6.0
>Reporter: Adam Jacobs
>Assignee: A. Soroka
>Priority: Trivial
>  Labels: easyfix
> Fix For: Jena 3.7.0
>
>
> The {{Model}} interface inherits several methods from {{PrefixMapping}} which 
> return {{this}}.
>  The return type of these methods can be refined to allow call chaining with 
> the {{Model}} object.
> There appear to be two concrete implementations of {{Model}} which override 
> the {{PrefixMapping}} methods: {{ModelCom}} and {{SecuredModelImpl}}. Steps 
> to add covariant return types for prefix mapping are as follows.
> Add these six methods to the Model interface.
>  # Model setNsPrefix( String prefix, String uri );
>  # Model removeNsPrefix( String prefix );
>  # Model clearNsPrefixMap();
>  # Model setNsPrefixes( PrefixMapping other );
>  # Model setNsPrefixes( Map map );
>  # Model withDefaultMappings( PrefixMapping map );
> ...and update ModelCom accordingly.
> Add these six methods to the SecuredModel interface.
>  # SecuredModel setNsPrefix( String prefix, String uri );
>  # SecuredModel removeNsPrefix( String prefix ); // This method is already 
> defined.
>  # SecuredModel clearNsPrefixMap();
>  # SecuredModel setNsPrefixes( PrefixMapping other );
>  # SecuredModel setNsPrefixes( Map map );
>  # SecuredModel withDefaultMappings( PrefixMapping map );
> ...and update SecuredModelImpl accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #379: Refactor tests; don't test for GregorianYear< 0

[afs]

GitHub user afs opened a pull request:

https://github.com/apache/jena/pull/379

Refactor tests; don't test for GregorianYear< 0

Follow on from JENA-1503.

This splits up some `TestTypeLiteral` tests and removes the old testing for 
GregorianYear< 0 which didn't test correctly, and couldn't.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afs/jena test_tidy

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/379.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 #379


commit daf349022c2188345ba4630e4e074594b697bda2
Author: Andy Seaborne 
Date:   2018-03-09T16:47:57Z

Refactor tests; don't test for GregorianYear< 0




---

[jira] [Resolved] (JENA-1503) Bug in XSDDateTime toString

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne resolved JENA-1503.
-
   Resolution: Fixed
Fix Version/s: Jena 3.7.0

Fix applied - thanks!

> Bug in XSDDateTime toString
> ---
>
> Key: JENA-1503
> URL: https://issues.apache.org/jira/browse/JENA-1503
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Datatypes
>Reporter: Derek Law
>Assignee: Andy Seaborne
>Priority: Major
>  Labels: beginner, easyfix, newbie, patch
> Fix For: Jena 3.7.0
>
> Attachments: proposed_fix.txt
>
>   Original Estimate: 0.1h
>  Remaining Estimate: 0.1h
>
> toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
> incorrect output when year value is between -999 and -1.
> For example : the representation of date time "-0001-01-01T00:00:00" in 
> XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
> however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"
> proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena issue #368: JENA-1495 Return Model from PrefixMapping methods.

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/368
  
Closing this PR. I see these commits in the codebase under different SHA1 
ids (b8b482ecaa and 036ebce8ed).

@jaco0646 - thanks!


---

[GitHub] jena pull request #368: JENA-1495 Return Model from PrefixMapping methods.

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/368


---

[jira] [Commented] (JENA-1495) Covariant return type for Model's PrefixMapping methods.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393533#comment-16393533
 ] 

ASF GitHub Bot commented on JENA-1495:
--

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/368


> Covariant return type for Model's PrefixMapping methods.
> 
>
> Key: JENA-1495
> URL: https://issues.apache.org/jira/browse/JENA-1495
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.6.0
>Reporter: Adam Jacobs
>Assignee: A. Soroka
>Priority: Trivial
>  Labels: easyfix
> Fix For: Jena 3.7.0
>
>
> The {{Model}} interface inherits several methods from {{PrefixMapping}} which 
> return {{this}}.
>  The return type of these methods can be refined to allow call chaining with 
> the {{Model}} object.
> There appear to be two concrete implementations of {{Model}} which override 
> the {{PrefixMapping}} methods: {{ModelCom}} and {{SecuredModelImpl}}. Steps 
> to add covariant return types for prefix mapping are as follows.
> Add these six methods to the Model interface.
>  # Model setNsPrefix( String prefix, String uri );
>  # Model removeNsPrefix( String prefix );
>  # Model clearNsPrefixMap();
>  # Model setNsPrefixes( PrefixMapping other );
>  # Model setNsPrefixes( Map map );
>  # Model withDefaultMappings( PrefixMapping map );
> ...and update ModelCom accordingly.
> Add these six methods to the SecuredModel interface.
>  # SecuredModel setNsPrefix( String prefix, String uri );
>  # SecuredModel removeNsPrefix( String prefix ); // This method is already 
> defined.
>  # SecuredModel clearNsPrefixMap();
>  # SecuredModel setNsPrefixes( PrefixMapping other );
>  # SecuredModel setNsPrefixes( Map map );
>  # SecuredModel withDefaultMappings( PrefixMapping map );
> ...and update SecuredModelImpl accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1503) Bug in XSDDateTime toString

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393528#comment-16393528
 ] 

ASF GitHub Bot commented on JENA-1503:
--

GitHub user afs opened a pull request:

https://github.com/apache/jena/pull/379

Refactor tests; don't test for GregorianYear< 0

Follow on from JENA-1503.

This splits up some `TestTypeLiteral` tests and removes the old testing for 
GregorianYear< 0 which didn't test correctly, and couldn't.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afs/jena test_tidy

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/379.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 #379


commit daf349022c2188345ba4630e4e074594b697bda2
Author: Andy Seaborne 
Date:   2018-03-09T16:47:57Z

Refactor tests; don't test for GregorianYear< 0




> Bug in XSDDateTime toString
> ---
>
> Key: JENA-1503
> URL: https://issues.apache.org/jira/browse/JENA-1503
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Datatypes
>Reporter: Derek Law
>Assignee: Andy Seaborne
>Priority: Major
>  Labels: beginner, easyfix, newbie, patch
> Fix For: Jena 3.7.0
>
> Attachments: proposed_fix.txt
>
>   Original Estimate: 0.1h
>  Remaining Estimate: 0.1h
>
> toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
> incorrect output when year value is between -999 and -1.
> For example : the representation of date time "-0001-01-01T00:00:00" in 
> XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
> however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"
> proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1503) Bug in XSDDateTime toString

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393520#comment-16393520
 ] 

ASF GitHub Bot commented on JENA-1503:
--

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/377


> Bug in XSDDateTime toString
> ---
>
> Key: JENA-1503
> URL: https://issues.apache.org/jira/browse/JENA-1503
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Datatypes
>Reporter: Derek Law
>Assignee: Andy Seaborne
>Priority: Major
>  Labels: beginner, easyfix, newbie, patch
> Attachments: proposed_fix.txt
>
>   Original Estimate: 0.1h
>  Remaining Estimate: 0.1h
>
> toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
> incorrect output when year value is between -999 and -1.
> For example : the representation of date time "-0001-01-01T00:00:00" in 
> XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
> however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"
> proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1503) Bug in XSDDateTime toString

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393519#comment-16393519
 ] 

ASF subversion and git services commented on JENA-1503:
---

Commit c656cf10734f4d6316c28e96090588425de8d981 in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=c656cf1 ]

JENA-1503: Merge commit 'refs/pull/377/head' of https://github.com/apache/jena

This closes #377.


> Bug in XSDDateTime toString
> ---
>
> Key: JENA-1503
> URL: https://issues.apache.org/jira/browse/JENA-1503
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Datatypes
>Reporter: Derek Law
>Assignee: Andy Seaborne
>Priority: Major
>  Labels: beginner, easyfix, newbie, patch
> Attachments: proposed_fix.txt
>
>   Original Estimate: 0.1h
>  Remaining Estimate: 0.1h
>
> toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
> incorrect output when year value is between -999 and -1.
> For example : the representation of date time "-0001-01-01T00:00:00" in 
> XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
> however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"
> proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1503) Bug in XSDDateTime toString

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393518#comment-16393518
 ] 

ASF subversion and git services commented on JENA-1503:
---

Commit bd1ee9ed2a0aebc055f8b280e31fe087686934c8 in jena's branch 
refs/heads/master from [~ajs6f]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=bd1ee9e ]

JENA-1503: Bug in XSDDateTime toString


> Bug in XSDDateTime toString
> ---
>
> Key: JENA-1503
> URL: https://issues.apache.org/jira/browse/JENA-1503
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Datatypes
>Reporter: Derek Law
>Assignee: Andy Seaborne
>Priority: Major
>  Labels: beginner, easyfix, newbie, patch
> Attachments: proposed_fix.txt
>
>   Original Estimate: 0.1h
>  Remaining Estimate: 0.1h
>
> toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
> incorrect output when year value is between -999 and -1.
> For example : the representation of date time "-0001-01-01T00:00:00" in 
> XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
> however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"
> proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #377: JENA-1503: Bug in XSDDateTime toString

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/377


---

[jira] [Commented] (JENA-1504) TrigBlock writer can lose triples

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393345#comment-16393345
 ] 

ASF GitHub Bot commented on JENA-1504:
--

GitHub user afs opened a pull request:

https://github.com/apache/jena/pull/378

JENA-1504: Fix batch handling.

Fix batch handling.
Fix new line output.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afs/jena trig-blocks

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/378.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 #378


commit f3549cabc95113412aa6d7e2e82066f0d836cd1d
Author: Andy Seaborne 
Date:   2018-03-09T18:33:50Z

JENA-1504: Fix batch handling.

Fix new line output.




> TrigBlock writer can lose triples
> -
>
> Key: JENA-1504
> URL: https://issues.apache.org/jira/browse/JENA-1504
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> Example: run {{riot --out TRIG }}.
> {noformat}
> PREFIX : 
> :s :p "Triple" .
> # This cause the above to be lost.
> :g { :s :p "NG", "NG1" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #378: JENA-1504: Fix batch handling.

[afs]

GitHub user afs opened a pull request:

https://github.com/apache/jena/pull/378

JENA-1504: Fix batch handling.

Fix batch handling.
Fix new line output.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afs/jena trig-blocks

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/378.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 #378


commit f3549cabc95113412aa6d7e2e82066f0d836cd1d
Author: Andy Seaborne 
Date:   2018-03-09T18:33:50Z

JENA-1504: Fix batch handling.

Fix new line output.




---

[jira] [Commented] (JENA-1504) TrigBlock writer can lose triples

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393335#comment-16393335
 ] 

Andy Seaborne commented on JENA-1504:
-

It gets the first blank lie wrong as well when the first named graph is output.

> TrigBlock writer can lose triples
> -
>
> Key: JENA-1504
> URL: https://issues.apache.org/jira/browse/JENA-1504
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> Example: run {{riot --out TRIG }}.
> {noformat}
> PREFIX : 
> :s :p "Triple" .
> # This cause the above to be lost.
> :g { :s :p "NG", "NG1" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JENA-1504) TrigBlock writer can lose triples

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne updated JENA-1504:

Summary: TrigBlock writer can lose triples  (was: TrigBlock writer can lose 
quads.)

> TrigBlock writer can lose triples
> -
>
> Key: JENA-1504
> URL: https://issues.apache.org/jira/browse/JENA-1504
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> Example: run {{riot --out TRIG }}.
> {noformat}
> PREFIX : 
> :s :p "Triple" .
> # This cause the above to be lost.
> :g { :s :p "NG", "NG1" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JENA-1504) TrigBlock writer can lose quads.

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne updated JENA-1504:

Summary: TrigBlock writer can lose quads.  (was: TrigBlock writer can loose 
quads.)

> TrigBlock writer can lose quads.
> 
>
> Key: JENA-1504
> URL: https://issues.apache.org/jira/browse/JENA-1504
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.7.0
>
>
> Example: run {{riot --out TRIG }}.
> {noformat}
> PREFIX : 
> :s :p "Triple" .
> # This cause the above to be lost.
> :g { :s :p "NG", "NG1" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1503) Bug in XSDDateTime toString

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393090#comment-16393090
 ] 

ASF GitHub Bot commented on JENA-1503:
--

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/377#discussion_r173498951
  
--- Diff: 
jena-core/src/test/java/org/apache/jena/graph/test/TestTypedLiterals.java ---
@@ -989,7 +991,17 @@ public void testXSDanyURI() {
 Node node2 = NodeFactory.createLiteral("http://example/;, 
XSDDatatype.XSDstring) ;
 assertFalse(node1.sameValueAs(node2)) ;
 }
-
+
+/**
+ * Test a user error report concerning date/time literals from 
JENA-1503
+ */
+public void testDateTimeBug3() {
+final RDFDatatype XSDdateTime = 
TypeMapper.getInstance().getSafeTypeByName(XSD.dateTime.getURI());
--- End diff --

Hey, let's model good behavior! (Says the father of two toddlers.) I'll add 
a commit right now.


> Bug in XSDDateTime toString
> ---
>
> Key: JENA-1503
> URL: https://issues.apache.org/jira/browse/JENA-1503
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Datatypes
>Reporter: Derek Law
>Assignee: Andy Seaborne
>Priority: Major
>  Labels: beginner, easyfix, newbie, patch
> Attachments: proposed_fix.txt
>
>   Original Estimate: 0.1h
>  Remaining Estimate: 0.1h
>
> toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
> incorrect output when year value is between -999 and -1.
> For example : the representation of date time "-0001-01-01T00:00:00" in 
> XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
> however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"
> proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #377: JENA-1503: Bug in XSDDateTime toString

[ajs6f]

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/377#discussion_r173498951
  
--- Diff: 
jena-core/src/test/java/org/apache/jena/graph/test/TestTypedLiterals.java ---
@@ -989,7 +991,17 @@ public void testXSDanyURI() {
 Node node2 = NodeFactory.createLiteral("http://example/;, 
XSDDatatype.XSDstring) ;
 assertFalse(node1.sameValueAs(node2)) ;
 }
-
+
+/**
+ * Test a user error report concerning date/time literals from 
JENA-1503
+ */
+public void testDateTimeBug3() {
+final RDFDatatype XSDdateTime = 
TypeMapper.getInstance().getSafeTypeByName(XSD.dateTime.getURI());
--- End diff --

Hey, let's model good behavior! (Says the father of two toddlers.) I'll add 
a commit right now.


---

[jira] [Commented] (JENA-1503) Bug in XSDDateTime toString

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393085#comment-16393085
 ] 

Andy Seaborne commented on JENA-1503:
-

The route via creating with a {{GregorianCalendar}} is a "feature" of Java 
Gregorian calendar. It does not handle negative years and converts them to 
positive+1.

{noformat}
Calendar cal1 = new GregorianCalendar(-77, 1, 2, 10, 11, 12);
System.out.println(cal1.get(Calendar.YEAR));
{noformat}
==> 78.
This is only in support of app code that uses {{GregorianCalendar}} already.

I will submit some testing changes around this to go after #377.


> Bug in XSDDateTime toString
> ---
>
> Key: JENA-1503
> URL: https://issues.apache.org/jira/browse/JENA-1503
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Datatypes
>Reporter: Derek Law
>Assignee: Andy Seaborne
>Priority: Major
>  Labels: beginner, easyfix, newbie, patch
> Attachments: proposed_fix.txt
>
>   Original Estimate: 0.1h
>  Remaining Estimate: 0.1h
>
> toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
> incorrect output when year value is between -999 and -1.
> For example : the representation of date time "-0001-01-01T00:00:00" in 
> XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
> however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"
> proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1503) Bug in XSDDateTime toString

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393084#comment-16393084
 ] 

ASF GitHub Bot commented on JENA-1503:
--

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/377#discussion_r173497971
  
--- Diff: 
jena-core/src/test/java/org/apache/jena/graph/test/TestTypedLiterals.java ---
@@ -989,7 +991,17 @@ public void testXSDanyURI() {
 Node node2 = NodeFactory.createLiteral("http://example/;, 
XSDDatatype.XSDstring) ;
 assertFalse(node1.sameValueAs(node2)) ;
 }
-
+
+/**
+ * Test a user error report concerning date/time literals from 
JENA-1503
+ */
+public void testDateTimeBug3() {
+final RDFDatatype XSDdateTime = 
TypeMapper.getInstance().getSafeTypeByName(XSD.dateTime.getURI());
--- End diff --

More FYI than anything else: There is a constant `XSDDatatype.XSDdateTime`.


> Bug in XSDDateTime toString
> ---
>
> Key: JENA-1503
> URL: https://issues.apache.org/jira/browse/JENA-1503
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Datatypes
>Reporter: Derek Law
>Assignee: Andy Seaborne
>Priority: Major
>  Labels: beginner, easyfix, newbie, patch
> Attachments: proposed_fix.txt
>
>   Original Estimate: 0.1h
>  Remaining Estimate: 0.1h
>
> toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
> incorrect output when year value is between -999 and -1.
> For example : the representation of date time "-0001-01-01T00:00:00" in 
> XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
> however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"
> proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #377: JENA-1503: Bug in XSDDateTime toString

[afs]

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/377#discussion_r173497971
  
--- Diff: 
jena-core/src/test/java/org/apache/jena/graph/test/TestTypedLiterals.java ---
@@ -989,7 +991,17 @@ public void testXSDanyURI() {
 Node node2 = NodeFactory.createLiteral("http://example/;, 
XSDDatatype.XSDstring) ;
 assertFalse(node1.sameValueAs(node2)) ;
 }
-
+
+/**
+ * Test a user error report concerning date/time literals from 
JENA-1503
+ */
+public void testDateTimeBug3() {
+final RDFDatatype XSDdateTime = 
TypeMapper.getInstance().getSafeTypeByName(XSD.dateTime.getURI());
--- End diff --

More FYI than anything else: There is a constant `XSDDatatype.XSDdateTime`.


---

[jira] [Assigned] (JENA-1503) Bug in XSDDateTime toString

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne reassigned JENA-1503:
---

Assignee: Andy Seaborne

> Bug in XSDDateTime toString
> ---
>
> Key: JENA-1503
> URL: https://issues.apache.org/jira/browse/JENA-1503
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Datatypes
>Reporter: Derek Law
>Assignee: Andy Seaborne
>Priority: Major
>  Labels: beginner, easyfix, newbie, patch
> Attachments: proposed_fix.txt
>
>   Original Estimate: 0.1h
>  Remaining Estimate: 0.1h
>
> toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
> incorrect output when year value is between -999 and -1.
> For example : the representation of date time "-0001-01-01T00:00:00" in 
> XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
> however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"
> proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (JENA-1495) Covariant return type for Model's PrefixMapping methods.

[A. Soroka (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

A. Soroka resolved JENA-1495.
-
   Resolution: Fixed
Fix Version/s: Jena 3.7.0

> Covariant return type for Model's PrefixMapping methods.
> 
>
> Key: JENA-1495
> URL: https://issues.apache.org/jira/browse/JENA-1495
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.6.0
>Reporter: Adam Jacobs
>Assignee: A. Soroka
>Priority: Trivial
>  Labels: easyfix
> Fix For: Jena 3.7.0
>
>
> The {{Model}} interface inherits several methods from {{PrefixMapping}} which 
> return {{this}}.
>  The return type of these methods can be refined to allow call chaining with 
> the {{Model}} object.
> There appear to be two concrete implementations of {{Model}} which override 
> the {{PrefixMapping}} methods: {{ModelCom}} and {{SecuredModelImpl}}. Steps 
> to add covariant return types for prefix mapping are as follows.
> Add these six methods to the Model interface.
>  # Model setNsPrefix( String prefix, String uri );
>  # Model removeNsPrefix( String prefix );
>  # Model clearNsPrefixMap();
>  # Model setNsPrefixes( PrefixMapping other );
>  # Model setNsPrefixes( Map map );
>  # Model withDefaultMappings( PrefixMapping map );
> ...and update ModelCom accordingly.
> Add these six methods to the SecuredModel interface.
>  # SecuredModel setNsPrefix( String prefix, String uri );
>  # SecuredModel removeNsPrefix( String prefix ); // This method is already 
> defined.
>  # SecuredModel clearNsPrefixMap();
>  # SecuredModel setNsPrefixes( PrefixMapping other );
>  # SecuredModel setNsPrefixes( Map map );
>  # SecuredModel withDefaultMappings( PrefixMapping map );
> ...and update SecuredModelImpl accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (JENA-1495) Covariant return type for Model's PrefixMapping methods.

[A. Soroka (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

A. Soroka reassigned JENA-1495:
---

Assignee: A. Soroka

> Covariant return type for Model's PrefixMapping methods.
> 
>
> Key: JENA-1495
> URL: https://issues.apache.org/jira/browse/JENA-1495
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.6.0
>Reporter: Adam Jacobs
>Assignee: A. Soroka
>Priority: Trivial
>  Labels: easyfix
> Fix For: Jena 3.7.0
>
>
> The {{Model}} interface inherits several methods from {{PrefixMapping}} which 
> return {{this}}.
>  The return type of these methods can be refined to allow call chaining with 
> the {{Model}} object.
> There appear to be two concrete implementations of {{Model}} which override 
> the {{PrefixMapping}} methods: {{ModelCom}} and {{SecuredModelImpl}}. Steps 
> to add covariant return types for prefix mapping are as follows.
> Add these six methods to the Model interface.
>  # Model setNsPrefix( String prefix, String uri );
>  # Model removeNsPrefix( String prefix );
>  # Model clearNsPrefixMap();
>  # Model setNsPrefixes( PrefixMapping other );
>  # Model setNsPrefixes( Map map );
>  # Model withDefaultMappings( PrefixMapping map );
> ...and update ModelCom accordingly.
> Add these six methods to the SecuredModel interface.
>  # SecuredModel setNsPrefix( String prefix, String uri );
>  # SecuredModel removeNsPrefix( String prefix ); // This method is already 
> defined.
>  # SecuredModel clearNsPrefixMap();
>  # SecuredModel setNsPrefixes( PrefixMapping other );
>  # SecuredModel setNsPrefixes( Map map );
>  # SecuredModel withDefaultMappings( PrefixMapping map );
> ...and update SecuredModelImpl accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Towards Jena 3.7.0

[ajs6f]

> On Mar 9, 2018, at 10:23 AM, Andy Seaborne  wrote:
> 
> Status?:
> * PR#368 "Return Model from PrefixMapping methods" JENA-1495

Just merged, I will close the ticket.

> * JENA-1499 : PR done, JIRA open - is there work still in progress?

My mistake-- I just closed the ticket.

ajs6f

[jira] [Resolved] (JENA-1499) The TIM dataset retains a memory of named graphs after deleting all quads.

[A. Soroka (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

A. Soroka resolved JENA-1499.
-
   Resolution: Fixed
Fix Version/s: Jena 3.7.0

> The TIM dataset retains a memory of named graphs after deleting all quads.
> --
>
> Key: JENA-1499
> URL: https://issues.apache.org/jira/browse/JENA-1499
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Assignee: A. Soroka
>Priority: Minor
> Fix For: Jena 3.7.0
>
>
> Illustration:
> {noformat}
> DatasetGraph dsg = DatasetGraphFactory.createTxnMem();
> Quad q = SSE.parseQuad("(:g :s :p :o)");
> dsg.add(q);
> dsg.delete(q);
> Iter.print(dsg.listGraphNodes());
> {noformat}
> prints {{http://example/g}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Towards Jena 3.7.0

[Andy Seaborne]

How are we looking for Jena 3.7.0?

I can RM.  Don't let me stop anyone else but changes in Fuseki for 
custom services will help me so this is $job time.


I suggest we email users@ to say we are hoping to release in the coming 
weeks (no specific date), and say "please test (=> "this is your last 
chance this cycle") and also send the Java9 message.


I have web site documentation updates for Txn and for RDFConnection to do.

Andy

42 JIRA resolved this release:
https://s.apache.org/jena-3.7.0-jira

In-progress:
* JENA-1501, #375 : systemd init file. (ready to go)
Others?

Status?:
* PR#368 "Return Model from PrefixMapping methods" JENA-1495
* JENA-1499 : PR done, JIRA open - is there work still in progress?
* PR#330 : Obfuscation Support

Lib upgrades: none.

** No jena-maven-tools (broken by Apache v19)

Material to go toward the ANN (this is notes, not the text)

--

** Java9: Running on a Java9 platform is supported - language 
requirement remain Java8.  More below.



JENA-1461 - Allow ARQ custom functions to be written in JavaScript
http://jena.apache.org/documentation/query/javascript-functions.html

JENA-1458, JENA-1483 - Transaction Promotion
http://jena.staging.apache.org/documentation/txn/

The fully transactional storage (TDB, TIM,TDB2) now support transaction 
promotion from "read" to "write", reducing the need for write 
transactions when they may not be needed.


JENA-1435 - Provide extensibility of Fuseki with new services

JENA-1453 - Lucene indexes using a graph field are smaller

This release includes updates to the Jena Lucene integration that 
reduces the size of the documents indexed by Lucene and reduces the size 
of the resulting indexes. Re-indexing is not necessary as the changes 
are compatible with existing indexes. Additionally, there is an optional 
output argument for text:query that allows to retrieve the graph that 
contains a result triple. See the updated

http://jena.apache.org/documentation/query/text-query.html



JENA-1391: Add methods for ModelCollectors to API in ModelUtils

JENA-1492   
Transactions now passed down for nested models.

JENA-1490   
Working with Blank Nodes with Fuseki

JENA-1482 Robustness checks for (mis)use of TDB
"Add testing when creating Bindings to catch null values earlier. "

== API

JENA-1389   
Return `this` rather than `void` from Dataset
JENA-1495
PR#368 "Return Model from PrefixMapping methods"


** Java9

Java8 is the current LTS version of Java and receives security updates. 
The next LTS is Java11. [Sched]


[Sched] http://www.oracle.com/technetwork/java/eol-135779.html

There are different cases for running with Java9:

[1] Run on a Java9 JVM
[2] Build using Java9 JDK, output Java8 classfiles.
[3] Java9 required - language features and runtime library
[4] Java9 modules


[1] at Jena 3.7.0, running with a Java9 platform (except as noted below) 
is supported.


[2] at Jena 3.7.0, running maven using Java9 to produce Java8 bytecode 
is supported (expect as noted).  We now run a Jenkins job daily to check 
this for the main jars.


[3] The project has no current plans to require a Java9 language 
runtime. The language requirement is still Java8.


[4] Jena jars can work as automatic modules but Jena itself does not 
provide a "modules" version. Proper migration needs all the dependencies 
to be modules, and also has implications on the upstream. Contribution 
and discussions are welcome!


For discussion and background see

[A] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
[B] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html

And note: Java 9 is obsolete March 2018, as soon as java10 comes out.
http://openjdk.java.net/projects/jdk/10/#Schedule

Notes:

jena-elephas depends on Hadoop that depends on jdk.tools that is not 
available in Java9.

[jira] [Commented] (JENA-1503) Bug in XSDDateTime toString

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16392990#comment-16392990
 ] 

ASF GitHub Bot commented on JENA-1503:
--

GitHub user ajs6f opened a pull request:

https://github.com/apache/jena/pull/377

JENA-1503: Bug in XSDDateTime toString



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ajs6f/jena JENA-1503

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/377.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 #377


commit bd1ee9ed2a0aebc055f8b280e31fe087686934c8
Author: ajs6f 
Date:   2018-03-09T15:19:28Z

JENA-1503: Bug in XSDDateTime toString




> Bug in XSDDateTime toString
> ---
>
> Key: JENA-1503
> URL: https://issues.apache.org/jira/browse/JENA-1503
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Datatypes
>Reporter: Derek Law
>Priority: Major
>  Labels: beginner, easyfix, newbie, patch
> Attachments: proposed_fix.txt
>
>   Original Estimate: 0.1h
>  Remaining Estimate: 0.1h
>
> toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
> incorrect output when year value is between -999 and -1.
> For example : the representation of date time "-0001-01-01T00:00:00" in 
> XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
> however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"
> proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #377: JENA-1503: Bug in XSDDateTime toString

[ajs6f]

GitHub user ajs6f opened a pull request:

https://github.com/apache/jena/pull/377

JENA-1503: Bug in XSDDateTime toString



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ajs6f/jena JENA-1503

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/377.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 #377


commit bd1ee9ed2a0aebc055f8b280e31fe087686934c8
Author: ajs6f 
Date:   2018-03-09T15:19:28Z

JENA-1503: Bug in XSDDateTime toString




---

[jira] [Commented] (JENA-1503) Bug in XSDDateTime toString

[A. Soroka (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16392956#comment-16392956
 ] 

A. Soroka commented on JENA-1503:
-

I'm making a PR right now.

> Bug in XSDDateTime toString
> ---
>
> Key: JENA-1503
> URL: https://issues.apache.org/jira/browse/JENA-1503
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Datatypes
>Reporter: Derek Law
>Priority: Major
>  Labels: beginner, easyfix, newbie, patch
> Attachments: proposed_fix.txt
>
>   Original Estimate: 0.1h
>  Remaining Estimate: 0.1h
>
> toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
> incorrect output when year value is between -999 and -1.
> For example : the representation of date time "-0001-01-01T00:00:00" in 
> XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
> however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"
> proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1503) Bug in XSDDateTime toString

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16392952#comment-16392952
 ] 

Andy Seaborne commented on JENA-1503:
-

Derke - thank you for the report and fix.

Here is how to make it happen.
{noformat}
Node n = SSE.parseNode("'-0001-02-03T04:05:06'^^xsd:dateTime");
System.out.println(n.getLiteralValue());
{noformat}
The fix works.

The route via creating with a {{Calendar}} (i.e. {{GregorianCalendar}}) does 
not show this because the negative is lost, which is why the test 
{{TestTypeLiterals.testDateTime}} appears to pass.  There again, 
{{GregorianCalendar}} has a year zero and the ISO calendar does not. 


> Bug in XSDDateTime toString
> ---
>
> Key: JENA-1503
> URL: https://issues.apache.org/jira/browse/JENA-1503
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Datatypes
>Reporter: Derek Law
>Priority: Major
>  Labels: beginner, easyfix, newbie, patch
> Attachments: proposed_fix.txt
>
>   Original Estimate: 0.1h
>  Remaining Estimate: 0.1h
>
> toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
> incorrect output when year value is between -999 and -1.
> For example : the representation of date time "-0001-01-01T00:00:00" in 
> XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
> however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"
> proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1503) Bug in XSDDateTime toString

[A. Soroka (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16392924#comment-16392924
 ] 

A. Soroka commented on JENA-1503:
-

Looks like the mirror-image of JENA-565. Thanks for the report, [~dl]!

> Bug in XSDDateTime toString
> ---
>
> Key: JENA-1503
> URL: https://issues.apache.org/jira/browse/JENA-1503
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Datatypes
>Reporter: Derek Law
>Priority: Major
>  Labels: beginner, easyfix, newbie, patch
> Attachments: proposed_fix.txt
>
>   Original Estimate: 0.1h
>  Remaining Estimate: 0.1h
>
> toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
> incorrect output when year value is between -999 and -1.
> For example : the representation of date time "-0001-01-01T00:00:00" in 
> XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
> however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"
> proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1488) SelectiveFoldingFilter for jena-text

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16392865#comment-16392865
 ] 

Bruno P. Kinoshita commented on JENA-1488:
--

Updated my current branch, removing the assembler changes and the analyzer. Now 
it actually holds one single file, 
[/org/apache/jena/query/text/filter/SelectiveFoldingFilter.java|https://github.com/apache/jena/compare/apache:46e2f56...kinow:d90ffa0]

I have not added tests, not squashed commits, removed main method, etc, as the 
code may still need some further massaging.

The output of the main method now would be:
{noformat}
TERM = Senora
TERM = Siobhan
TERM = look
TERM = at
TERM = that
TERM = façade
{noformat}
So the _façade_ keep the cedilla, as it was whitelisted. If the letter 'ñ' was 
added to the white-list, then the first term found would actually be _Señora_. 
After using the white-list, the code delegates it to a method from the existing 
ASCIIFoldingFilter.

Now just need to find a way to rig it up together with Jena text analyzers. I 
liked [~code-ferret], though I am not entirely sure where/how to update the 
ConfigurableAnalyzer. I tried using it, and noticed I couldn't pass the 
white-list when creating an analyzer/filter.

> 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] [Created] (JENA-1503) Bug in XSDDateTime toString

[Derek Law (JIRA)]

Derek Law created JENA-1503:
---

 Summary: Bug in XSDDateTime toString
 Key: JENA-1503
 URL: https://issues.apache.org/jira/browse/JENA-1503
 Project: Apache Jena
  Issue Type: Bug
  Components: Datatypes
Reporter: Derek Law
 Attachments: proposed_fix.txt

toString() for the class org.apache.jena.datatypes.xsd.XSDDateTime generates 
incorrect output when year value is between -999 and -1.

For example : the representation of date time "-0001-01-01T00:00:00" in 
XSDDateTime class has data array of (-1,1,1,0,0,0,0,0,0) and mask = 15. 
however, the toString() method incorrectly outputs "000-1-01-01T00:00:00"

proposed fix attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (JENA-1488) SelectiveFoldingFilter for jena-text

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita reassigned JENA-1488:


Assignee: Bruno P. Kinoshita

> 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] [Updated] (JENA-1502) SPARQL extensions for processing CSV, XML, JSON and remote data

[Claus Stadler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Stadler updated JENA-1502:

Description: 
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

An example of these extension functions:
{code:sql}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
WHERE {
  # Magic property to fetch the text (at present always a string) of some URL
   url:text ?src .
  # Parse into a literal of JSON datatype
  BIND(STRDT(?src, xsd:json) AS ?o)
  # Access a JSON array attribute
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  # Create bindings for each element in the JSON document
  ?stopNames json:unnest (?l ?i) .
  # An ordinary join with existing data
  GRAPH ?x { ?s eg:stopId ?i }
}
{code}


In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
perform such integration tasks - and for instance one could already start a 
Fuseki  in order to play around with conversions in a Web interface.



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions should look like. For instance, right now we use two 
custom datatypes, xsd:json and xsd:xml which obviously should be replaced by 
better IRIs.
* Maybe the functionality of running files containing sequences of SPARQL 
queries from the command line could also be added to Jena directly - as I think 
there is no magic outside the scope of Jena to it.


  was:
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

An example of these extension functions:
{code:sql}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
WHERE {
   url:text ?src .
  BIND(STRDT(?src, xsd:json) AS ?o)
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}


In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
perform such integration tasks - and for instance one could already start a 
Fuseki  in order to play around with conversions in a Web interface.



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and 

[jira] [Updated] (JENA-1502) SPARQL extensions for processing CSV, XML, JSON and remote data

[Claus Stadler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Stadler updated JENA-1502:

Description: 
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

An example of these extension functions:
{code:sql}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
WHERE {
   url:text ?src .
  BIND(STRDT(?src, xsd:json) AS ?o)
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}


In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
perform such integration tasks - and for instance one could already start a 
Fuseki  in order to play around with conversions in a Web interface.



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions should look like. For instance, right now we use two 
custom datatypes, xsd:json and xsd:xml which obviously should be replaced by 
better IRIs.
* Maybe the functionality of running files containing sequences of SPARQL 
queries from the command line could also be added to Jena directly - as I think 
there is no magic outside the scope of Jena to it.


  was:
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

An example of these extension functions:
{code:sql}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
WHERE {
  ?x eg:workload ?o
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}


In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
perform such integration tasks - and for instance one could already start a 
Fuseki  in order to play around with conversions in a Web interface.



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions should look like. For instance, right now we use two 
custom datatypes, xsd:json and xsd:xml which 

[jira] [Updated] (JENA-1502) SPARQL extensions for processing CSV, XML, JSON and remote data

[Claus Stadler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Stadler updated JENA-1502:

Summary: SPARQL extensions for processing CSV, XML, JSON and remote data  
(was: SPARQL extensions for processing CSV, XML and JSON)

> SPARQL extensions for processing CSV, XML, JSON and remote data
> ---
>
> Key: JENA-1502
> URL: https://issues.apache.org/jira/browse/JENA-1502
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Claus Stadler
>Priority: Major
>
> Many systems have been built so far for transforming heterogeneous data - 
> most prominently CSV, XML and JSON) to RDF.
> As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
> an extremely convenient tool for this task.
> To clarify our point, for a project we have to convert several (open) 
> datasets, and we came up with a solution where we just have to execute a 
> sequence of SPARQL queries making use of our ARQ extensions.
> In [this 
> repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
>  there are sub folders with JSON datasets, and the conversion is just a 
> matter of running the SPARQL queries in the files 
> [workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
>  (which adds triples describing workloads into a jena in-memory dataset) and 
> [process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
>  (which processes all workloads in that dataset and inserts triples into a 
> (named) result graph). We created a [thin command line 
> wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to 
> conveniently run these conversions.
> An example of these extension functions:
> {code:sql}
> # Add labels of train / bus stops
> INSERT {
>   GRAPH eg:result { ?s rdfs:label ?l }
> }
> WHERE {
>   ?x eg:workload ?o
>   BIND(json:path(?o, "$.stopNames") AS ?stopNames)
>   ?stopNames json:unnest (?l ?i) .
>   GRAPH ?x { ?s eg:stopId ?i }
> }
> {code}
> In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
> perform such integration tasks - and for instance one could already start a 
> Fuseki  in order to play around with conversions in a Web interface.
> * Is there interest to integrate our ARQ [SPARQL extension 
> functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
>  into Jena? If so, what would we have to do and where (which existing or new 
> jena module) would be the most appropriate place?
> We are also open to discussion and changes on what exactly the signatures of 
> these extension functions should look like. For instance, right now we use 
> two custom datatypes, xsd:json and xsd:xml which obviously should be replaced 
> by better IRIs.
> * Maybe the functionality of running files containing sequences of SPARQL 
> queries from the command line could also be added to Jena directly - as I 
> think there is no magic outside the scope of Jena to it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JENA-1502) SPARQL extensions for processing CSV, XML and JSON

[Claus Stadler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Stadler updated JENA-1502:

Description: 
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

An example of these extension functions:
{code:sql}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
WHERE {
  ?x eg:workload ?o
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}


In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
perform such integration tasks - and for instance one could already start a 
Fuseki  in order to play around with conversions in a Web interface.



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions should look like. For instance, right now we use two 
custom datatypes, xsd:json and xsd:xml which obviously should be replaced by 
better IRIs.
* Maybe the functionality of running files containing sequences of SPARQL 
queries from the command line could also be added to Jena directly - as I think 
there is no magic outside the scope of Jena to it.


  was:
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

An example of these extension functions:
{code:sql}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
WHERE {
  ?x eg:workload ?o
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}


In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
perform such integration tasks - and for instance one could already start a 
Fuseki  in order to play around with conversions in a Web interface.



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions should look like. For instance, right now we use two 
custom datatypes, xsd:json and xsd:xml which obviously should be replaced by 
better 

[jira] [Updated] (JENA-1502) SPARQL extensions for processing CSV, XML and JSON

[Claus Stadler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Stadler updated JENA-1502:

Description: 
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

An example of these extension functions:
{code:sql}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
WHERE {
  ?x eg:workload ?o
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}


In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
perform such integration tasks - and for instance one could already start a 
Fuseki  in order to play around with conversions in a Web interface.



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions should look like. For instance, right now we use two 
custom datatypes, xsd:json and xsd:xml which obviously should be replaced by 
better IRIs.
* Maybe the functionality of running files containing sequences of SPARQL 
queries could also be added to Jena directly - as I think there is no magic 
outside the scope of Jena to it.


  was:
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

An example of these extension functions:
{code:sql}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
WHERE {
  ?x eg:workload ?o
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}


In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
perform such integration tasks - and for instance one could already start a 
Fuseki  in order to play around with conversions in a Web interface.



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions should look like.
* Maybe the functionality of running files containing sequences of SPARQL 
queries could also be added to Jena directly - as I think there is no 

[jira] [Updated] (JENA-1502) SPARQL extensions for processing CSV, XML and JSON

[Claus Stadler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Stadler updated JENA-1502:

Description: 
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

An example of these extension functions:
{code:sql}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
WHERE {
  ?x eg:workload ?o
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}


In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
perform such integration tasks - and for instance one could already start a 
Fuseki  in order to play around with conversions in a Web interface.



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions should look like.
* Maybe the functionality of running files containing sequences of SPARQL 
queries could also be added to Jena directly - as I think there is no magic 
outside the scope of Jena to it.


  was:
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

An example of these extension functions:
{code:sql}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
WHERE {
  ?x eg:workload ?o
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}


In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
perform such integration tasks - and for instance one could already start a 
Fuseki  in order to play around with conversions in a Web interface.



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions.
* Maybe the functionality of running files containing sequences of SPARQL 
queries could also be added to Jena directly - as I think there is no magic 
outside the scope of Jena to it.



> SPARQL extensions for processing CSV, XML and JSON
> 

[jira] [Updated] (JENA-1502) SPARQL extensions for processing CSV, XML and JSON

[Claus Stadler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Stadler updated JENA-1502:

Description: 
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

An example of these extension functions:
{code:sql}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
WHERE {
  ?x eg:workload ?o
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}


In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
perform such integration tasks - and for instance one could already start a 
Fuseki  in order to play around with conversions in a Web interface.



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions.
* Maybe the functionality of running files containing sequences of SPARQL 
queries could also be added to Jena directly - as I think there is no magic 
outside the scope of Jena to it.


  was:
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

An example of these extension functions:
{code:sparql}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
#SELECT ?s ?i ?l
WHERE {
  ?x eg:workload ?o
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}


In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
perform such integration tasks - and for instance one could already start a 
Fuseki  in order to play around with conversions in a Web interface.



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions.
* Maybe the functionality of running files containing sequences of SPARQL 
queries could also be added to Jena directly - as I think there is no magic 
outside the scope of Jena to it.



> SPARQL extensions for processing CSV, XML and JSON
> 

[jira] [Updated] (JENA-1502) SPARQL extensions for processing CSV, XML and JSON

[Claus Stadler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Stadler updated JENA-1502:

Description: 
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

An example of these extension functions:
{code:sparql}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
#SELECT ?s ?i ?l
WHERE {
  ?x eg:workload ?o
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}


In fact, these SPARQL ARQ extensions would enable any Jena-based project to 
perform such integration tasks - and for instance one could already start a 
Fuseki  in order to play around with conversions in a Web interface.



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions.
* Maybe the functionality of running files containing sequences of SPARQL 
queries could also be added to Jena directly - as I think there is no magic 
outside the scope of Jena to it.


  was:
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

In fact, we could also start a Fuseki with these ARQ SPARQL extensions which 
enables easily playing around with conversions in a Web interface.

An example of these extension functions:
{code:java}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
#SELECT ?s ?i ?l
WHERE {
  ?x eg:workload ?o
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions.
* Maybe the functionality of running files containing sequences of SPARQL 
queries could also be added to Jena directly - as I think there is no magic 
outside the scope of Jena to it.



> SPARQL extensions for processing CSV, XML and JSON
> --
>
> Key: JENA-1502
> 

[jira] [Updated] (JENA-1502) SPARQL extensions for processing CSV, XML and JSON

[Claus Stadler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Stadler updated JENA-1502:

Description: 
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

In fact, we could also start a Fuseki with these ARQ SPARQL extensions which 
enables easily playing around with conversions in a Web interface.

An example of these extension functions:
{code:java}
# Add labels of train / bus stops
INSERT {
  GRAPH eg:result { ?s rdfs:label ?l }
}
#SELECT ?s ?i ?l
WHERE {
  ?x eg:workload ?o
  BIND(json:path(?o, "$.stopNames") AS ?stopNames)
  ?stopNames json:unnest (?l ?i) .

  GRAPH ?x { ?s eg:stopId ?i }
}
{code}



* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions.
* Maybe the functionality of running files containing sequences of SPARQL 
queries could also be added to Jena directly - as I think there is no magic 
outside the scope of Jena to it.


  was:
Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

In fact, we could also start a Fuseki with these ARQ SPARQL extensions which 
enables easily playing around with conversions in a Web interface.

* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions.
* Maybe the functionality of running files containing sequences of SPARQL 
queries could also be added to Jena directly - as I think there is no magic 
outside the scope of Jena to it.



> SPARQL extensions for processing CSV, XML and JSON
> --
>
> Key: JENA-1502
> URL: https://issues.apache.org/jira/browse/JENA-1502
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Claus Stadler
>Priority: Major
>
> Many systems have been built so far for transforming heterogeneous data - 
> most prominently CSV, XML and JSON) to RDF.
> As it turns 

[jira] [Created] (JENA-1502) SPARQL extensions for processing CSV, XML and JSON

[Claus Stadler (JIRA)]

Claus Stadler created JENA-1502:
---

 Summary: SPARQL extensions for processing CSV, XML and JSON
 Key: JENA-1502
 URL: https://issues.apache.org/jira/browse/JENA-1502
 Project: Apache Jena
  Issue Type: Improvement
  Components: ARQ
Affects Versions: Jena 3.6.0
Reporter: Claus Stadler


Many systems have been built so far for transforming heterogeneous data - most 
prominently CSV, XML and JSON) to RDF.
As it turns out, with a few extensions to ARQ, Jena becomes (at least for me) 
an extremely convenient tool for this task.

To clarify our point, for a project we have to convert several (open) datasets, 
and we came up with a solution where we just have to execute a sequence of 
SPARQL queries making use of our ARQ extensions.

In [this 
repository|https://github.com/QROWD/QROWD-RDF-Data-Integration/tree/master/datasets/1046-1051]
 there are sub folders with JSON datasets, and the conversion is just a matter 
of running the SPARQL queries in the files 
[workloads.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/workloads.sparql]
 (which adds triples describing workloads into a jena in-memory dataset) and 
[process.sparql|https://github.com/QROWD/QROWD-RDF-Data-Integration/blob/master/datasets/1046-1051/process.sparql]
 (which processes all workloads in that dataset and inserts triples into a 
(named) result graph). We created a [thin command line 
wrapper|https://github.com/SmartDataAnalytics/Sparqlintegrate] to conveniently 
run these conversions.

In fact, we could also start a Fuseki with these ARQ SPARQL extensions which 
enables easily playing around with conversions in a Web interface.

* Is there interest to integrate our ARQ [SPARQL extension 
functions|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-sparql-ext]
 into Jena? If so, what would we have to do and where (which existing or new 
jena module) would be the most appropriate place?
We are also open to discussion and changes on what exactly the signatures of 
these extension functions.
* Maybe the functionality of running files containing sequences of SPARQL 
queries could also be added to Jena directly - as I think there is no magic 
outside the scope of Jena to it.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1501) Add systemd unit file for Fuseki

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16392569#comment-16392569
 ] 

ASF GitHub Bot commented on JENA-1501:
--

Github user osma commented on the issue:

https://github.com/apache/jena/pull/375
  
Thank you for your comments @ajs6f and @jneubert ! I made the changes you 
suggested.

I will merge this early next week unless there are further suggestions or 
objections.


> 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 issue #375: JENA-1501: add systemd unit file for Fuseki

[osma]

Github user osma commented on the issue:

https://github.com/apache/jena/pull/375
  
Thank you for your comments @ajs6f and @jneubert ! I made the changes you 
suggested.

I will merge this early next week unless there are further suggestions or 
objections.


---