Re: svn commit: r18065 - in /dev/jena: ./ binaries/ source/

[A. Soroka]

Before anyone points it out, yes, I just saw the "Jena X.Y.Z RC" message. :sigh:

Sorry. Shouldn't have keep working on this this late in the evening.

ajs6f


> On Jan 31, 2017, at 9:02 PM, aj...@apache.org wrote:
> 
> Author: ajs6f
> Date: Wed Feb  1 02:02:17 2017
> New Revision: 18065
> 
> Log:
> Jena X.Y.Z RC N
> 
> Added:
>dev/jena/binaries/apache-jena-3.2.0.tar.gz   (with props)
>dev/jena/binaries/apache-jena-3.2.0.tar.gz.asc
>dev/jena/binaries/apache-jena-3.2.0.tar.gz.md5
>dev/jena/binaries/apache-jena-3.2.0.tar.gz.sha1
>dev/jena/binaries/apache-jena-3.2.0.zip   (with props)
>dev/jena/binaries/apache-jena-3.2.0.zip.asc
>dev/jena/binaries/apache-jena-3.2.0.zip.md5
>dev/jena/binaries/apache-jena-3.2.0.zip.sha1
>dev/jena/binaries/apache-jena-fuseki-2.5.0.tar.gz   (with props)
>dev/jena/binaries/apache-jena-fuseki-2.5.0.tar.gz.asc
>dev/jena/binaries/apache-jena-fuseki-2.5.0.tar.gz.md5
>dev/jena/binaries/apache-jena-fuseki-2.5.0.tar.gz.sha1
>dev/jena/binaries/apache-jena-fuseki-2.5.0.zip   (with props)
>dev/jena/binaries/apache-jena-fuseki-2.5.0.zip.asc
>dev/jena/binaries/apache-jena-fuseki-2.5.0.zip.md5
>dev/jena/binaries/apache-jena-fuseki-2.5.0.zip.sha1
>dev/jena/binaries/jena-fuseki1-1.5.0-distribution.tar.gz   (with props)
>dev/jena/binaries/jena-fuseki1-1.5.0-distribution.tar.gz.asc
>dev/jena/binaries/jena-fuseki1-1.5.0-distribution.tar.gz.md5
>dev/jena/binaries/jena-fuseki1-1.5.0-distribution.tar.gz.sha1
>dev/jena/binaries/jena-fuseki1-1.5.0-distribution.zip   (with props)
>dev/jena/binaries/jena-fuseki1-1.5.0-distribution.zip.asc
>dev/jena/binaries/jena-fuseki1-1.5.0-distribution.zip.md5
>dev/jena/binaries/jena-fuseki1-1.5.0-distribution.zip.sha1
>dev/jena/source/jena-3.2.0-source-release.zip   (with props)
>dev/jena/source/jena-3.2.0-source-release.zip.asc
>dev/jena/source/jena-3.2.0-source-release.zip.md5
>dev/jena/source/jena-3.2.0-source-release.zip.sha1
> Modified:
>dev/jena/KEYS
> 
> Modified: dev/jena/KEYS
> ==
> --- dev/jena/KEYS (original)
> +++ dev/jena/KEYS Wed Feb  1 02:02:17 2017
> @@ -461,3 +461,61 @@ T01Ldx3SotOxOaUpA3crLd9f+7tVOskXo7XO8rYb
> 9kZuQY2d+EVHJXXTz35gtA==
> =Kosj
> -END PGP PUBLIC KEY BLOCK-
> +pub   4096R/DC3C98C3 2016-06-07 [expires: 2020-06-06]
> +uid   [ unknown] Adam Soroka (Apache key) 
> +sig 3DC3C98C3 2016-06-07  Adam Soroka (Apache key) 
> +sub   4096R/ADA1F5A1 2016-06-07 [expires: 2020-06-06]
> +sig  DC3C98C3 2016-06-07  Adam Soroka (Apache key) 
> +
> +-BEGIN PGP PUBLIC KEY BLOCK-
> +Comment: GPGTools - http://gpgtools.org
> +
> +mQINBFdW6lIBEAC6pPXflPkrLvaUni3aIN33tdPfYr28ExwnPuU0zmInSmivSh0y
> +WBEMpTA8RrMDLrR2/Iy2ESVOg/BDD2l2GnIp8QcXJLX6fFAi1uqaT9gDtdPSCIsz
> +uwitcNn/KPcDW3SJjQW8T3ARw/8Q+Yads1u+zF4nNk8mIKmRz9q6TlG8rT+gkcH7
> +DrMCjDB+h3oC1ONWPz0Nwes205JPWjFDsEdzqFOeKeTG4Y6aud6azMNLAB6N/r+j
> +mNVNsloLtG+Nro4sQt7ceaVa7VjnwJ5FZ4Kaik6RdtHOWsA67Rb52pHKbjNHx67n
> +XI/7cmm+KBG6lowfhc3SL54gD6F9rPF3iwN+zPVp+yUuvljsNUS7WskfOUsziNg+
> +n9eifg3bck4OLlyfrg69Zl9lQsBEYOy2VE9bysmFE7Gl2+WJGV1V1+N28VSfbEqx
> +3ft0zTRXvIp0hs48JBxktJN/SgepmnsTVpBelKlUCVuAj2BHbLctbpqMkRRmtCpX
> +URPTunbQM7OISdxahQiZPh3ZhQYHtxC5y7UQ40SMiZu5Zu7GZFyF3S94sk2O5Of6
> +CxtNDdroPm8ysQFYCgbfo5GU0gGMpDLV9mfnwcTr5FNySUz37VMI5D5709NG3fa1
> +m5lDSRXnKOYUhP5WAzLdhF3qsuklcwQ0z3KRqxT4Gga7RYc1izphRbElNwARAQAB
> +tCtBZGFtIFNvcm9rYSAoQXBhY2hlIGtleSkgPGFqczZmQGFwYWNoZS5vcmc+iQI/
> +BBMBCAApBQJXVupSAhsDBQkHhM4ABwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AA
> +CgkQmAy11dw8mMOLZRAAl1lSMQ+n9buckThR3FyBJAYktQ3qdzbjZAoAJrU/jbfF
> +NVFZMuFjXXyXjwPq9Nvmi0VRu7IZ3B30owD67AY00rWEiJpdVwteyJEGW9gVenmj
> +DveSDegdlQRXAukvoev8AgUkl4zGknvgKocCWQIKg7/+BxC9bLAFcYUlLRSMPhAj
> +Y0qEK6URkGGFAZhJrCwh1DuipaYYIfG7DjeytI1Rvvrs37UOgseYBahqwTlF5Vzh
> +vufUnqb6++ivM9AzQOPfjMrCQg7W7KM9MV63sFrNsR2kEuc3aJk6M88y5JOj8C4R
> +b+/W/G6UCVkLhLZkCSIxyjbmMlPI08AkZvfnHORS/0xGC1oN/HEp0uQ3Yp7a7/oJ
> +ldk7+y9b6CPm68tKxvG1gen90NuFvVLYmkRzzxYHgqQ5qifBbQFRGCnye+RLAzCR
> +mWdMLMbfbu0ULKYoQIyCQS+AJqJrbi7SMOXZDi7urFUC4eY2R4/4gXr8AFjEI42o
> +jQxwrcwMgimLO6adfvaM4p7QqeqvEbKnbkEv4Igr1bM8Khe02hb95wVw0uh0m5T9
> +lEOWzT9azcFAzF0ACSsvusu3uEELcsXilGBCtKo8X9CidHF2q1+cvkfHrfzUIFRQ
> +e0NM+008NUjT7bk4AcrZFuEt8VTYD105N/IQU/Vtv/9oGfMdMf+xFz8PJ7JVIHa5
> +Ag0EV1bqUgEQAMNQ3cvVs9CgGD5at6NIJGYk5MkAJfaf4n5bbmeWuv0R+23G/blm
> ++Z+2PQDYCkzYENMvvU+E8H2GIcP5d8kItUq7xr1H3RNUNwPieATaeuN9E8j5sCI7
> +Ood9F7xHEYjJ+l2JkESrSmRia9Rx30WkV3Mp4fNUDRjzRxcndUn1I6XtrYhf005k
> +hedDIEDIBze6U3xXxl0/egGFnbjkEAcemECUurbpz8IbO7vXffA9onszmjqpzm4N
> +uigZ48awrYyf8iNDcGYZy/cyKYxtdKu3S6A22s63mlRR0PAEBZzTpHtvtCM6iXwO
> +UCLCN7iBUoIf5eqyd3JrIkbXL2KiLAZY5P3bevV78nlcAWVrectvGLocc2wXSZ5L
> +9XUubnO980lKVrr8nG/hhMXgo6sjw6bakEefHJqTXQ93B2fIz5zgao8FeNuJWsIv
> +5h+ADY+JRUFH3hSOLGVnr4L7HRo5pqkuLrlPgTOGBCyfWBtIRsOPZ/7dINyBTHX0
> 

[jira] (JENA-1284) Improve GraphUtil operations by considering relative graph sizes.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1284:
--

GitHub user afs opened a pull request:

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

JENA-1284: Improvements for bulk graph operations in GraphUtil

(for Jena 3.3.0 development)

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

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

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

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


commit 781895ce64e062c7f2268a78189a777c39b92844
Author: Andy Seaborne 
Date:   2017-01-27T13:31:59Z

Improve bulk operations depending on relative sizes of graphs

commit 01419943d908676152c43a66bda16cb90cba3a46
Author: Andy Seaborne 
Date:   2017-01-28T12:13:16Z

Extra tests for bulk addInto/deleteFrom.




> Improve GraphUtil operations by considering relative graph sizes.
> -
>
> Key: JENA-1284
> URL: https://issues.apache.org/jira/browse/JENA-1284
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>
> Some of the bulk `GraphUtil` operations, `addInto` and `deleteFrom`, could be 
> improved to loop on the smaller graph and have different algorithms depending 
> on whether source or destination graph is smaller.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] jena pull request #212: JENA-1284: Improvements for bulk graph operations in...

[afs]

GitHub user afs opened a pull request:

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

JENA-1284: Improvements for bulk graph operations in GraphUtil

(for Jena 3.3.0 development)

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

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

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

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


commit 781895ce64e062c7f2268a78189a777c39b92844
Author: Andy Seaborne 
Date:   2017-01-27T13:31:59Z

Improve bulk operations depending on relative sizes of graphs

commit 01419943d908676152c43a66bda16cb90cba3a46
Author: Andy Seaborne 
Date:   2017-01-28T12:13:16Z

Extra tests for bulk addInto/deleteFrom.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] (JENA-1284) Improve GraphUtil operations by considering relative graph sizes.

[Andy Seaborne (JIRA)]

Andy Seaborne created JENA-1284:
---

 Summary: Improve GraphUtil operations by considering relative 
graph sizes.
 Key: JENA-1284
 URL: https://issues.apache.org/jira/browse/JENA-1284
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Andy Seaborne
Assignee: Andy Seaborne


Some of the bulk `GraphUtil` operations, `addInto` and `deleteFrom`, could be 
improved to loop on the smaller graph and have different algorithms depending 
on whether source or destination graph is smaller.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: not sure if I am on track for release

[A. Soroka]

Oh, you are certainly right, but that was a typo in the my email. Good, we are 
all on the same page.

ajs6f

> On Jan 31, 2017, at 10:04 AM, Osma Suominen  wrote:
> 
> 31.01.2017, 17:01, A. Soroka kirjoitti:
> 
>> Which is probably why it occurs to me to double-check myself: we _are_ going 
>> to 3.3.0-SNAPSHOT/2.6.0-SNAPSHOT/1.5.0-SNAPSHOT after this, right? That's 
>> what we decided?
> 
> 1.6.0-SNAPSHOT for Fuseki1, but other than that, I think you're right.
> 
> -Osma
> 
> 
> -- 
> Osma Suominen
> D.Sc. (Tech), Information Systems Specialist
> National Library of Finland
> P.O. Box 26 (Kaikukatu 4)
> 00014 HELSINGIN YLIOPISTO
> Tel. +358 50 3199529
> osma.suomi...@helsinki.fi
> http://www.nationallibrary.fi

Re: not sure if I am on track for release

[Osma Suominen]

31.01.2017, 17:01, A. Soroka kirjoitti:


Which is probably why it occurs to me to double-check myself: we _are_ going to 
3.3.0-SNAPSHOT/2.6.0-SNAPSHOT/1.5.0-SNAPSHOT after this, right? That's what we 
decided?


1.6.0-SNAPSHOT for Fuseki1, but other than that, I think you're right.

-Osma


--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suomi...@helsinki.fi
http://www.nationallibrary.fi

Re: not sure if I am on track for release

[A. Soroka]

I'm probably too cautious.

Which is probably why it occurs to me to double-check myself: we _are_ going to 
3.3.0-SNAPSHOT/2.6.0-SNAPSHOT/1.5.0-SNAPSHOT after this, right? That's what we 
decided?

ajs6f

> On Jan 31, 2017, at 9:36 AM, Andy Seaborne  wrote:
> 
> git is your friend!
> 
> On 31/01/17 13:07, A. Soroka wrote:
>> Okay, cool, I'm back on track. Sorry this is taking so long-- first time 
>> jitters!
>> 
>> ajs6f
>> 
>>> On Jan 30, 2017, at 6:29 PM, Andy Seaborne  wrote:
>>> 
>>> 
>>> 
>>> On 30/01/17 22:03, A. Soroka wrote:
 I'm done a dry run of release now (several times, actually). The
 versions in the release.properties file look good, e.g.:
 
 project.dev.org.apache.jena\:jena-iri=3.3.0-SNAPSHOT
 project.rel.org.apache.jena\:jena-cmds=3.2.0
 
 i.e. all the project.rel versions are 3.2.0 (or Fuseki-appropriate
 versions) and all the project.dev versions are 3.3.0-SNAPSHOT (or
 1.6.0-SNAPSHOT or 2.6.0-SNAPSHOT for Fuseki).
 
 BUT, the artifacts in target/ directories don't look right. They all
 have SNAPSHOT versions, e.g. jena-3.2.0-SNAPSHOT-source-release.zip
 or apache-jena-fuseki-2.5.0-SNAPSHOT.tar.gz.
 
 So the first question is: am I correct to think that this is wrong?
 Those should be the real release versions (3.2.0 or 2.5.0), right?
 And if this is wrong, is there some obvious thing I must have done to
 go off like this? It has been almost a year since I used the Maven
 release plugin, and I honestly remember very little of it.
>>> 
>>> 
>>> Same for me - target/*SNAPSHOT*
>>> 
>>> The dry run does not modify the pom.xml, or any files in git. It just 
>>> thinks about it and writes "pom.xml.tag" - that should be the pom that 
>>> would be used for real.
>>> 
>>>   Andy
>>> 
 
 ajs6f
 
>> 

Re: not sure if I am on track for release

[Andy Seaborne]

git is your friend!

On 31/01/17 13:07, A. Soroka wrote:

Okay, cool, I'm back on track. Sorry this is taking so long-- first time 
jitters!

ajs6f


On Jan 30, 2017, at 6:29 PM, Andy Seaborne  wrote:



On 30/01/17 22:03, A. Soroka wrote:

I'm done a dry run of release now (several times, actually). The
versions in the release.properties file look good, e.g.:

project.dev.org.apache.jena\:jena-iri=3.3.0-SNAPSHOT
project.rel.org.apache.jena\:jena-cmds=3.2.0

i.e. all the project.rel versions are 3.2.0 (or Fuseki-appropriate
versions) and all the project.dev versions are 3.3.0-SNAPSHOT (or
1.6.0-SNAPSHOT or 2.6.0-SNAPSHOT for Fuseki).

BUT, the artifacts in target/ directories don't look right. They all
have SNAPSHOT versions, e.g. jena-3.2.0-SNAPSHOT-source-release.zip
or apache-jena-fuseki-2.5.0-SNAPSHOT.tar.gz.

So the first question is: am I correct to think that this is wrong?
Those should be the real release versions (3.2.0 or 2.5.0), right?
And if this is wrong, is there some obvious thing I must have done to
go off like this? It has been almost a year since I used the Maven
release plugin, and I honestly remember very little of it.



Same for me - target/*SNAPSHOT*

The dry run does not modify the pom.xml, or any files in git. It just thinks about it and 
writes "pom.xml.tag" - that should be the pom that would be used for real.

   Andy



ajs6f

Re: not sure if I am on track for release

[A. Soroka]

Okay, cool, I'm back on track. Sorry this is taking so long-- first time 
jitters!

ajs6f

> On Jan 30, 2017, at 6:29 PM, Andy Seaborne  wrote:
> 
> 
> 
> On 30/01/17 22:03, A. Soroka wrote:
>> I'm done a dry run of release now (several times, actually). The
>> versions in the release.properties file look good, e.g.:
>> 
>> project.dev.org.apache.jena\:jena-iri=3.3.0-SNAPSHOT
>> project.rel.org.apache.jena\:jena-cmds=3.2.0
>> 
>> i.e. all the project.rel versions are 3.2.0 (or Fuseki-appropriate
>> versions) and all the project.dev versions are 3.3.0-SNAPSHOT (or
>> 1.6.0-SNAPSHOT or 2.6.0-SNAPSHOT for Fuseki).
>> 
>> BUT, the artifacts in target/ directories don't look right. They all
>> have SNAPSHOT versions, e.g. jena-3.2.0-SNAPSHOT-source-release.zip
>> or apache-jena-fuseki-2.5.0-SNAPSHOT.tar.gz.
>> 
>> So the first question is: am I correct to think that this is wrong?
>> Those should be the real release versions (3.2.0 or 2.5.0), right?
>> And if this is wrong, is there some obvious thing I must have done to
>> go off like this? It has been almost a year since I used the Maven
>> release plugin, and I honestly remember very little of it.
> 
> 
> Same for me - target/*SNAPSHOT*
> 
> The dry run does not modify the pom.xml, or any files in git. It just thinks 
> about it and writes "pom.xml.tag" - that should be the pom that would be used 
> for real.
> 
>Andy
> 
>> 
>> ajs6f
>> 

[GitHub] jena issue #211: writing jsonld: preserve id of blanknodes if they are valid...

[fpservant]

Github user fpservant commented on the issue:

https://github.com/apache/jena/pull/211
  
@afs OK, that was a quick hack, based on the existing. I'll need more time, 
then


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #211: writing jsonld: preserve id of blanknodes if they are valid...

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/211
  
**NodeToLabel**

The general idea in RIOT is that a specific, special instance of 
`NodeToLabel` be used for the conversion step. Writing nodes elsewhere uses a 
`NodeFormatter` which for Turtle etc takes a `NodeToLabel` for the conversion 
policy.  There is such an object `labels` in JenaRDF2JSONLD.

Hard coding an algorithm for JSON-LD seems less than ideal, together the 
assumption that Jena blank nodes have a specific form which is a feature of the 
`NodeToLabel` algorithm.

The correct way is to have a specific `NodeToLabel` for this.
Example: `NodeToLabel.createBNodeByLabelAsGiven` which will use labels 
unchanged.

**Determining which label to preserve**

This could be a hint carried by `BlankNodeId` with method `boolean 
BlankNodeId.preserveHint()` seems the proper way to me.  This could extend to 
all formats and generalizes the "use label as given" option.

If it is necessary to have a way without calling a new constructor for 
`BlankNodeId`, a way to do that might be to require the string be marked, say, 
`|...|` (c.f. using quotes `"`!)

I am not sure if this should be some kind of option to writing, rather than 
the default.

** Parsing **

See also `LabelToNode` for the parsing direction.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #211: writing jsonld: preserve id of blanknodes if they are valid...

[fpservant]

Github user fpservant commented on the issue:

https://github.com/apache/jena/pull/211
  
@afs yes


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #211: writing jsonld: preserve id of blanknodes if they are valid...

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/211
  
Is the intention to be able to allocate blank nodes in Jena with a specific 
label and have that label appear in the JSON-LD?



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena pull request #211: writing jsonld: preserve id of blanknodes if they ar...

[afs]

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

https://github.com/apache/jena/pull/211#discussion_r98633112
  
--- Diff: 
jena-arq/src/test/java/org/apache/jena/riot/writer/TestJsonLDWriter.java ---
@@ -460,15 +468,77 @@ private Model simpleModel(String ns) {
 // compactArrays is false -> an array for all props, even when 
there's only one value
 assertTrue(jsonld.indexOf("\"jobTitle\" : [ \"Professor\" ]") > 
-1);
 }
+
+/**
+ * Test blanknodes.
+ * 
+ * Several graphs, blanknodes with an id given by the user, or 
generated by jena
+ */
+@Test public final void blankNodesTest() throws IOException {
+ // create a dataset with one named graph, and some blanknodes
+
+Dataset ds = null;
+Model m = ModelFactory.createDefaultModel();
+Model m2 = ModelFactory.createDefaultModel();
+ds = DatasetFactory.create(m);
+String namedModelName = "http://ex.com/namedgraph;;
+ds.addNamedModel(namedModelName, m2);
+
+Resource s = m.createResource();
+m.add(s, RDFS.label, "blank node 1 in default graph");
+
+s = m2.createResource();
+m2.add(s, RDFS.label, "blank node 2 in named graph");
+   
+// blanknodes with given id, shared by the 2 graphs
+
+s = m.createResource(AnonId.create("_:foo"));
+m.add(s, RDFS.label, "_:foo in default graph");
+  
+s = m2.createResource(AnonId.create("_:foo"));
+m2.add(s, RDFS.label, "_:foo in named graph");
+
+s = m.createResource(AnonId.create("xxx"));
+m.add(s, RDFS.label, "xxx in default");
+  
+s = m2.createResource(AnonId.create("xxx"));
+m2.add(s, RDFS.label, "xxx in named");
+
+// this id will probably be changed in output
+s = m.createResource(AnonId.create("_:b0"));
+m.add(s, RDFS.label, "? in default graph");
+  
+s = m2.createResource(AnonId.create("_:b0"));
+m2.add(s, RDFS.label, "? in named graph");
+
+// write to jsonld
+ 
+String jsonld = dataset2jsonld(ds.asDatasetGraph(), 
RDFFormat.JSONLD, null);
+System.out.println(jsonld);
+
+// check we have kept the blanknodes identifiers that were valid 
jsonld bn identifiers
+assertTrue(jsonld.indexOf("\"_:foo\"") > -1);
--- End diff --

` if ( jsonld.contains("\"_:foo\"") )`


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: FOSDEM notes

[Andy Seaborne]

There are couple of general thing that would be useful to hear about:

1/ Experience of Java9 - how have projects been getting on with building 
and running with Java9?  We're a bit blocked with the lack of a maven 
release compatible with java9 but maybe other projects have pushed 
harder on maven plugin versions and got stuff working.  What running 
with Java9 and the new compact strings?


2/ Xerces : XSD 1.1

Jena handles xsd:datetimeStamp and the two derived durations introduced 
in XSD 1.1 by having code specifically for them.


Xerces has a download for XSD 1.1 beta version, dated 2010, and was 
based on working drafts, not the final specs.


There is an unofficial, non-apache, artifact in maven but not an Apache 
one.  What's the situation?


This came up in the gYear question - XSD 1.1 makes changes to BCE dates 
- but also because we have had the odd question about XML 1.1 parsing 
before.


This is all a bit tricky because Java8 and Java9 provide XSD 1.0 
although the XML datatype factory is automatically pluggable and should 
get updated when a full XSD 1.1 system is used.


Andy


On 30/01/17 21:55, A. Soroka wrote:

If you run into anyone from other Apache "sem web" projects that might use Jena 
as a dependency (e.g. Stanbol, Commons RDF, Clerezza, inter al.) I would be curious to 
hear how they feel about using Jena (fi they do, and if not, why not) and whether we have 
any improvements we could make from their POV. Also, if you happen to run into anyone 
using Jena in an OSGi context, I would be interested to hear about their experiences 
(good or bad).

If you hear anything about people using Elephas, it would be nice to know bow 
they are so doing.

From my POV, the interesting things coming along for Jena include better 
persistence (TDB2), explorations in concurrency, the beginnings of design for 
distribution, improvements to sidecar indexing... lots of other stuff I can't 
remember! :grin:

ajs6f


On Jan 30, 2017, at 12:13 PM, Claude Warren  wrote:

I will be attending FOSDEM next weekend and will spend some time at the
Apache table.  Are there any hot topics for Jena that I should mention?

Claude

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

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

[GitHub] jena pull request #211: writing jsonld: preserve id of blanknodes if they ar...

[fpservant]

GitHub user fpservant opened a pull request:

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

writing jsonld: preserve id of blanknodes if they are valid jsonld 
identifiers

current process to output jsonld computes identifiers for the blanknodes: 
_:b0, _:b1, etc.
Ids of blanknodes defined by the user (using AnonId.create()) are not used, 
even when they are valid jsonld blanknode identifiers.
Of course, this is just a cosmetic question - but if one took care to 
define valid bn identifiers, why wouldn't they be used in the output ?
This PR allows just that - with a limit: user defined identifiers beginning 
with "_:b" are not preserved (this, to avoid clash with those generated by jena)


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

$ git pull https://github.com/fpservant/jena master

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

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


commit 216111f1031482a68dcc1b6068c37adc84a7ee8b
Author: François-Paul Servant 
Date:   2017-01-31T09:06:25Z

writing jsonld: preserve id of blanknodes if they are valid jsonld
blanknode identifiers

commit 767bf5b261782b87f489a2f509fa743f7dea3541
Author: François-Paul Servant 
Date:   2017-01-31T09:18:19Z

cleaning

commit 849e070ad1122ad28bc080d295c8d174aa87af95
Author: François-Paul Servant 
Date:   2017-01-31T09:28:24Z

improved test




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---