date:20171107

[jira] [Commented] (JENA-1391) Add Convenience Methods to Dataset

2017-11-07 Thread A. Soroka (JIRA)


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

A. Soroka commented on JENA-1391:
-

[~jaco0646] would you like to start a discussion about immutability on the dev@ 
list?

> Add Convenience Methods to Dataset
> --
>
> Key: JENA-1391
> URL: https://issues.apache.org/jira/browse/JENA-1391
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Adam Jacobs
>Assignee: A. Soroka
>Priority: Trivial
>
> The Dataset interface could provide several convenience methods similar to 
> the Model interface, allowing usability of RDF quads on par with RDF triples. 
> Specific examples include,
> # add(Dataset)
> # remove(Dataset)
> # union(Dataset)
> # intersection(Dataset)
> # difference(Dataset)
> # isEmpty()
> Following is a possible implementation of these methods.
> {code:java}
> default Dataset add(Dataset d) {
> this.getDefaultModel().add(d.getDefaultModel());
> d.listNames().forEachRemaining(name -> 
> this.getNamedModel(name).add(d.getNamedModel(name)));
> return this;
> }
> default Dataset remove(Dataset d) {
> this.getDefaultModel().remove(d.getDefaultModel());
> d.listNames().forEachRemaining(name -> 
> this.getNamedModel(name).remove(d.getNamedModel(name)));
> return this;
> }
> default Dataset union(Dataset d) {
> return DatasetFactory.create().add(this).add(d);
> }
> default Dataset difference(Dataset d) {
> Dataset output = DatasetFactory.create();
> 
> output.setDefaultModel(this.getDefaultModel().difference(d.getDefaultModel()));
> this.listNames().forEachRemaining(name -> {
> Model difference = 
> this.getNamedModel(name).difference(d.getNamedModel(name));
> if (!difference.isEmpty()) output.addNamedModel(name, difference);
> });
> return output;
> }
> default Dataset intersection(Dataset d) {
> Dataset output = DatasetFactory.create();
> 
> output.setDefaultModel(this.getDefaultModel().intersection(d.getDefaultModel()));
> Set names = this.names();
> names.retainAll(d.names());
> names.forEach(name -> {
> Model intersection = 
> this.getNamedModel(name).intersection(d.getNamedModel(name));
> if (!intersection.isEmpty()) output.addNamedModel(name, 
> intersection);
> });
> return output;
> }
> default Set names() {
> Set names = new HashSet<>();
> this.listNames().forEachRemaining(names::add);
> return names;
> }
> default boolean isEmpty() {
> return this.asDatasetGraph().isEmpty();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena issue #299: Turtle Star

2017-11-07 Thread afs

Github user afs commented on the issue:

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

Sorry for the delay getting round to this - Jena had a release which
takes time. It would be interesting to see some support for RDF*.

Comments in two areas : the parser and about RDF*.

**Turtle parser**

The Turtle parser in jena-core only exists for legacy and support some
tests. It isn't the normal Turtle parser, and isn't spec compliant.

Parsing happens in RIOT org.apache.jena.riot.lang.LangTurtle. It is a
custom (hand written parser) with its own tokenizer for speed.

If you are interested, we can add the tokens for RDF*, it takes some care
because this is the same tokenizer as used for N-Triples and so
speed-critical. We may need o split of an N-Triples/N-quads tokenizer
but that wouldn't be such a bad thing anyway.

There is an example of plumbing in a new language in
[EXRIOT5.java](https://github.com/apache/jena/blob/master/jena-arq/src-examples/arq/examples/riot/ExRIOT_5.java).

**RDF\* and RDF**

RDF* has the notion of a triple id: each triple has a unique id which makes
it different to reification. An RDF* grah can be written in RDF and the result
and back in again by using exactly one for a
triple and the process can be reversed. This equates to the triple id of
RDF* with information in the
strict RDF graph. It's not a general RDF graph.

It is not possible to RDF-merge to such graphs - that would end up with two
bnode-reificiations and statements in one graph about the triple will not
RDF*-merge with the statements in the other graph (which is the whole point of
RDF reification).

Merging needs to respect the additional RDF* data model.
Example:
```
<< :s :p :o >> :addedBy "Alice" .
<< :s :p :o >> :addedBy "Bob" .
```
My understanding of RDF* is that this is one triple `td = :s :p :o` with two
triples with the same subject. `td :addedBy "Alice" . td :addedBy "Bob" .`.

**SPARQL**

The `<< >>` syntax has a long history - it was first used in early SPARQL
discussions but never made it to the final stages. It may only existed on the
mailing list; teh WG decided not to have reification syntax. However, there
are some remains in the SPARQL grammar in ARQ.

---

[jira] [Closed] (JENA-1421) Fuseki UI data upload fails

2017-11-07 Thread Andy Seaborne (JIRA)


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

Andy Seaborne closed JENA-1421.
---

> Fuseki UI data upload fails
> ---
>
> Key: JENA-1421
> URL: https://issues.apache.org/jira/browse/JENA-1421
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.5.0
>Reporter: Chris Tomlinson
> Fix For: Jena 3.6.0
>
>
> From [email 2017-11-07 on 
> users@jena|https://lists.apache.org/thread.html/bc682c91a6f340b051cd7eb3bae79bedd85f10c0cc0a476aa810dd93@%3Cusers.jena.apache.org%3E].
> Error in Fuseki 3.5.0: the “upload files” tab:
> {noformat}
> Result: failed with message "SyntaxError: JSON Parse error: Unrecognized 
> token '<‘"
> {noformat}
> It works fine in Fuseki 3.4.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JENA-1420) Fuseki 3.5.0 "upload files" fails

2017-11-07 Thread Andy Seaborne (JIRA)


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

Andy Seaborne updated JENA-1420:

Description: 
>From [email 2017-11-07 on 
>users@jena|https://lists.apache.org/thread.html/bc682c91a6f340b051cd7eb3bae79bedd85f10c0cc0a476aa810dd93@%3Cusers.jena.apache.org%3E].

I'm seeing the following error in fuseki 3.5.0 when I use the “upload files” 
tab:
{noformat}
Result: failed with message "SyntaxError: JSON Parse error: Unrecognized token 
'<‘"
{noformat}
I’ve tried ttl, jsonld and rdf/xml versions of the same set of triples:
{noformat}
@prefix ex:  .
@prefix skos:  .

ex:SomeOne
  a   ex:Item ;
  skos:prefLabel "abc def ghi”@en ;
  skos:altLabel "jkl mno pqr”@en ;
  .
{noformat}
It works fine in fuseki 3.4.0.

  was:
I'm seeing the following error in fuseki 3.5.0 when I use the “upload files” 
tab:
{noformat}
Result: failed with message "SyntaxError: JSON Parse error: Unrecognized token 
'<‘"
{noformat}
I’ve tried ttl, jsonld and rdf/xml versions of the same set of triples:
{noformat}
@prefix ex:  .
@prefix skos:  .

ex:SomeOne
  a   ex:Item ;
  skos:prefLabel "abc def ghi”@en ;
  skos:altLabel "jkl mno pqr”@en ;
  .
{noformat}
It works fine in fuseki 3.4.0.


> Fuseki 3.5.0 "upload files" fails
> -
>
> Key: JENA-1420
> URL: https://issues.apache.org/jira/browse/JENA-1420
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.5.0
> Environment: Debian/stretch64 and MacOSX 10.12. Oracle JDK 1.8.0_131
>Reporter: Code Ferret
>Assignee: Andy Seaborne
> Fix For: Jena 3.6.0
>
>
> From [email 2017-11-07 on 
> users@jena|https://lists.apache.org/thread.html/bc682c91a6f340b051cd7eb3bae79bedd85f10c0cc0a476aa810dd93@%3Cusers.jena.apache.org%3E].
> I'm seeing the following error in fuseki 3.5.0 when I use the “upload files” 
> tab:
> {noformat}
> Result: failed with message "SyntaxError: JSON Parse error: Unrecognized 
> token '<‘"
> {noformat}
> I’ve tried ttl, jsonld and rdf/xml versions of the same set of triples:
> {noformat}
> @prefix ex:  .
> @prefix skos:  .
> ex:SomeOne
>   a   ex:Item ;
>   skos:prefLabel "abc def ghi”@en ;
>   skos:altLabel "jkl mno pqr”@en ;
>   .
> {noformat}
> It works fine in fuseki 3.4.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JENA-1420) Fuseki 3.5.0 "upload files" fails

2017-11-07 Thread Andy Seaborne (JIRA)


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

Andy Seaborne updated JENA-1420:

Fix Version/s: Jena 3.6.0

> Fuseki 3.5.0 "upload files" fails
> -
>
> Key: JENA-1420
> URL: https://issues.apache.org/jira/browse/JENA-1420
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.5.0
> Environment: Debian/stretch64 and MacOSX 10.12. Oracle JDK 1.8.0_131
>Reporter: Code Ferret
>Assignee: Andy Seaborne
> Fix For: Jena 3.6.0
>
>
> From [email 2017-11-07 on 
> users@jena|https://lists.apache.org/thread.html/bc682c91a6f340b051cd7eb3bae79bedd85f10c0cc0a476aa810dd93@%3Cusers.jena.apache.org%3E].
> I'm seeing the following error in fuseki 3.5.0 when I use the “upload files” 
> tab:
> {noformat}
> Result: failed with message "SyntaxError: JSON Parse error: Unrecognized 
> token '<‘"
> {noformat}
> I’ve tried ttl, jsonld and rdf/xml versions of the same set of triples:
> {noformat}
> @prefix ex:  .
> @prefix skos:  .
> ex:SomeOne
>   a   ex:Item ;
>   skos:prefLabel "abc def ghi”@en ;
>   skos:altLabel "jkl mno pqr”@en ;
>   .
> {noformat}
> It works fine in fuseki 3.4.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JENA-1420) Fuseki 3.5.0 "upload files" fails

2017-11-07 Thread Andy Seaborne (JIRA)


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

Andy Seaborne updated JENA-1420:

Priority: Major  (was: Minor)

> Fuseki 3.5.0 "upload files" fails
> -
>
> Key: JENA-1420
> URL: https://issues.apache.org/jira/browse/JENA-1420
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.5.0
> Environment: Debian/stretch64 and MacOSX 10.12. Oracle JDK 1.8.0_131
>Reporter: Code Ferret
>Assignee: Andy Seaborne
>
> I'm seeing the following error in fuseki 3.5.0 when I use the “upload files” 
> tab:
> {noformat}
> Result: failed with message "SyntaxError: JSON Parse error: Unrecognized 
> token '<‘"
> {noformat}
> I’ve tried ttl, jsonld and rdf/xml versions of the same set of triples:
> {noformat}
> @prefix ex:  .
> @prefix skos:  .
> ex:SomeOne
>   a   ex:Item ;
>   skos:prefLabel "abc def ghi”@en ;
>   skos:altLabel "jkl mno pqr”@en ;
>   .
> {noformat}
> It works fine in fuseki 3.4.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JENA-1421) Fuseki UI data upload fails

2017-11-07 Thread Andy Seaborne (JIRA)


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

Andy Seaborne resolved JENA-1421.
-
Resolution: Duplicate
  Assignee: (was: Andy Seaborne)

Duplicates JENA-1420

> Fuseki UI data upload fails
> ---
>
> Key: JENA-1421
> URL: https://issues.apache.org/jira/browse/JENA-1421
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.5.0
>Reporter: Chris Tomlinson
> Fix For: Jena 3.6.0
>
>
> From [email 2017-11-07 on 
> users@jena|https://lists.apache.org/thread.html/bc682c91a6f340b051cd7eb3bae79bedd85f10c0cc0a476aa810dd93@%3Cusers.jena.apache.org%3E].
> Error in Fuseki 3.5.0: the “upload files” tab:
> {noformat}
> Result: failed with message "SyntaxError: JSON Parse error: Unrecognized 
> token '<‘"
> {noformat}
> It works fine in Fuseki 3.4.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (JENA-1404) Put all CSV2RDF handling in jena-csv

2017-11-07 Thread Andy Seaborne (JIRA)


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

Andy Seaborne updated JENA-1404:

Comment: was deleted

(was: GitHub user afs opened a pull request:

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

Fuseki fixes

Fixes for both JENA-1404 and JENA-1420.

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

$ git pull https://github.com/afs/jena fuseki-fixes

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

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


commit b250eee794c502eb96a417d0bd12ec1734dd2f93
Author: Andy Seaborne 
Date:   2017-11-07T15:28:20Z

JENA-1410 : Delete database configuration files.

commit 76f0408f37e774317bb2dc7955c435f837bba05e
Author: Andy Seaborne 
Date:   2017-11-07T18:28:16Z

JENA-1420: OperationName fix. The "name" must be  a simple name.


)

> Put all CSV2RDF handling in jena-csv
> 
>
> Key: JENA-1404
> URL: https://issues.apache.org/jira/browse/JENA-1404
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.5.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.6.0
>
>
> Move any remaining for the old CSV2RDF code out of RIOT in jena-csv.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JENA-1404) Put all CSV2RDF handling in jena-csv

2017-11-07 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on JENA-1404:
--

GitHub user afs opened a pull request:

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

Fuseki fixes

Fixes for both JENA-1404 and JENA-1420.

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

$ git pull https://github.com/afs/jena fuseki-fixes

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

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


commit b250eee794c502eb96a417d0bd12ec1734dd2f93
Author: Andy Seaborne 
Date:   2017-11-07T15:28:20Z

JENA-1410 : Delete database configuration files.

commit 76f0408f37e774317bb2dc7955c435f837bba05e
Author: Andy Seaborne 
Date:   2017-11-07T18:28:16Z

JENA-1420: OperationName fix. The "name" must be  a simple name.




> Put all CSV2RDF handling in jena-csv
> 
>
> Key: JENA-1404
> URL: https://issues.apache.org/jira/browse/JENA-1404
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.5.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.6.0
>
>
> Move any remaining for the old CSV2RDF code out of RIOT in jena-csv.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena pull request #305: Fuseki fixes

2017-11-07 Thread afs

GitHub user afs opened a pull request:

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

Fuseki fixes

Fixes for both JENA-1404 and JENA-1420.

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

$ git pull https://github.com/afs/jena fuseki-fixes

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

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


commit b250eee794c502eb96a417d0bd12ec1734dd2f93
Author: Andy Seaborne 
Date:   2017-11-07T15:28:20Z

JENA-1410 : Delete database configuration files.

commit 76f0408f37e774317bb2dc7955c435f837bba05e
Author: Andy Seaborne 
Date:   2017-11-07T18:28:16Z

JENA-1420: OperationName fix. The "name" must be  a simple name.




---

[jira] [Assigned] (JENA-1420) Fuseki 3.5.0 "upload files" fails

2017-11-07 Thread Andy Seaborne (JIRA)


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

Andy Seaborne reassigned JENA-1420:
---

Assignee: Andy Seaborne

> Fuseki 3.5.0 "upload files" fails
> -
>
> Key: JENA-1420
> URL: https://issues.apache.org/jira/browse/JENA-1420
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.5.0
> Environment: Debian/stretch64 and MacOSX 10.12. Oracle JDK 1.8.0_131
>Reporter: Code Ferret
>Assignee: Andy Seaborne
>Priority: Minor
>
> I'm seeing the following error in fuseki 3.5.0 when I use the “upload files” 
> tab:
> {noformat}
> Result: failed with message "SyntaxError: JSON Parse error: Unrecognized 
> token '<‘"
> {noformat}
> I’ve tried ttl, jsonld and rdf/xml versions of the same set of triples:
> {noformat}
> @prefix ex:  .
> @prefix skos:  .
> ex:SomeOne
>   a   ex:Item ;
>   skos:prefLabel "abc def ghi”@en ;
>   skos:altLabel "jkl mno pqr”@en ;
>   .
> {noformat}
> It works fine in fuseki 3.4.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JENA-1420) Fuseki 3.5.0 "upload files" fails

2017-11-07 Thread Andy Seaborne (JIRA)


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

Andy Seaborne commented on JENA-1420:
-

Introduced in commit fc7beb02c3.


> Fuseki 3.5.0 "upload files" fails
> -
>
> Key: JENA-1420
> URL: https://issues.apache.org/jira/browse/JENA-1420
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.5.0
> Environment: Debian/stretch64 and MacOSX 10.12. Oracle JDK 1.8.0_131
>Reporter: Code Ferret
>Priority: Minor
>
> I'm seeing the following error in fuseki 3.5.0 when I use the “upload files” 
> tab:
> {noformat}
> Result: failed with message "SyntaxError: JSON Parse error: Unrecognized 
> token '<‘"
> {noformat}
> I’ve tried ttl, jsonld and rdf/xml versions of the same set of triples:
> {noformat}
> @prefix ex:  .
> @prefix skos:  .
> ex:SomeOne
>   a   ex:Item ;
>   skos:prefLabel "abc def ghi”@en ;
>   skos:altLabel "jkl mno pqr”@en ;
>   .
> {noformat}
> It works fine in fuseki 3.4.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JENA-1421) Fuseki UI data upload fails

2017-11-07 Thread Andy Seaborne (JIRA)

Andy Seaborne created JENA-1421:
---

 Summary: Fuseki UI data upload fails
 Key: JENA-1421
 URL: https://issues.apache.org/jira/browse/JENA-1421
 Project: Apache Jena
  Issue Type: Bug
Affects Versions: Jena 3.5.0
Reporter: Chris Tomlinson
Assignee: Andy Seaborne
 Fix For: Jena 3.6.0


>From [email 2017-11-07 on 
>users@jena|https://lists.apache.org/thread.html/bc682c91a6f340b051cd7eb3bae79bedd85f10c0cc0a476aa810dd93@%3Cusers.jena.apache.org%3E].

Error in Fuseki 3.5.0: the “upload files” tab:

{noformat}
Result: failed with message "SyntaxError: JSON Parse error: Unrecognized 
token '<‘"
{noformat}

It works fine in Fuseki 3.4.0.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

2017-11-07 Thread Greg Albiston (JIRA)


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

Greg Albiston edited comment on JENA-1402 at 11/7/17 3:51 PM:
--

The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_, 
_xsd:time_ and _xsd:dateTime_.

I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and 
parsed into Jena XSD Typed Literals. I haven't found any problems with 
_java.time.Duration_.

The only issue I've found with _java.time.LocalTime_ is that 
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"), 
when Jena expects them to be preserved. I don't know which is the correct 
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement 
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1 
Part 2: 
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce 
the format.

{code:java}
public static final DateTimeFormatter TIME_FORMATTER = 
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

public static final Literal createLocalTime(LocalTime localTime) {
return 
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), 
XSDBaseNumericType.XSDtime);
}
{code}

Usage of the _java.time.Duration_ would suggest replacing 
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An 
issue here is that _ java.time_ distinguishes between dateTime and time with 
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those 
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD 
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid 
_xsd:time_ literals that throw exceptions if parsed through the wrong 
_java.time_ object.

Thanks,

Greg




was (Author: gregalbiston):
The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_, 
_xsd:time_ and _xsd:dateTime_.

I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and 
parsed into Jena XSD Typed Literals. I haven't found any problems with 
_java.time.Duration_.

The only issue I've found with _java.time.LocalTime_ is that 
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"), 
when Jena expects them to be preserved. I don't know which is the correct 
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement 
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1 
Part 2: 
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce 
the format.

{code:java}
public static final DateTimeFormatter TIME_FORMATTER = 
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

public static final Literal createLocalTime(LocalTime localTime) {
return 
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), 
XSDBaseNumericType.XSDtime);
}
{code}

Usage of the _java.time.Duration_ would suggest replacing 
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An 
issue here is that_ java.time_ distinguishes between dateTime and time with 
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those 
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD 
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid 
_xsd:time_ literals that throw exceptions if parsed through the wrong 
_java.time_ object.

Thanks,

Greg



> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^ 
>

[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

2017-11-07 Thread Greg Albiston (JIRA)


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

Greg Albiston edited comment on JENA-1402 at 11/7/17 3:51 PM:
--

The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_, 
_xsd:time_ and _xsd:dateTime_.

I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and 
parsed into Jena XSD Typed Literals. I haven't found any problems with 
_java.time.Duration_.

The only issue I've found with _java.time.LocalTime_ is that 
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"), 
when Jena expects them to be preserved. I don't know which is the correct 
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement 
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1 
Part 2: 
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce 
the format.

{code:java}
public static final DateTimeFormatter TIME_FORMATTER = 
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

public static final Literal createLocalTime(LocalTime localTime) {
return 
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), 
XSDBaseNumericType.XSDtime);
}
{code}

Usage of the _java.time.Duration_ would suggest replacing 
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An 
issue here is that _java.time_ distinguishes between dateTime and time with 
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those 
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD 
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid 
_xsd:time_ literals that throw exceptions if parsed through the wrong 
_java.time_ object.

Thanks,

Greg




was (Author: gregalbiston):
The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_, 
_xsd:time_ and _xsd:dateTime_.

I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and 
parsed into Jena XSD Typed Literals. I haven't found any problems with 
_java.time.Duration_.

The only issue I've found with _java.time.LocalTime_ is that 
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"), 
when Jena expects them to be preserved. I don't know which is the correct 
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement 
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1 
Part 2: 
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce 
the format.

{code:java}
public static final DateTimeFormatter TIME_FORMATTER = 
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

public static final Literal createLocalTime(LocalTime localTime) {
return 
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), 
XSDBaseNumericType.XSDtime);
}
{code}

Usage of the _java.time.Duration_ would suggest replacing 
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An 
issue here is that _ java.time_ distinguishes between dateTime and time with 
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those 
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD 
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid 
_xsd:time_ literals that throw exceptions if parsed through the wrong 
_java.time_ object.

Thanks,

Greg



> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^ 
>

[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

2017-11-07 Thread Greg Albiston (JIRA)


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

Greg Albiston edited comment on JENA-1402 at 11/7/17 3:49 PM:
--

The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_, 
_xsd:time_ and _xsd:dateTime_.

I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and 
parsed into Jena XSD Typed Literals. I haven't found any problems with 
_java.time.Duration_.

The only issue I've found with _java.time.LocalTime_ is that 
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"), 
when Jena expects them to be preserved. I don't know which is the correct 
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement 
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1 
Part 2: 
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce 
the format.

{code:java}
public static final DateTimeFormatter TIME_FORMATTER = 
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

public static final Literal createLocalTime(LocalTime localTime) {
return 
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), 
XSDBaseNumericType.XSDtime);
}
{code}

Usage of the _java.time.Duration_ would suggest replacing 
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An 
issue here is that_ java.time_ distinguishes between dateTime and time with 
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those 
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD 
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid 
_xsd:time_ literals that throw exceptions if parsed through the wrong 
_java.time_ object.

Thanks,

Greg




was (Author: gregalbiston):
The {noformat}java.time{noformat} API is supposed to be ISO-8601 compliant as 
are {noformat}xsd:duration{noformat}, {noformat}xsd:time{noformat} and 
{noformat}xsd:dateTime{noformat}.

I've used {noformat}java.time.Duration{noformat} and 
{noformat}java.time.LocalTime{noformat} in a project and parsed into Jena XSD 
Typed Literals. I haven't found any problems with 
{noformat}java.time.Duration{noformat}.

The only issue I've found with {noformat}java.time.LocalTime{noformat} is that 
{noformat}LocalTime.toString(){noformat} drops zero seconds (i.e. "09:00:00" 
becomes "09:00"), when Jena expects them to be preserved. I don't know which is 
the correct behaviour for ISO-8601 but the latter seems to be a 
{noformat}xsd:time{noformat} requirement (based on 3rd bullet point in 
[https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a 
{noformat}java.time.format.DateTimeFormatter{noformat} to enforce the format.

{code:java}
public static final DateTimeFormatter TIME_FORMATTER = 
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

public static final Literal createLocalTime(LocalTime localTime) {
return 
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), 
XSDBaseNumericType.XSDtime);
}
{code}

Usage of the {noformat}java.time.Duration{noformat} would suggest replacing 
{noformat}javax.xml.datatype.XMLGregorianCalendar{noformat} and 
{noformat}java.util.Calendar{noformat} in Jena. An issue here is that 
{noformat}java.time{noformat} distinguishes between dateTime and time with 
timezone ({noformat}java.time.OffsetDateTime{noformat} and 
{noformat}java.time.OffsetTime{noformat}) from those without timezones 
({noformat}java.time.LocalDateTime{noformat} and 
{noformat}java.time.LocalTime{noformat}). XSD does not distinguish and so 
"09:00:00" and "09:00:00+00:00" are both valid {noformat}xsd:time{noformat} 
literals that throw exceptions if parsed through the wrong 
{noformat}java.time{noformat} object.

Thanks,

Greg



> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes:

[jira] [Created] (JENA-1420) Fuseki 3.5.0 "upload files" fails

2017-11-07 Thread Code Ferret (JIRA)

Code Ferret created JENA-1420:
-

 Summary: Fuseki 3.5.0 "upload files" fails
 Key: JENA-1420
 URL: https://issues.apache.org/jira/browse/JENA-1420
 Project: Apache Jena
  Issue Type: Bug
  Components: Fuseki
Affects Versions: Jena 3.5.0
 Environment: Debian/stretch64 and MacOSX 10.12. Oracle JDK 1.8.0_131
Reporter: Code Ferret
Priority: Minor


I'm seeing the following error in fuseki 3.5.0 when I use the “upload files” 
tab:
{noformat}
Result: failed with message "SyntaxError: JSON Parse error: Unrecognized token 
'<‘"
{noformat}
I’ve tried ttl, jsonld and rdf/xml versions of the same set of triples:
{noformat}
@prefix ex:  .
@prefix skos:  .

ex:SomeOne
  a   ex:Item ;
  skos:prefLabel "abc def ghi”@en ;
  skos:altLabel "jkl mno pqr”@en ;
  .
{noformat}
It works fine in fuseki 3.4.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

2017-11-07 Thread Andy Seaborne (JIRA)


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

Andy Seaborne commented on JENA-1402:
-

Greg - thanks for tracking this.  Ideally, it will be fixed in the JDK but we 
have a way forward now.

>From looking at {{java.time.Duration}} I think (small experiment) Jena could 
>switch to using it instead of the XML one. Either as a complete replacement of 
>the value of a duration or holding it as an additional value item. The 
>question will be is {{java.time.Duration}} exactly {{xsd:duration}} or whether 
>there are some minor differences.



> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^ 
> "PT1M10S"^^)
> ("PT2M3.123S"^^ 
> "PT1M1.123S"^^)
> ("PT0M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT2M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT1H4M3.123S"^^ 
> "PT0M10.123S"^^)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

2017-11-07 Thread Greg Albiston (JIRA)


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

Greg Albiston commented on JENA-1402:
-

The bug in javax.xml.datatype.Duration has been reported to Oracle as Bug ID: 
JDK-8190835 [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8190835].

It has been assigned a priority of P4, so is apparently an optional fix for the 
next release.

Thanks,

Greg

> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^ 
> "PT1M10S"^^)
> ("PT2M3.123S"^^ 
> "PT1M1.123S"^^)
> ("PT0M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT2M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT1H4M3.123S"^^ 
> "PT0M10.123S"^^)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JENA-1391) Add Convenience Methods to Dataset

[GitHub] jena issue #299: Turtle Star

[jira] [Closed] (JENA-1421) Fuseki UI data upload fails

[jira] [Updated] (JENA-1420) Fuseki 3.5.0 "upload files" fails

[jira] [Updated] (JENA-1420) Fuseki 3.5.0 "upload files" fails

[jira] [Updated] (JENA-1420) Fuseki 3.5.0 "upload files" fails

[jira] [Resolved] (JENA-1421) Fuseki UI data upload fails

[jira] [Issue Comment Deleted] (JENA-1404) Put all CSV2RDF handling in jena-csv

[jira] [Commented] (JENA-1404) Put all CSV2RDF handling in jena-csv

[GitHub] jena pull request #305: Fuseki fixes

[jira] [Assigned] (JENA-1420) Fuseki 3.5.0 "upload files" fails

[jira] [Commented] (JENA-1420) Fuseki 3.5.0 "upload files" fails

[jira] [Created] (JENA-1421) Fuseki UI data upload fails

[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[jira] [Created] (JENA-1420) Fuseki 3.5.0 "upload files" fails

[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

19 matches

Site Navigation

Mail list logo

Footer information