date:20200221

[jira] [Updated] (JENA-1848) Trig Writer slow; doesn't scale to many graphs

2020-02-21 Thread Claus Stadler (Jira)



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

Claus Stadler updated JENA-1848:

Description: 
The following code for loading 1.000.000 graphs takes 1 minute on my notebook, 
but I stopped my attempt of writing the data out as trig after several hours.
{code:java}
Dataset ds = RDFDataMgr.loadDataset("test-data.trig");
RDFDataMgr.write(new NullOutputStream(), ds, RDFFormat.TRIG_PRETTY);
{code}

In comparison, writing takes 2 seconds for me with RDFFormat.NQUADS.

The test data I used can be generated with this *gendata.sh* bash script:
{code:bash}
#!/bin/bash
MAX=${1:-10}
echo "@prefix eg:  ."
for i in `seq 1 $MAX`; do
  echo " {  eg:idx $i }"
done
{code}

Invoke the script with the number of named graphs to generate, in my case I used
{code:bash}
./gendata.sh 100 > test-data.trig`
{code}

With the profiler I could trace the problem to code in 
[TurtleShell.java|https://github.com/apache/jena/blob/2a13a9c633f1c8661c1a446a9d98819391c09477/jena-arq/src/main/java/org/apache/jena/riot/writer/TurtleShell.java#L185]
 which repeatedly collects all one million graph names :

{code:java}
this.graphNames = (dsg != null) ? Iter.toSet(dsg.listGraphNodes()) : null ;`
{code}




  was:
The following code for loading 1.000.000 graphs takes 1 minute on my notebook, 
but I stopped my attempt of writing the data out as trig after several hours.
{code:java}
Dataset ds = RDFDataMgr.loadDataset("test-data.trig");
RDFDataMgr.write(new NullOutputStream(), ds, RDFFormat.TRIG_PRETTY);
{code}

In comparison, writing takes 2 seconds for me with RDFFormat.NQUADS.

The test data I used can be generated with this *gendata.sh* bash script:
{code:bash}
#!/bin/bash
MAX=${1:-10}
echo "@prefix eg:  ."
for i in `seq 1 $MAX`; do
  echo " {  eg:idx $i }"
done
{code}

Invoke the script with the number of named graphs to generate, in my case I used
{code:bash}
./gendata.sh 100 > test-data.trig`
{code}

With the profiler I could trace the problem to code in *TurtleShell.java* which 
repeatedly collects all one million graph names :

{code:java}
this.graphNames = (dsg != null) ? Iter.toSet(dsg.listGraphNodes()) : null ;`
{code}

https://github.com/apache/jena/blob/2a13a9c633f1c8661c1a446a9d98819391c09477/jena-arq/src/main/java/org/apache/jena/riot/writer/TurtleShell.java#L185




> Trig Writer slow; doesn't scale to many graphs
> --
>
> Key: JENA-1848
> URL: https://issues.apache.org/jira/browse/JENA-1848
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: RIOT
>Affects Versions: Jena 3.14.0
>Reporter: Claus Stadler
>Priority: Major
>
> The following code for loading 1.000.000 graphs takes 1 minute on my 
> notebook, but I stopped my attempt of writing the data out as trig after 
> several hours.
> {code:java}
> Dataset ds = RDFDataMgr.loadDataset("test-data.trig");
> RDFDataMgr.write(new NullOutputStream(), ds, RDFFormat.TRIG_PRETTY);
> {code}
> In comparison, writing takes 2 seconds for me with RDFFormat.NQUADS.
> The test data I used can be generated with this *gendata.sh* bash script:
> {code:bash}
> #!/bin/bash
> MAX=${1:-10}
> echo "@prefix eg:  ."
> for i in `seq 1 $MAX`; do
>   echo " {  eg:idx $i }"
> done
> {code}
> Invoke the script with the number of named graphs to generate, in my case I 
> used
> {code:bash}
> ./gendata.sh 100 > test-data.trig`
> {code}
> With the profiler I could trace the problem to code in 
> [TurtleShell.java|https://github.com/apache/jena/blob/2a13a9c633f1c8661c1a446a9d98819391c09477/jena-arq/src/main/java/org/apache/jena/riot/writer/TurtleShell.java#L185]
>  which repeatedly collects all one million graph names :
> {code:java}
> this.graphNames = (dsg != null) ? Iter.toSet(dsg.listGraphNodes()) : null ;`
> {code}



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

[jira] [Updated] (JENA-1848) Trig Writer slow; doesn't scale to many graphs

2020-02-21 Thread Claus Stadler (Jira)



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

Claus Stadler updated JENA-1848:

Description: 
The following code for loading 1.000.000 graphs takes 1 minute on my notebook, 
but I stopped my attempt of writing the data out as trig after several hours.
{code:java}
Dataset ds = RDFDataMgr.loadDataset("test-data.trig");
RDFDataMgr.write(new NullOutputStream(), ds, RDFFormat.TRIG_PRETTY);
{code}

In comparison, writing takes 2 seconds for me with RDFFormat.NQUADS.

The test data I used can be generated with this *gendata.sh* bash script:
{code:bash}
#!/bin/bash
MAX=${1:-10}
echo "@prefix eg:  ."
for i in `seq 1 $MAX`; do
  echo " {  eg:idx $i }"
done
{code}

Invoke the script with the number of named graphs to generate, in my case I used
{code:bash}
./gendata.sh 100 > test-data.trig`
{code}

With the profiler I could trace the problem to code in *TurtleShell.java* which 
repeatedly collects all one million graph names :

{code:java}
this.graphNames = (dsg != null) ? Iter.toSet(dsg.listGraphNodes()) : null ;`
{code}

https://github.com/apache/jena/blob/2a13a9c633f1c8661c1a446a9d98819391c09477/jena-arq/src/main/java/org/apache/jena/riot/writer/TurtleShell.java#L185



  was:
The following code for loading 1.000.000 graphs takes 1 minute on my notebook, 
but I stopped my attempt of writing the data out as trig after several hours.
{code:java}
Dataset ds = RDFDataMgr.loadDataset("test-data.trig");
RDFDataMgr.write(new NullOutputStream(), ds, RDFFormat.TRIG_PRETTY);
{code}

In comparison, writing takes 2 seconds for me with RDFFormat.NQUADS.

The test data I used can be generated with this *gendata.sh* bash script:
{code:bash}
#!/bin/bash
MAX=${1:-10}
echo "@prefix eg:  ."
for i in `seq 1 $MAX`; do
  echo " {  eg:idx $i }"
done
{code}

Invoke the script the number of named graphs to generate, in my case I used
{code:bash}
./gendata.sh 100 > test-data.trig`
{code}

With the profiler I could trace the problem to code in *TurtleShell.java* which 
repeatedly collects all one million graph names :

{code:java}
this.graphNames = (dsg != null) ? Iter.toSet(dsg.listGraphNodes()) : null ;`
{code}

https://github.com/apache/jena/blob/2a13a9c633f1c8661c1a446a9d98819391c09477/jena-arq/src/main/java/org/apache/jena/riot/writer/TurtleShell.java#L185




> Trig Writer slow; doesn't scale to many graphs
> --
>
> Key: JENA-1848
> URL: https://issues.apache.org/jira/browse/JENA-1848
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: RIOT
>Affects Versions: Jena 3.14.0
>Reporter: Claus Stadler
>Priority: Major
>
> The following code for loading 1.000.000 graphs takes 1 minute on my 
> notebook, but I stopped my attempt of writing the data out as trig after 
> several hours.
> {code:java}
> Dataset ds = RDFDataMgr.loadDataset("test-data.trig");
> RDFDataMgr.write(new NullOutputStream(), ds, RDFFormat.TRIG_PRETTY);
> {code}
> In comparison, writing takes 2 seconds for me with RDFFormat.NQUADS.
> The test data I used can be generated with this *gendata.sh* bash script:
> {code:bash}
> #!/bin/bash
> MAX=${1:-10}
> echo "@prefix eg:  ."
> for i in `seq 1 $MAX`; do
>   echo " {  eg:idx $i }"
> done
> {code}
> Invoke the script with the number of named graphs to generate, in my case I 
> used
> {code:bash}
> ./gendata.sh 100 > test-data.trig`
> {code}
> With the profiler I could trace the problem to code in *TurtleShell.java* 
> which repeatedly collects all one million graph names :
> {code:java}
> this.graphNames = (dsg != null) ? Iter.toSet(dsg.listGraphNodes()) : null ;`
> {code}
> https://github.com/apache/jena/blob/2a13a9c633f1c8661c1a446a9d98819391c09477/jena-arq/src/main/java/org/apache/jena/riot/writer/TurtleShell.java#L185



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

[jira] [Created] (JENA-1848) Trig Writer slow; doesn't scale to many graphs

2020-02-21 Thread Claus Stadler (Jira)

Claus Stadler created JENA-1848:
---

 Summary: Trig Writer slow; doesn't scale to many graphs
 Key: JENA-1848
 URL: https://issues.apache.org/jira/browse/JENA-1848
 Project: Apache Jena
  Issue Type: Improvement
  Components: RIOT
Affects Versions: Jena 3.14.0
Reporter: Claus Stadler


The following code for loading 1.000.000 graphs takes 1 minute on my notebook, 
but I stopped my attempt of writing the data out as trig after several hours.
{code:java}
Dataset ds = RDFDataMgr.loadDataset("test-data.trig");
RDFDataMgr.write(new NullOutputStream(), ds, RDFFormat.TRIG_PRETTY);
{code}

In comparison, writing takes 2 seconds for me with RDFFormat.NQUADS.

The test data I used can be generated with this *gendata.sh* bash script:
{code:bash}
#!/bin/bash
MAX=${1:-10}
echo "@prefix eg:  ."
for i in `seq 1 $MAX`; do
  echo " {  eg:idx $i }"
done
{code}

Invoke the script the number of named graphs to generate, in my case I used
{code:bash}
./gendata.sh 100 > test-data.trig`
{code}

With the profiler I could trace the problem to code in *TurtleShell.java* which 
repeatedly collects all one million graph names :

{code:java}
this.graphNames = (dsg != null) ? Iter.toSet(dsg.listGraphNodes()) : null ;`
{code}

https://github.com/apache/jena/blob/2a13a9c633f1c8661c1a446a9d98819391c09477/jena-arq/src/main/java/org/apache/jena/riot/writer/TurtleShell.java#L185





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

[jira] [Commented] (JENA-1847) getLocalName()

2020-02-21 Thread Andy Seaborne (Jira)



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

Andy Seaborne commented on JENA-1847:
-

{{getLocalName}} returns a split suitable for all situations. RDF/XML is the 
most restrictive. XML QNames can not start with a digit. For compatibility, we 
leave this behaviour for {{getLocalName}}.

See {{SplitIRI}} for variations of the split algorithms.

> getLocalName() 
> ---
>
> Key: JENA-1847
> URL: https://issues.apache.org/jira/browse/JENA-1847
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Base
>Affects Versions: Jena 3.12.0
>Reporter: Lutz Weber
>Priority: Major
>
> object.getLocalName() does not work for mixed number/letter IDs:
> from [http://xyz.com/ontology/123xyzuvw] we get xyzuvw 
>  from [http://xyz.com/ontology/x123yzuvw] we get x123yzuvw



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

[jira] [Created] (JENA-1847) getLocalName()

2020-02-21 Thread Lutz Weber (Jira)

Lutz Weber created JENA-1847:


 Summary: getLocalName() 
 Key: JENA-1847
 URL: https://issues.apache.org/jira/browse/JENA-1847
 Project: Apache Jena
  Issue Type: Bug
  Components: Base
Affects Versions: Jena 3.12.0
Reporter: Lutz Weber


object.getLocalName() does not work for mixed number/letter IDs:

from [http://xyz.com/ontology/123xyzuvw] we get xyzuvw 
 from [http://xyz.com/ontology/x123yzuvw] we get x123yzuvw



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

Re: [DISCUSS] Moving Jena site from Apache CMS/SVN to Git

2020-02-21 Thread Roy Lenferink

On 2020/02/21 18:24:08, Andy Seaborne  wrote: 
> Is the following description correct and complete?
> 
> 1/ We have repo "jena-site"
> 
> I prefer the website to be separate from the code and not in the 
> source-release so we are free to publish the site at anytime.

This is indeed my suggestion as well because sites most probably need to be 
updated separate from
releases.

> 
> 2/ We have a branch of the "jena-site:asf-site" that is the published 
> webside
> 
> 3/ There is a "jena-site:release-docs" branch for javadoc
> Let's say this has /javadoc

If we have the following configured in the gitwcsub.cfg (INFRA stuff)
/www/jena.apache.org:   $gitbox/jena-site
This means that the 'asf-site' contains a 'content' folder with the actual site 
content.

/www/jena.apache.org/content/documentation/javadoc: 
$gitbox/jena-site:release-docs
This means that everything from the root of the release-docs branch will be 
served on 
jena.apache.org/documentation/javadoc

The release-docs branch will contain an exact copy of the following: 
https://svn.apache.org/repos/infra/websites/production/jena/content/documentation/javadoc/

> 
> 4/ The site is built by a Jenkins job at ASF. The job is triggered manually.
> e.g.
> https://builds.apache.org/job/celix-site/
> 
> It is restricted to run on 'git-websites'
> 
> 5/ It runs a shell script - see the one for Celix -
> 
> In essence the job does:
> 
> * pull master
> * run Hugo to get the pages in /temp-??/output
> * switch to 'asf-site'
> * copy /temp-??/output to /content
>  /content/ is the site root.
> * 
> * commit
> * push -u
> 
> Is there an example of a project that does javadoc?
> Looks to me like at 
> 
> git co release-docs
> cp -r /javadoc /content/documentation/
> 

Copying the release-docs to the asf-site branch is not even necessary. The 
config above (the INFRA
part) defines that on the production machine content is being served from 2 
branches. It _is_ 
possible to copy it to the asf-site branch and then serve everything from the 
asf-site, but that is just
an additional step which I wouldn't do personally (we already have all the 
documentation available
on the release-docs branch, no need to copy it over. Just let INFRA handle the 
merging of the actual
content.

> It emails rlenfer...@apache.org -- no need to change that :-)

Let's keep that :)

> 
> We need to modify the script because it does not handle separate javadoc.
> 
> 6/ There is no "jena.staging.apache.org". It is replaced by people 
> running "hugo" locally to get "/target/content" : "hugo server" puts it 
> on http://localhost:1313

The staging domain is indeed gone. An alternative could be to use Netlify 
(netlify has free plans for 
OSS projects). Netlify will build pull requests and comment with a link to the 
preview. Celix has this
enabled as well. See this pull request as example: 
https://github.com/apache/celix-site/pull/7

(of course cgi scripts are not working but this is expected behavior)

But maybe with the new site build solution that INFRA is currently working on 
the staging domain
will be re-introduced as well ;) This is something we probably will find out in 
a couple of weeks.

> 
>  Andy
>

Re: [VOTE][LAZY] Move from CMS/SVN to Hugo/Git

2020-02-21 Thread ajs6f

With the same interpretation, +1, and thanks very much to Roy for looking into 
this!

ajs6f

> On Feb 21, 2020, at 1:26 PM, Andy Seaborne  wrote:
> 
> Interpreting as a general "in principle" to move website content ... no 
> timeline and (obviously) subject to new information becoming available.
> 
> +1
> 
> PMC - please vote and not leave to LAZY to indicate you are aware this is 
> work-in-progress.
> 
>Andy
> 
> On 19/02/2020 13:41, Roy Lenferink wrote:
>> Hi Jena community,
>> After last weeks proposal [1] I'd like to start a vote for moving over from 
>> the current Apache CMS
>> (and SVN) to use Hugo and git :)
>> Short recap about Hugo: Hugo is a static site generator which is already 
>> having more stars on
>> GitHub than Jekyll. It is easy to get started with (single static binary 
>> without dependencies) and it is
>> really doing well performance wise.
>> [ ] +1 for moving over from the Apache CMS / SVN to Hugo / Git.
>> [ ] 0 I don't have a strong opinion on this
>> [ ] -1 for not moving over, in this case please explain why
>> This vote will be open for the usual 72 hour period. Lazy consensus applies: 
>> if no -1 votes are being
>> cast within the voting period, the vote passes.
>> Best regards,
>> Roy
>> [1] 
>> https://lists.apache.org/thread.html/r1a46369ea6e9df4f0b0971934563b9e8433cb33fe42290240969bbe0%40%3Cdev.jena.apache.org%3E

Re: [VOTE][LAZY] Move from CMS/SVN to Hugo/Git

2020-02-21 Thread Chris Tomlinson

I like the idea of having the documentation on GitHub and separating the 
javadocs from the documentation website. I have no knowledge or opinion about 
mechanisms such as Hugo.

+1

Chris T

> On Feb 21, 2020, at 12:26 PM, Andy Seaborne  wrote:
> 
> Interpreting as a general "in principle" to move website content ... no 
> timeline and (obviously) subject to new information becoming available.
> 
> +1
> 
> PMC - please vote and not leave to LAZY to indicate you are aware this is 
> work-in-progress.
> 
>Andy
> 
> On 19/02/2020 13:41, Roy Lenferink wrote:
>> Hi Jena community,
>> After last weeks proposal [1] I'd like to start a vote for moving over from 
>> the current Apache CMS
>> (and SVN) to use Hugo and git :)
>> Short recap about Hugo: Hugo is a static site generator which is already 
>> having more stars on
>> GitHub than Jekyll. It is easy to get started with (single static binary 
>> without dependencies) and it is
>> really doing well performance wise.
>> [ ] +1 for moving over from the Apache CMS / SVN to Hugo / Git.
>> [ ] 0 I don't have a strong opinion on this
>> [ ] -1 for not moving over, in this case please explain why
>> This vote will be open for the usual 72 hour period. Lazy consensus applies: 
>> if no -1 votes are being
>> cast within the voting period, the vote passes.
>> Best regards,
>> Roy
>> [1] 
>> https://lists.apache.org/thread.html/r1a46369ea6e9df4f0b0971934563b9e8433cb33fe42290240969bbe0%40%3Cdev.jena.apache.org%3E

Re: [VOTE][LAZY] Move from CMS/SVN to Hugo/Git

2020-02-21 Thread Andy Seaborne

Interpreting as a general "in principle" to move website content ... no 
timeline and (obviously) subject to new information becoming available.


+1

PMC - please vote and not leave to LAZY to indicate you are aware this 
is work-in-progress.


Andy

On 19/02/2020 13:41, Roy Lenferink wrote:

Hi Jena community,

After last weeks proposal [1] I'd like to start a vote for moving over from the 
current Apache CMS
(and SVN) to use Hugo and git :)

Short recap about Hugo: Hugo is a static site generator which is already having 
more stars on
GitHub than Jekyll. It is easy to get started with (single static binary 
without dependencies) and it is
really doing well performance wise.

[ ] +1 for moving over from the Apache CMS / SVN to Hugo / Git.
[ ] 0 I don't have a strong opinion on this
[ ] -1 for not moving over, in this case please explain why

This vote will be open for the usual 72 hour period. Lazy consensus applies: if 
no -1 votes are being
cast within the voting period, the vote passes.

Best regards,
Roy

[1] 
https://lists.apache.org/thread.html/r1a46369ea6e9df4f0b0971934563b9e8433cb33fe42290240969bbe0%40%3Cdev.jena.apache.org%3E

Re: [DISCUSS] Moving Jena site from Apache CMS/SVN to Git

2020-02-21 Thread Andy Seaborne

Is the following description correct and complete?

1/ We have repo "jena-site"

I prefer the website to be separate from the code and not in the
source-release so we are free to publish the site at anytime.

2/ We have a branch of the "jena-site:asf-site" that is the published
webside

3/ There is a "jena-site:release-docs" branch for javadoc
Let's say this has /javadoc

4/ The site is built by a Jenkins job at ASF. The job is triggered manually.
e.g.
https://builds.apache.org/job/celix-site/

It is restricted to run on 'git-websites'

5/ It runs a shell script - see the one for Celix -

In essence the job does:

* pull master
* run Hugo to get the pages in /temp-??/output
* switch to 'asf-site'
* copy /temp-??/output to /content
/content/ is the site root.
*
* commit
* push -u

Is there an example of a project that does javadoc?
Looks to me like at

git co release-docs
cp -r /javadoc /content/documentation/

It emails rlenfer...@apache.org -- no need to change that :-)

We need to modify the script because it does not handle separate javadoc.

6/ There is no "jena.staging.apache.org". It is replaced by people
running "hugo" locally to get "/target/content" : "hugo server" puts it
on http://localhost:1313

Andy

[A]
https://www.apache.org/dev/project-site.html

On 19/02/2020 18:40, Roy Lenferink wrote:

(inline comments)

On 2020/02/19 17:04:56, Andy Seaborne wrote:

Sorry, I haven't had time to investigate all the machinery but if the
javadoc is a different branch or repo, how does publish happen? And not
happen for changes during the development cycle?

Publishing right now happens by checking out the 'production' site and adding
the javadocs to there.
Publishing in the git way would happen by adding the generated javadocs to a
separate branch or
repository.

Right now jena.a.o is served using SVN (config here [1]). In these config files
it is possible to specify
multiple lines and specify a subfolder as well. E.g. what beam is doing here
[2].

The following could make sense for jena:
/www/jena.apache.org: $gitbox/jena-site
/www/jena.apache.org/content/documentation/javadoc:
$gitbox/jena-site:release-docs

This means:
- That the 'master' branch will contain the sources for the site
- That the 'asf-site' branch will contain the generated output for the site
- That the 'release-docs' branch will contain additional files which will be
served at http://jena.apache.org/documentation/javadoc/

I know infra is working on a CMS replacement and/or guidelines. Is this
it? Is it compatible? I thought they were going to have a buildbot2.

Infra currently offers pelican and jekyll as 'replacements' for the CMS.
However, Infra is also testing
a new build approach were the project can more or less define how their site is
build [3]. This could
be a script to e.g. retrieve and execute Hugo.

I already had a quick chat with Infra about how to implement support for Hugo
(e.g. next to Jekyll
and Pelican) but we decided that the new build approach will probably be a
better fit.

Good to hear the community is interested in this :)

TBC: I am interested - I can't speak for the community.

My bad. I made the quick assumption by taking 2 responses and calling that 'the
community', which is
almost never the case, oops!

Let me know if any additional information is needed.

Roy

[1]
https://github.com/apache/infrastructure-puppet/blob/5bd3b7cc8bd6d8f2698a6e0cac1f421dd960ddf0/modules/svnwcsub/files/svnwcsub.conf#L115
[2]
https://github.com/apache/infrastructure-puppet/blob/5bd3b7cc8bd6d8f2698a6e0cac1f421dd960ddf0/modules/gitwcsub/files/config/gitwcsub.cfg#L49-L50
[3]
https://lists.apache.org/thread.html/rf0d4fef9b65e1ef346bc71b66253f9e54f15e048be6d011751a24ae0%40%3Cdev.community.apache.org%3E

[jira] [Created] (JENA-1846) Add CORS to Fuseki main

2020-02-21 Thread Andy Seaborne (Jira)

Andy Seaborne created JENA-1846:
---

 Summary: Add CORS to Fuseki main
 Key: JENA-1846
 URL: https://issues.apache.org/jira/browse/JENA-1846
 Project: Apache Jena
  Issue Type: Improvement
  Components: Fuseki
Affects Versions: Jena 3.14.0
Reporter: Andy Seaborne


[Report on 
users@|https://lists.apache.org/thread.html/rd99fbd1119ba5a657e89ef949c807567a338450d1212faee2bcf7c93%40%3Cusers.jena.apache.org%3E].




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

[jira] [Commented] (JENA-1840) Add --syntax to TDB loaders.

2020-02-21 Thread ASF subversion and git services (Jira)



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

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

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

JENA-1840: Add --syntax to tdbloader (TDB2)


> Add --syntax to TDB loaders.
> 
>
> Key: JENA-1840
> URL: https://issues.apache.org/jira/browse/JENA-1840
> Project: Apache Jena
>  Issue Type: Task
>Affects Versions: Jena 3.14.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.15.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> tdbloader (TDB1 and TDB2 versions) can read stdin but the input must be 
> N-Quads.
> This ticket covers adding a "–syntax" argument to set the syntax of the stdin 
> data.
> This is not for tdbloader2 which does not support reading from stdin.
>  



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

[jira] [Commented] (JENA-1840) Add --syntax to TDB loaders.

2020-02-21 Thread ASF subversion and git services (Jira)



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

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

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

JENA-1840: Add --syntax to tdbloader (TDB1)


> Add --syntax to TDB loaders.
> 
>
> Key: JENA-1840
> URL: https://issues.apache.org/jira/browse/JENA-1840
> Project: Apache Jena
>  Issue Type: Task
>Affects Versions: Jena 3.14.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.15.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> tdbloader (TDB1 and TDB2 versions) can read stdin but the input must be 
> N-Quads.
> This ticket covers adding a "–syntax" argument to set the syntax of the stdin 
> data.
> This is not for tdbloader2 which does not support reading from stdin.
>  



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

[jira] [Commented] (JENA-1840) Add --syntax to TDB loaders.

2020-02-21 Thread ASF subversion and git services (Jira)



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

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

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

Merge pull request #691 from afs/loader-syntax

 JENA-1840: Add --syntax to tdbloader (TDB1 and TDB2)

> Add --syntax to TDB loaders.
> 
>
> Key: JENA-1840
> URL: https://issues.apache.org/jira/browse/JENA-1840
> Project: Apache Jena
>  Issue Type: Task
>Affects Versions: Jena 3.14.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.15.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> tdbloader (TDB1 and TDB2 versions) can read stdin but the input must be 
> N-Quads.
> This ticket covers adding a "–syntax" argument to set the syntax of the stdin 
> data.
> This is not for tdbloader2 which does not support reading from stdin.
>  



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

[jira] [Updated] (JENA-1848) Trig Writer slow; doesn't scale to many graphs

[jira] [Updated] (JENA-1848) Trig Writer slow; doesn't scale to many graphs

[jira] [Created] (JENA-1848) Trig Writer slow; doesn't scale to many graphs

[jira] [Commented] (JENA-1847) getLocalName()

[jira] [Created] (JENA-1847) getLocalName()

Re: [DISCUSS] Moving Jena site from Apache CMS/SVN to Git

Re: [VOTE][LAZY] Move from CMS/SVN to Hugo/Git

Re: [VOTE][LAZY] Move from CMS/SVN to Hugo/Git

Re: [VOTE][LAZY] Move from CMS/SVN to Hugo/Git

Re: [DISCUSS] Moving Jena site from Apache CMS/SVN to Git

[jira] [Created] (JENA-1846) Add CORS to Fuseki main

[jira] [Commented] (JENA-1840) Add --syntax to TDB loaders.

[jira] [Commented] (JENA-1840) Add --syntax to TDB loaders.

[jira] [Commented] (JENA-1840) Add --syntax to TDB loaders.

14 matches

Site Navigation

Mail list logo

Footer information