Re: Discuss: write PREFIX not @prefix?

2019-09-20 Thread ajs6f
Ditto, but I'd be interested in hearing why you suggested it, Andy. IOW are 
there some benefits that aren't obvious?

ajs6f

> On Sep 20, 2019, at 7:17 AM, Claude Warren  wrote:
> 
> For me this falls under "if it ain't broke don't fix it"
> so
> -1
> 
> 
> On Fri, Sep 20, 2019 at 11:47 AM Andy Seaborne  wrote:
> 
>> The Turtle and TriG writers output "@prefix".
>> 
>> RDF 1.1 allows PREFIX.
>> 
>> Should we change the writers to output PREFIX? (after the next release)
>> 
>> (we can add options but majority of users don't set options and exisintg
>> code doesn't)
>> 
>> Andy
>> 
> 
> 
> -- 
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren



[jira] [Updated] (JENA-1729) A minor initilization issue

2019-09-20 Thread Andy Seaborne (Jira)


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

Andy Seaborne updated JENA-1729:

Fix Version/s: (was: Jena 3.12.0)

> A minor initilization issue
> ---
>
> Key: JENA-1729
> URL: https://issues.apache.org/jira/browse/JENA-1729
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Core
> Environment: java8(1.8.0_152), jena-arq:3.12.0
>Reporter: ssz
>Priority: Minor
>
> The following one-class program fails with assertion error:
>  
> {code:java}
> package xx.yy;
> import org.apache.jena.rdf.model.RDFNode;
> import org.apache.jena.rdf.model.ResourceFactory;
> import org.apache.jena.sys.JenaSubsystemLifecycle;
> import org.apache.jena.sys.JenaSystem;
> import org.apache.jena.vocabulary.RDF;
> public class InitTest implements JenaSubsystemLifecycle {
> @Override
> public void start() {
> if (JenaSystem.DEBUG_INIT)
> System.err.println("InitTEST -- start");
> assert RDF.type != null : "RDF#type is null => attempt to load a 
> graph here will fail";
> }
> @Override
> public void stop() {
> if (JenaSystem.DEBUG_INIT)
> System.err.println("InitTEST -- finish");
> }
> @Override
> public int level() {
> return 500;
> }
> public static void main(String... args) { // run VM option: -ea
> JenaSystem.DEBUG_INIT = true;
> //RDFNode r = ResourceFactory.createProperty("X"); // this works fine
> RDFNode r = ResourceFactory.createTypedLiteral("Y"); // this causes a 
> problem
> System.out.println(r);
> }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: Towards Jena 3.13.0

2019-09-20 Thread Andy Seaborne




On 30/08/2019 11:34, Andy Seaborne wrote:
There are some things still in progress so it looks like mid/late 
September.


Getting ready to do the build in the next few days.

Pulls waiting:

PR#608 : JENA-1760: Retire jena-maven-tools
PR#607 : JENA-864: Switch off checking for normal forms NFC, NFKC

Status ??
JENA-1755: Improve documentation of Query Builders [WIP]

Claude - do you this in 3.13.0 (and work can refine it later if wanted) 
or wait for now. "WIP" suggests the latter.



== Major items

JENA-1733: A SHACL engine
JENA-1732: Lucene OR fields
JENA-1693: Add Aggregate Function MEDIAN and MODE (from Marco Neumann)
JENA-1731: Fuseki endpoint configuration improvements and refactoring
JENA-1695: DB storage refactoring
JENA-1718: Remove jena-spatial from the build


The code is still there and will included in the source-release.
I think we should leave the code as-is for this release and retire it 
afterwards but that isn't a strong opinion.



JENA-1717: Produce canonical xsd:decimal forms.

JENA-1756: Dependency updates.
jsonld-java :: 0.12.3 -> 0.12.5

Apache Commons Lang3 :: 3.4->3.9
Apache Commons CSV :: 1.5 -> 1.7
Apache HttpClient: 4.5.5 ->  4.5.10
Apache Commons Collections4 : 4.1 -> 4.4
Apache Commons Compress 1.18 -> 1.19 (JENA-1754 -- Brad Hards)
micrometer :: 1.1.3->1.2.1

jackson-databind :: 2.9.9 -> 2.9.9.3
  CVEs: JENA-1736, JENA-1738, JENA-1745


== PRs:
#585 : JENA-1735 : symlinks in apache-jena-fuseki/fuseki-server
   As in the discussion, I'd like to use the same way to deal with
   symlinks in scripts but getting the improvement in for the release,
   and refining as time permits is better process.


Above.


== JIRA

17 and another 5 with PRs.


33


https://s.apache.org/jena-3.13.0-jira

== Retirement

Suggestion for retirement, that is remove the code and put a README.md 
in the module root directory.



JENA-1760

   jena-maven-tools (not released since 3.6.0)


[GitHub] [jena] afs opened a new pull request #608: JENA-1760: Retire jena-maven-tools

2019-09-20 Thread GitBox
afs opened a new pull request #608: JENA-1760: Retire jena-maven-tools
URL: https://github.com/apache/jena/pull/608
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Created] (JENA-1760) Retire Apache Jena maven-tools module

2019-09-20 Thread Andy Seaborne (Jira)
Andy Seaborne created JENA-1760:
---

 Summary: Retire Apache Jena maven-tools module
 Key: JENA-1760
 URL: https://issues.apache.org/jira/browse/JENA-1760
 Project: Apache Jena
  Issue Type: Task
  Components: Maven Tools
Affects Versions: Jena 3.13.0
Reporter: Andy Seaborne
Assignee: Andy Seaborne






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [jena] afs opened a new pull request #607: JENA-864: Switch off checking for normal forms NFC, NFKC

2019-09-20 Thread GitBox
afs opened a new pull request #607: JENA-864: Switch off checking for normal 
forms NFC, NFKC
URL: https://github.com/apache/jena/pull/607
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Reopened] (JENA-864) Switch off NFC and NFCK checks on IRIs

2019-09-20 Thread Andy Seaborne (Jira)


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

Andy Seaborne reopened JENA-864:

  Assignee: Andy Seaborne

[users@ message 
|https://lists.apache.org/thread.html/803e95f310c806edf1d6f7173bff92453ee4bc5f727c3a1e304cfa54@%3Cusers.jena.apache.org%3E]

> Switch off NFC and NFCK checks on IRIs
> --
>
> Key: JENA-864
> URL: https://issues.apache.org/jira/browse/JENA-864
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
>
> {{org.apache.jena.riot.system.IRIResolver}} sets up the IRI factory used 
> throughout RIOT for IRI checking.
> NFC and NFCK are some warning checks.  They are both warnings, not errors 
> ("SHOULD"), of certain Unicode blocks where transcoding across systems errors 
> are possible so the standards discourage their use.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (JENA-1757) Deprecate GraphStatisticsHandler

2019-09-20 Thread ASF subversion and git services (Jira)


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

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

Commit 9c3415ab70ed19fe9a68b1e8b29f9d84384a1f22 in jena's branch 
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=9c3415a ]

JENA-1757: Remove tests for graph statistics handler


> Deprecate GraphStatisticsHandler
> 
>
> Key: JENA-1757
> URL: https://issues.apache.org/jira/browse/JENA-1757
> Project: Apache Jena
>  Issue Type: Task
>  Components: Core
>Affects Versions: Jena 3.12.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Graph statistics give the number of for "S P O" where S, P or O can be a 
> wildcard.
> This didn't quite work out for query optimization - the needs for 
> optimization are a little more complicated, needing information such as "if S 
> is going to fixed, estimate the number of "S P O" with out yet knowing what S 
> is fixed as, or it might be one of several values.
> The only significant implementation is \{{GraphMemStatisticsHandler}} for the 
> plain memory graphs. It does exploit the mem indexes to get the count, 
> compared to counting a "find" but the improvement appears to be small. 
> Proposal: deprecate {{GraphStatisticsHandler}}, retain the mem code "just in 
> case".
> This will clear the way for either removal or incompatible change in the 
> future.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (JENA-1757) Deprecate GraphStatisticsHandler

2019-09-20 Thread ASF subversion and git services (Jira)


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

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

Commit d490dcf5f19a396d25ebe014f6dd8990e7154c9f in jena's branch 
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=d490dcf ]

Merge pull request #604 from afs/stats-handler

JENA-1757: Deprecate GraphStatisticsHandler

> Deprecate GraphStatisticsHandler
> 
>
> Key: JENA-1757
> URL: https://issues.apache.org/jira/browse/JENA-1757
> Project: Apache Jena
>  Issue Type: Task
>  Components: Core
>Affects Versions: Jena 3.12.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Graph statistics give the number of for "S P O" where S, P or O can be a 
> wildcard.
> This didn't quite work out for query optimization - the needs for 
> optimization are a little more complicated, needing information such as "if S 
> is going to fixed, estimate the number of "S P O" with out yet knowing what S 
> is fixed as, or it might be one of several values.
> The only significant implementation is \{{GraphMemStatisticsHandler}} for the 
> plain memory graphs. It does exploit the mem indexes to get the count, 
> compared to counting a "find" but the improvement appears to be small. 
> Proposal: deprecate {{GraphStatisticsHandler}}, retain the mem code "just in 
> case".
> This will clear the way for either removal or incompatible change in the 
> future.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (JENA-1757) Deprecate GraphStatisticsHandler

2019-09-20 Thread ASF subversion and git services (Jira)


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

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

Commit 493b7f7a853d9b4ee6e47b9d275a0956fec3c7d8 in jena's branch 
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=493b7f7 ]

JENA-1757: Deprecate GraphStatisticsHandler


> Deprecate GraphStatisticsHandler
> 
>
> Key: JENA-1757
> URL: https://issues.apache.org/jira/browse/JENA-1757
> Project: Apache Jena
>  Issue Type: Task
>  Components: Core
>Affects Versions: Jena 3.12.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Graph statistics give the number of for "S P O" where S, P or O can be a 
> wildcard.
> This didn't quite work out for query optimization - the needs for 
> optimization are a little more complicated, needing information such as "if S 
> is going to fixed, estimate the number of "S P O" with out yet knowing what S 
> is fixed as, or it might be one of several values.
> The only significant implementation is \{{GraphMemStatisticsHandler}} for the 
> plain memory graphs. It does exploit the mem indexes to get the count, 
> compared to counting a "find" but the improvement appears to be small. 
> Proposal: deprecate {{GraphStatisticsHandler}}, retain the mem code "just in 
> case".
> This will clear the way for either removal or incompatible change in the 
> future.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (JENA-1757) Deprecate GraphStatisticsHandler

2019-09-20 Thread Andy Seaborne (Jira)


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

Andy Seaborne resolved JENA-1757.
-
Fix Version/s: Jena 3.13.0
   Resolution: Done

> Deprecate GraphStatisticsHandler
> 
>
> Key: JENA-1757
> URL: https://issues.apache.org/jira/browse/JENA-1757
> Project: Apache Jena
>  Issue Type: Task
>  Components: Core
>Affects Versions: Jena 3.12.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.13.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Graph statistics give the number of for "S P O" where S, P or O can be a 
> wildcard.
> This didn't quite work out for query optimization - the needs for 
> optimization are a little more complicated, needing information such as "if S 
> is going to fixed, estimate the number of "S P O" with out yet knowing what S 
> is fixed as, or it might be one of several values.
> The only significant implementation is \{{GraphMemStatisticsHandler}} for the 
> plain memory graphs. It does exploit the mem indexes to get the count, 
> compared to counting a "find" but the improvement appears to be small. 
> Proposal: deprecate {{GraphStatisticsHandler}}, retain the mem code "just in 
> case".
> This will clear the way for either removal or incompatible change in the 
> future.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [jena] afs merged pull request #604: JENA-1757: Deprecate GraphStatisticsHandler

2019-09-20 Thread GitBox
afs merged pull request #604: JENA-1757: Deprecate GraphStatisticsHandler
URL: https://github.com/apache/jena/pull/604
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


Re: Discuss: write PREFIX not @prefix?

2019-09-20 Thread Claude Warren
For me this falls under "if it ain't broke don't fix it"
so
-1


On Fri, Sep 20, 2019 at 11:47 AM Andy Seaborne  wrote:

> The Turtle and TriG writers output "@prefix".
>
> RDF 1.1 allows PREFIX.
>
> Should we change the writers to output PREFIX? (after the next release)
>
> (we can add options but majority of users don't set options and exisintg
> code doesn't)
>
>  Andy
>


-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren


Discuss: write PREFIX not @prefix?

2019-09-20 Thread Andy Seaborne

The Turtle and TriG writers output "@prefix".

RDF 1.1 allows PREFIX.

Should we change the writers to output PREFIX? (after the next release)

(we can add options but majority of users don't set options and exisintg 
code doesn't)


Andy