[jira] [Commented] (JENA-1647) Update jena-iri for RFC 8141 (revised URN RFC).
[
https://issues.apache.org/jira/browse/JENA-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16715099#comment-16715099
]
ASF GitHub Bot commented on JENA-1647:
--
Github user asfgit closed the pull request at:
https://github.com/apache/jena/pull/505
> Update jena-iri for RFC 8141 (revised URN RFC).
> ---
>
> Key: JENA-1647
> URL: https://issues.apache.org/jira/browse/JENA-1647
> Project: Apache Jena
> Issue Type: Improvement
>Affects Versions: Jena 3.9.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.10.0
>
>
> RFC 8141 allows "/", "~" and "?" in the NSS part of a URN.
> "?" is only allowed as "?=" and "?+"
> {{urn:NID:NSS}}
> "?"is still excluded by jena-iri because it is used in URN resolution
> algorithms for r-component and q-component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1647) Update jena-iri for RFC 8141 (revised URN RFC).
[
https://issues.apache.org/jira/browse/JENA-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16715096#comment-16715096
]
ASF subversion and git services commented on JENA-1647:
---
Commit 40ededc3ce05d4b1c27b1b58ae13ad98aca74996 in jena's branch
refs/heads/master from [~an...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=40ededc ]
JENA-1647: Allow '/' and '~' in URNs
Remove copies of XML files in in src/main/java
> Update jena-iri for RFC 8141 (revised URN RFC).
> ---
>
> Key: JENA-1647
> URL: https://issues.apache.org/jira/browse/JENA-1647
> Project: Apache Jena
> Issue Type: Improvement
>Affects Versions: Jena 3.9.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.10.0
>
>
> RFC 8141 allows "/", "~" and "?" in the NSS part of a URN.
> "?" is only allowed as "?=" and "?+"
> {{urn:NID:NSS}}
> "?"is still excluded by jena-iri because it is used in URN resolution
> algorithms for r-component and q-component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1647) Update jena-iri for RFC 8141 (revised URN RFC).
[
https://issues.apache.org/jira/browse/JENA-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16715097#comment-16715097
]
ASF subversion and git services commented on JENA-1647:
---
Commit 42dc4289bf97cb826301be9c3230f5208eb23ccb in jena's branch
refs/heads/master from [~an...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=42dc428 ]
JENA-1647: Merge commit 'refs/pull/505/head' of https://github.com/apache/jena
This closes #505.
> Update jena-iri for RFC 8141 (revised URN RFC).
> ---
>
> Key: JENA-1647
> URL: https://issues.apache.org/jira/browse/JENA-1647
> Project: Apache Jena
> Issue Type: Improvement
>Affects Versions: Jena 3.9.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.10.0
>
>
> RFC 8141 allows "/", "~" and "?" in the NSS part of a URN.
> "?" is only allowed as "?=" and "?+"
> {{urn:NID:NSS}}
> "?"is still excluded by jena-iri because it is used in URN resolution
> algorithms for r-component and q-component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (JENA-1647) Update jena-iri for RFC 8141 (revised URN RFC).
[
https://issues.apache.org/jira/browse/JENA-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne resolved JENA-1647.
-
Resolution: Fixed
> Update jena-iri for RFC 8141 (revised URN RFC).
> ---
>
> Key: JENA-1647
> URL: https://issues.apache.org/jira/browse/JENA-1647
> Project: Apache Jena
> Issue Type: Improvement
>Affects Versions: Jena 3.9.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.10.0
>
>
> RFC 8141 allows "/", "~" and "?" in the NSS part of a URN.
> "?" is only allowed as "?=" and "?+"
> {{urn:NID:NSS}}
> "?"is still excluded by jena-iri because it is used in URN resolution
> algorithms for r-component and q-component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] jena pull request #505: JENA-1647: Allow '/' and '~' in URNs
Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/505 ---
[DISCUSS] Move Jena repo to gitbox or github
I confess I don't completely understand the details/changes here "either the ASF repository system (gitbox.apache.org) OR GitHub for your development and code pushes" unless you can mix-and-match, in case anyone does not want to forced to have a GH account. gitbox.apache.org says "will be granted write-access on both services (gitbox and github)" if you have your GH account linked to your Apache account (which I do). The other unclarity is what happens about JIRA integration. We have managed to get people to use JIRA so whatever we may think about it at a technical level, we do have as a communication path. The Q has been asked on the infra list but no response yet. The text about either service sort of hints that that if there is an integration, it works on both access points. JIRA is useful during a release to find changes since last time. Obviously, GH issues and labels can be used for that but we need to set that up. There again, a clearout of old dead stuff would not be so bad! We have a release sometime soon (ish, maybe, whatever) and I think my only issue is controlling the switchover point in time, sooner is better, and otherwise we do it and see what happens. For workflow, if we have to fix on one tailored to GH or gitbox.a.o, shall we go GH? If it's both, we can start being more GH on our own timescales. Thoughts? Let's discuss for a few days and if nothing arises, run the vote. Andy But please, not go back to SVN :-) On 09/12/2018 20:47, Andy Seaborne wrote: [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS] Hello Apache projects, I am writing to you because you may have git repositories on the git-wip-us server, which is slated to be decommissioned in the coming months. All repositories will be moved to the new gitbox service which includes direct write access on github as well as the standard ASF commit access via gitbox.apache.org. ## Why this move? ## The move comes as a result of retiring the git-wip service, as the hardware it runs on is longing for retirement. In lieu of this, we have decided to consolidate the two services (git-wip and gitbox), to ease the management of our repository systems and future-proof the underlying hardware. The move is fully automated, and ideally, nothing will change in your workflow other than added features and access to GitHub. ## Timeframe for relocation ## Initially, we are asking that projects voluntarily request to move their repositories to gitbox, hence this email. The voluntary timeframe is between now and January 9th 2019, during which projects are free to either move over to gitbox or stay put on git-wip. After this phase, we will be requiring the remaining projects to move within one month, after which we will move the remaining projects over. To have your project moved in this initial phase, you will need: - Consensus in the project (documented via the mailing list) - File a JIRA ticket with INFRA to voluntarily move your project repos over to gitbox (as stated, this is highly automated and will take between a minute and an hour, depending on the size and number of your repositories) To sum up the preliminary timeline; - December 9th 2018 -January 9th 2019: Voluntary (coordinated) relocation - January 9th -February 6th: Mandated (coordinated) relocation - February 7th: All remaining repositories are mass migrated. This timeline may change to accommodate various scenarios. ## Using GitHub with ASF repositories ## When your project has moved, you are free to use either the ASF repository system (gitbox.apache.org) OR GitHub for your development and code pushes. To be able to use GitHub, please follow the primer at: https://reference.apache.org/committer/github We appreciate your understanding of this issue, and hope that your project can coordinate voluntarily moving your repositories in a timely manner. All settings, such as commit mail targets, issue linking, PR notification schemes etc will automatically be migrated to gitbox as well. With regards, Daniel on behalf of ASF Infra. PS:For inquiries, please reply to us...@infra.apache.org, not your project's dev list :-).
[GitHub] jena issue #473: Extendable versions of classes for printing result sets
Github user afs commented on the issue: https://github.com/apache/jena/pull/473 I got sidetracked :-) last time. The code in this area is ancient. Text format isn't like the other formats because (1) it is isn't self-contained, It needs prefixes for abbreviation and (2) there isn't an input version. Where are you wanting to output text format? `QueryExecutils.outputResultSet` handles it - making `ResultSetFormatter.output(OutputStream, ResultSet, ResultsFormat)` do the same (lookup properly for first-class results formats, and have some adapter code to handle the other ways) is one way. Would that work or you? ---
Re: Toward Jena 3.10.0
yes I would think so. looking forward to test the incorporated Fuseki release. On Mon, Dec 10, 2018 at 8:20 AM Greg Albiston wrote: > Hi Marco, > > There doesn't seem to be an option on the embedded Fuseki Server API to > set for this. > It seems like there is extra configuration done by the Fuseki release > that isn't present in the API. > > If the GeoSPARQL-Fuseki functionality is incorporated into the Fuseki > release then wouldn't this issue be resolved? > > Thanks, > > Greg > > On 09/12/2018 22:43, Marco Neumann wrote: > > Greg, I am doing further testing, when issuing queries from OpenLayers > on a > > remote machine I am getting a "No Access-Control-Allow-Origin header is > > present" error in the browser. I don't have that problem with the > standard > > fuseki release. I don't see an option in the geosparql fuseki server > > configuration to enable this with the current release. > > > > Access to XMLHttpRequest at ' > > > http://192.168.0.15:3030/ds/sparql?query=PREFIX%20PREFIX%20rdfs%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%20PREFIX%20geo%3A%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23%3E%20PREFIX%20geosparql%3A%3Chttp%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23%3E%20PREFIX%20geof%3A%3Chttp%3A%2F%2Fwww.opengis.net%2Fdef%2Ffunction%2Fgeosparql%2F%3E%20Select%20*%20WHERE%7B%3Fobject%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fentity%2FP625%3E%20%3Fgeometry%20.%3Fobject%20rdfs%3Alabel%20%3Flabel%20.%20%3Fobject%20geo%3Alat%20%3Flat%20.%20%3Fobject%20geo%3Along%20%3Flon%20.%20FILTER(geof%3AsfWithin(%3Fgeometry%2C%22POLYGON((53.3299984%20-6.199%2C53.3299984%203.8007%2C63.3299984%203.8007%2C63.3299984%20-6.199%2C53.3299984%20-6.199))%22%5E%5Egeosparql%3AwktLiteral))%7D=json > ' > > from origin 'http://192.168.0.15' has been blocked by CORS policy: No > > 'Access-Control-Allow-Origin' header is present on the requested > resource. > > > > > > On Tue, Dec 4, 2018 at 1:29 PM Marco Neumann > > wrote: > > > >> > >> On Tue, Dec 4, 2018 at 1:04 PM Greg Albiston > wrote: > >> > >>> Hi Marco, > >>> > >>> 2. The GeoSPARQL-Fuseki application has some options for convenience in > >>> setting up the Fuseki server. It looks like the two minute delay is > >>> caused by applying RDFS inferencing to the dataset and then writing the > >>> results into the datset (i.e. Jena operations). The GeoSPARQL schema > has > >>> a class and property hierachy that a user can apply to their dataset > for > >>> some of the functionality. The inferencing is applied by default when > >>> loading a file, but also when connecting to a TDB, in case it hasn't > >>> been done manually by the user. The other potentially costly operation > >>> is creating "hasDefaultGeometry" properties, which is switched off by > >>> default. > >>> > >> ah OK that's good to know > >> > >> > >>> The following line should lead to quicker loading the second time. > >>> > >>> ./geosparql-fuseki --loopback false --tdb TDB1 --inference > >> > >> this looks useful I will check it out tonight > >> > >> > >>> I could change the setup so that file loading applies inferencing by > >>> default and TDB does not, but I thought picking one would be better for > >>> consistent behaviour. Always true means less burden for users working > >>> out why they might have a problem after loading their dataset. > >>> > >>> There is probably a broader question as to how/if these options should > >>> be integrated in with Fuseki, whether it should be a separate > >>> application or they should be left out. I think they are useful to a > >>> user who is looking for a GeoSPARQL solution. Currently, > >>> GeoSPARQL-Fuseki is using the main/embedded server so doesn't have a > GUI > >>> etc. > >> > >>> 3. I get what you mean about the invalidty of the query now. The > polygon > >>> is invalid because it is not closed. However, I'm unclear about how > >>> these errors and warnings are handled any different to if there was a > >>> SPARQL syntax error. A Query Parse Exception is thrown with full stack > >>> trace. The error highlights the specific problem while the warning > shows > >>> the context of the error and stack trace. This made it easier to hunt > >>> down these kinds of problems when they could be coming from a query or > >>> the dataset. What would you be looking for instead? > >>> > >> it would be great if we could tie this closer into query processor and > >> have the query canceled on a spatial pre processor error like the one > above > >> and report something to the user. because now it seems to hit all wkts > in > >> the dataset before finishing up (of course ignoring LIMIT in the sparql > >> query) while the user waits with no further information to be finally > >> presented with a an empty results table. > >> > >> > >> Best, > >> Marco > >> > >> > >> > >>> Thanks, > >>> > >>> Greg > >>> > >>> On 04/12/2018 12:01, Marco Neumann wrote: >
Re: Toward Jena 3.10.0
Hi Marco, There doesn't seem to be an option on the embedded Fuseki Server API to set for this. It seems like there is extra configuration done by the Fuseki release that isn't present in the API. If the GeoSPARQL-Fuseki functionality is incorporated into the Fuseki release then wouldn't this issue be resolved? Thanks, Greg On 09/12/2018 22:43, Marco Neumann wrote: Greg, I am doing further testing, when issuing queries from OpenLayers on a remote machine I am getting a "No Access-Control-Allow-Origin header is present" error in the browser. I don't have that problem with the standard fuseki release. I don't see an option in the geosparql fuseki server configuration to enable this with the current release. Access to XMLHttpRequest at ' http://192.168.0.15:3030/ds/sparql?query=PREFIX%20PREFIX%20rdfs%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%20PREFIX%20geo%3A%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23%3E%20PREFIX%20geosparql%3A%3Chttp%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23%3E%20PREFIX%20geof%3A%3Chttp%3A%2F%2Fwww.opengis.net%2Fdef%2Ffunction%2Fgeosparql%2F%3E%20Select%20*%20WHERE%7B%3Fobject%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fentity%2FP625%3E%20%3Fgeometry%20.%3Fobject%20rdfs%3Alabel%20%3Flabel%20.%20%3Fobject%20geo%3Alat%20%3Flat%20.%20%3Fobject%20geo%3Along%20%3Flon%20.%20FILTER(geof%3AsfWithin(%3Fgeometry%2C%22POLYGON((53.3299984%20-6.199%2C53.3299984%203.8007%2C63.3299984%203.8007%2C63.3299984%20-6.199%2C53.3299984%20-6.199))%22%5E%5Egeosparql%3AwktLiteral))%7D=json' from origin 'http://192.168.0.15' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. On Tue, Dec 4, 2018 at 1:29 PM Marco Neumann wrote: On Tue, Dec 4, 2018 at 1:04 PM Greg Albiston wrote: Hi Marco, 2. The GeoSPARQL-Fuseki application has some options for convenience in setting up the Fuseki server. It looks like the two minute delay is caused by applying RDFS inferencing to the dataset and then writing the results into the datset (i.e. Jena operations). The GeoSPARQL schema has a class and property hierachy that a user can apply to their dataset for some of the functionality. The inferencing is applied by default when loading a file, but also when connecting to a TDB, in case it hasn't been done manually by the user. The other potentially costly operation is creating "hasDefaultGeometry" properties, which is switched off by default. ah OK that's good to know The following line should lead to quicker loading the second time. ./geosparql-fuseki --loopback false --tdb TDB1 --inference this looks useful I will check it out tonight I could change the setup so that file loading applies inferencing by default and TDB does not, but I thought picking one would be better for consistent behaviour. Always true means less burden for users working out why they might have a problem after loading their dataset. There is probably a broader question as to how/if these options should be integrated in with Fuseki, whether it should be a separate application or they should be left out. I think they are useful to a user who is looking for a GeoSPARQL solution. Currently, GeoSPARQL-Fuseki is using the main/embedded server so doesn't have a GUI etc. 3. I get what you mean about the invalidty of the query now. The polygon is invalid because it is not closed. However, I'm unclear about how these errors and warnings are handled any different to if there was a SPARQL syntax error. A Query Parse Exception is thrown with full stack trace. The error highlights the specific problem while the warning shows the context of the error and stack trace. This made it easier to hunt down these kinds of problems when they could be coming from a query or the dataset. What would you be looking for instead? it would be great if we could tie this closer into query processor and have the query canceled on a spatial pre processor error like the one above and report something to the user. because now it seems to hit all wkts in the dataset before finishing up (of course ignoring LIMIT in the sparql query) while the user waits with no further information to be finally presented with a an empty results table. Best, Marco Thanks, Greg On 04/12/2018 12:01, Marco Neumann wrote: comments inline On Mon, Dec 3, 2018 at 5:14 PM Greg Albiston wrote: Hi Marco, 1. As mentioned this shouldn't be too difficult to support. indeed not difficult but needs a decision you could try with the following geonames dataset all-geonames_lotico.ttl.gz 2. Yes, the indexing, or rather caching, is in-memory, but it is on-demand. There shouldn't be any delay at start-up beyond what Jena needs to do. The cost comes during query execution. The key invariant data produced for solutions is retained for a short period of time (but can be configured to be
