Re: CMS diff:
Done - thanks Andy On 18/02/15 04:10, Tom Saleeba wrote: Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fquery%2Fproperty_paths.mdtext Tom Saleeba Index: trunk/content/documentation/query/property_paths.mdtext === --- trunk/content/documentation/query/property_paths.mdtext (revision 1655891) +++ trunk/content/documentation/query/property_paths.mdtext (working copy) @@ -13,7 +13,7 @@ regular expression but over properties, not characters. ARQ determines all matches of a path expression and binds subject or object as appropriate. Only one match is recorded - no duplicates -for any given path expression, although is the path is used in a +for any given path expression, although if the path is used in a situation where it's initial points is already repeated in a pattern, then this duplication is preserved.
JENA-686, Add support for cross field conjunctive queries in jena-text
Dear All I have been putting in some work on JENA-686 [1] (which dates back to April 2014 ...). We have a fork of Jena with a modified jena-text which I have just integrated with changes made to Jena since we forked (but not the most recent version of Jena yet). "Integrated" means that: * the jena-text tests pass with the necessary modifications to exercise the extension point we added * our new indexer (which uses the extension point added to jena-text) also passes its own tests. I'd rather like the changes to jena-text reviewed. What would be the preferred approach? The diffs between our modified jena-text and the moderately-recent-jena-master come to about 700 lines, and I will write a short summary of what the changes are about. I can push my local working branch of jena-text if that would be helpful -- so far I haven't wanted to change the jena repo state. I'd expecially appreciated Stephen Allen's view as I believe he has been doing some work around jena-text recently. Chris [1] https://issues.apache.org/jira/browse/JENA-686 -- "It took a very long time, much longer than the most /Sector General/ generous estimates." Epimorphics Ltd, http://www.epimorphics.com Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT Epimorphics Ltd. is a limited company registered in England (number 7016688)
Re: JENA-686, Add support for cross field conjunctive queries in jena-text
Chris Since we moved to git we can accept pull requests. If you push to a fork of Jena on GitHub (forked from the Apache mirror at github.com/apache/jena) and then open a pull request from your changes we can use the nice GitHub interface to review and comment on the pull request, any comments are mirrored to a thread on the dev list (and any replies to that thread mirrored back to the GitHub PR) so the discussion is archived in both places Btw would you mind updating JENA-686 to say that you are working on it and removing the gsoc labels since we're about to start getting potential GSoC students looking for projects and if this work is already done we don't want to waste prospective students time with something that is already pretty much done Rob On 18/02/2015 09:49, "Chris Dollin" wrote: >Dear All > >I have been putting in some work on JENA-686 [1] (which dates back to >April 2014 ...). We have a fork of Jena with a modified jena-text which >I have just integrated with changes made to Jena since we forked >(but not the most recent version of Jena yet). > >"Integrated" means that: > >* the jena-text tests pass with the necessary modifications to exercise > the extension point we added > >* our new indexer (which uses the extension point added to jena-text) > also passes its own tests. > >I'd rather like the changes to jena-text reviewed. What would be the >preferred approach? The diffs between our modified jena-text and the >moderately-recent-jena-master come to about 700 lines, and I will write a >short summary of what the changes are about. I can push my local >working branch of jena-text if that would be helpful -- so far I haven't >wanted to change the jena repo state. > >I'd expecially appreciated Stephen Allen's view as I believe he has been >doing >some work around jena-text recently. > >Chris > >[1] https://issues.apache.org/jira/browse/JENA-686 > >-- >"It took a very long time, much longer than the most /Sector >General/ > generous estimates." > >Epimorphics Ltd, http://www.epimorphics.com >Registered address: Court Lodge, 105 High Street, Portishead, Bristol >BS20 6PT >Epimorphics Ltd. is a limited company registered in England (number >7016688) >
[jira] [Commented] (JENA-686) Add support for cross field conjunctive queries in jena-text
[ https://issues.apache.org/jira/browse/JENA-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325719#comment-14325719 ] christopher james dollin commented on JENA-686: --- Chris Dollin is now working on this issue and has code ready to review. > Add support for cross field conjunctive queries in jena-text > > > Key: JENA-686 > URL: https://issues.apache.org/jira/browse/JENA-686 > Project: Apache Jena > Issue Type: Improvement > Components: Text >Affects Versions: Jena 2.11.1, Fuseki 1.0.1 >Reporter: Brian McBride > Labels: gsoc, gsoc2015 > Attachments: TestDatasetWithBatchProducer.java > > > We have a project where we are doing text search on addresses and wish to do > jena text queries like "city:liverpool AND street:green". These queries > return no results, whilst queries like "street:green AND street:lane" work > fine. > The reason is that jena text indexes each property in a separate Lucene > document, so there is no Lucene document matching city:liverpool AND > street:green, there are two documents, one for each property. > Given the scale of our data, we really want to do the conjunctive query in > Lucene and not two separate queries and then a filter in SPARQL. > I will attach a test case from an attempt to solve this for us to illustrate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (JENA-686) Add support for cross field conjunctive queries in jena-text
[ https://issues.apache.org/jira/browse/JENA-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] christopher james dollin reassigned JENA-686: - Assignee: christopher james dollin > Add support for cross field conjunctive queries in jena-text > > > Key: JENA-686 > URL: https://issues.apache.org/jira/browse/JENA-686 > Project: Apache Jena > Issue Type: Improvement > Components: Text >Affects Versions: Jena 2.11.1, Fuseki 1.0.1 >Reporter: Brian McBride >Assignee: christopher james dollin > Labels: gsoc, gsoc2015 > Attachments: TestDatasetWithBatchProducer.java > > > We have a project where we are doing text search on addresses and wish to do > jena text queries like "city:liverpool AND street:green". These queries > return no results, whilst queries like "street:green AND street:lane" work > fine. > The reason is that jena text indexes each property in a separate Lucene > document, so there is no Lucene document matching city:liverpool AND > street:green, there are two documents, one for each property. > Given the scale of our data, we really want to do the conjunctive query in > Lucene and not two separate queries and then a filter in SPARQL. > I will attach a test case from an attempt to solve this for us to illustrate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JENA-686) Add support for cross field conjunctive queries in jena-text
[ https://issues.apache.org/jira/browse/JENA-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] christopher james dollin updated JENA-686: -- Labels: (was: gsoc gsoc2015) > Add support for cross field conjunctive queries in jena-text > > > Key: JENA-686 > URL: https://issues.apache.org/jira/browse/JENA-686 > Project: Apache Jena > Issue Type: Improvement > Components: Text >Affects Versions: Jena 2.11.1, Fuseki 1.0.1 >Reporter: Brian McBride >Assignee: christopher james dollin > Attachments: TestDatasetWithBatchProducer.java > > > We have a project where we are doing text search on addresses and wish to do > jena text queries like "city:liverpool AND street:green". These queries > return no results, whilst queries like "street:green AND street:lane" work > fine. > The reason is that jena text indexes each property in a separate Lucene > document, so there is no Lucene document matching city:liverpool AND > street:green, there are two documents, one for each property. > Given the scale of our data, we really want to do the conjunctive query in > Lucene and not two separate queries and then a filter in SPARQL. > I will attach a test case from an attempt to solve this for us to illustrate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: JENA-686, Add support for cross field conjunctive queries in jena-text
On 02/18/2015 10:49 AM, Rob Vesse wrote: Since we moved to git we can accept pull requests. [...] Following up. Thanks, Rob. If you push to a fork of Jena on GitHub (forked from the Apache mirror at github.com/apache/jena) and then open a pull request from your changes we can use the nice GitHub interface to review and comment on the pull request, any comments are mirrored to a thread on the dev list (and any replies to that thread mirrored back to the GitHub PR) so the discussion is archived in both places Btw would you mind updating JENA-686 to say [...] Done. Chris -- "It took a very long time, much longer than the most /Sector General/ generous estimates." Epimorphics Ltd, http://www.epimorphics.com Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT Epimorphics Ltd. is a limited company registered in England (number 7016688)
[GitHub] jena pull request: JENA-878 Avoid exposing xerces.impl.dv
Github user afs commented on a diff in the pull request: https://github.com/apache/jena/pull/31#discussion_r24904425 --- Diff: jena-core/src/main/java/com/hp/hpl/jena/datatypes/xsd/impl/XSDGenericType.java --- @@ -1,66 +0,0 @@ -/* --- End diff -- Why is this moved to XSDDatatype? Seems to be just stylistic. --- 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] [Commented] (JENA-878) Avoid dependencies on xerces.impl
[
https://issues.apache.org/jira/browse/JENA-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325948#comment-14325948
]
ASF GitHub Bot commented on JENA-878:
-
Github user afs commented on a diff in the pull request:
https://github.com/apache/jena/pull/31#discussion_r24904425
--- Diff:
jena-core/src/main/java/com/hp/hpl/jena/datatypes/xsd/impl/XSDGenericType.java
---
@@ -1,66 +0,0 @@
-/*
--- End diff --
Why is this moved to XSDDatatype? Seems to be just stylistic.
> Avoid dependencies on xerces.impl
> -
>
> Key: JENA-878
> URL: https://issues.apache.org/jira/browse/JENA-878
> Project: Apache Jena
> Issue Type: Task
> Components: Jena
>Affects Versions: Jena 2.13.0
>Reporter: Stian Soiland-Reyes
>Priority: Minor
>
> Building jena-osgi complains about xerces.impl dependencies:
> > [WARNING] Bundle org.apache.jena:jena-osgi:bundle:2.12.2-SNAPSHOT : Unused
> > Private-Package instructions, no such package(s) on the class path: [!*]
> > [WARNING] Bundle org.apache.jena:jena-osgi:bundle:2.12.2-SNAPSHOT : Export
> > com.hp.hpl.jena.datatypes.xsd, has 1, private references
> > [org.apache.xerces.impl.dv],
> {code}
> stain@biggie-utopic:~/src/jena/jena-core/src/main/java/com/hp/hpl/jena/datatypes$
> grep -r xerces.*impl .
> ./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.* ;
> ./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.util.Base64 ;
> ./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.util.HexBin ;
> ./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.xs.DecimalDV ;
> ./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl ;
> ./xsd/XSDDatatype.java:import
> org.apache.xerces.impl.validation.ValidationState ;
> ./xsd/XSDhexBinary.java:import org.apache.xerces.impl.dv.util.HexBin ;
> ./xsd/XSDbase64Binary.java:import org.apache.xerces.impl.dv.util.Base64 ;
> ./xsd/impl/XSDGenericType.java:import org.apache.xerces.impl.dv.XSSimpleType;
> {code}
> It is not good style to depend on *.impl of a package - it is liable to fall
> over at some point. jena-osgi complains, but works in this particular case,
> because xercesImpl is shadowed in.
> Some/all of these (base64) are available through more official packages -
> org.apache.commons.codec.binary.Base64 comes to mind.
> https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html
> https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Hex.html
> So this task suggests to replace these dependencies with commons-codec
> versions. Remember to add commons-codec to jena-osgi as well!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] jena pull request: JENA-878 Avoid exposing xerces.impl.dv
Github user afs commented on a diff in the pull request: https://github.com/apache/jena/pull/31#discussion_r24904627 --- Diff: jena-core/src/main/java/com/hp/hpl/jena/datatypes/xsd/XSDDatatype.java --- @@ -18,34 +18,52 @@ package com.hp.hpl.jena.datatypes.xsd; -import java.io.Reader ; -import java.math.BigDecimal ; -import java.math.BigInteger ; +import java.io.Reader; +import java.math.BigDecimal; +import java.math.BigInteger; import java.net.URI; -import java.util.ArrayList ; -import java.util.List ; - -import org.apache.xerces.impl.dv.* ; -import org.apache.xerces.impl.dv.util.Base64 ; -import org.apache.xerces.impl.dv.util.HexBin ; -import org.apache.xerces.impl.dv.xs.DecimalDV ; -import org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl ; -import org.apache.xerces.impl.validation.ValidationState ; -import org.apache.xerces.parsers.XMLGrammarPreparser ; -import org.apache.xerces.util.SymbolHash ; -import org.apache.xerces.xni.grammars.XMLGrammarDescription ; -import org.apache.xerces.xni.grammars.XSGrammar ; -import org.apache.xerces.xni.parser.XMLInputSource ; -import org.apache.xerces.xs.XSConstants ; -import org.apache.xerces.xs.XSNamedMap ; -import org.apache.xerces.xs.XSTypeDefinition ; - -import com.hp.hpl.jena.datatypes.BaseDatatype ; -import com.hp.hpl.jena.datatypes.DatatypeFormatException ; -import com.hp.hpl.jena.datatypes.RDFDatatype ; -import com.hp.hpl.jena.datatypes.TypeMapper ; -import com.hp.hpl.jena.datatypes.xsd.impl.* ; -import com.hp.hpl.jena.graph.impl.LiteralLabel ; +import java.util.ArrayList; +import java.util.List; + +import org.apache.xerces.impl.dv.InvalidDatatypeValueException; +import org.apache.xerces.impl.dv.SchemaDVFactory; +import org.apache.xerces.impl.dv.ValidatedInfo; +import org.apache.xerces.impl.dv.ValidationContext; +import org.apache.xerces.impl.dv.XSSimpleType; +import org.apache.xerces.impl.dv.util.Base64; +import org.apache.xerces.impl.dv.util.HexBin; +import org.apache.xerces.impl.dv.xs.DecimalDV; +import org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl; +import org.apache.xerces.impl.validation.ValidationState; +import org.apache.xerces.parsers.XMLGrammarPreparser; +import org.apache.xerces.util.SymbolHash; +import org.apache.xerces.xni.grammars.XMLGrammarDescription; +import org.apache.xerces.xni.grammars.XSGrammar; +import org.apache.xerces.xni.parser.XMLInputSource; +import org.apache.xerces.xs.XSConstants; +import org.apache.xerces.xs.XSNamedMap; +import org.apache.xerces.xs.XSTypeDefinition; + +import com.hp.hpl.jena.datatypes.BaseDatatype; +import com.hp.hpl.jena.datatypes.DatatypeFormatException; +import com.hp.hpl.jena.datatypes.RDFDatatype; +import com.hp.hpl.jena.datatypes.TypeMapper; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDBaseNumericType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDBaseStringType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDByteType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDDateTimeType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDDateType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDDayType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDDouble; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDDurationType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDFloat; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDMonthDayType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDMonthType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDPlainType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDTimeType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDYearMonthType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDYearType; +import com.hp.hpl.jena.graph.impl.LiteralLabel; --- End diff -- Gnerally, we havn't enforced style of imports. These will get lost is anyone uses Eclipse to reformat and has * collapse on (which it is by default). --- 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] [Commented] (JENA-878) Avoid dependencies on xerces.impl
[ https://issues.apache.org/jira/browse/JENA-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325951#comment-14325951 ] ASF GitHub Bot commented on JENA-878: - Github user afs commented on a diff in the pull request: https://github.com/apache/jena/pull/31#discussion_r24904627 --- Diff: jena-core/src/main/java/com/hp/hpl/jena/datatypes/xsd/XSDDatatype.java --- @@ -18,34 +18,52 @@ package com.hp.hpl.jena.datatypes.xsd; -import java.io.Reader ; -import java.math.BigDecimal ; -import java.math.BigInteger ; +import java.io.Reader; +import java.math.BigDecimal; +import java.math.BigInteger; import java.net.URI; -import java.util.ArrayList ; -import java.util.List ; - -import org.apache.xerces.impl.dv.* ; -import org.apache.xerces.impl.dv.util.Base64 ; -import org.apache.xerces.impl.dv.util.HexBin ; -import org.apache.xerces.impl.dv.xs.DecimalDV ; -import org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl ; -import org.apache.xerces.impl.validation.ValidationState ; -import org.apache.xerces.parsers.XMLGrammarPreparser ; -import org.apache.xerces.util.SymbolHash ; -import org.apache.xerces.xni.grammars.XMLGrammarDescription ; -import org.apache.xerces.xni.grammars.XSGrammar ; -import org.apache.xerces.xni.parser.XMLInputSource ; -import org.apache.xerces.xs.XSConstants ; -import org.apache.xerces.xs.XSNamedMap ; -import org.apache.xerces.xs.XSTypeDefinition ; - -import com.hp.hpl.jena.datatypes.BaseDatatype ; -import com.hp.hpl.jena.datatypes.DatatypeFormatException ; -import com.hp.hpl.jena.datatypes.RDFDatatype ; -import com.hp.hpl.jena.datatypes.TypeMapper ; -import com.hp.hpl.jena.datatypes.xsd.impl.* ; -import com.hp.hpl.jena.graph.impl.LiteralLabel ; +import java.util.ArrayList; +import java.util.List; + +import org.apache.xerces.impl.dv.InvalidDatatypeValueException; +import org.apache.xerces.impl.dv.SchemaDVFactory; +import org.apache.xerces.impl.dv.ValidatedInfo; +import org.apache.xerces.impl.dv.ValidationContext; +import org.apache.xerces.impl.dv.XSSimpleType; +import org.apache.xerces.impl.dv.util.Base64; +import org.apache.xerces.impl.dv.util.HexBin; +import org.apache.xerces.impl.dv.xs.DecimalDV; +import org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl; +import org.apache.xerces.impl.validation.ValidationState; +import org.apache.xerces.parsers.XMLGrammarPreparser; +import org.apache.xerces.util.SymbolHash; +import org.apache.xerces.xni.grammars.XMLGrammarDescription; +import org.apache.xerces.xni.grammars.XSGrammar; +import org.apache.xerces.xni.parser.XMLInputSource; +import org.apache.xerces.xs.XSConstants; +import org.apache.xerces.xs.XSNamedMap; +import org.apache.xerces.xs.XSTypeDefinition; + +import com.hp.hpl.jena.datatypes.BaseDatatype; +import com.hp.hpl.jena.datatypes.DatatypeFormatException; +import com.hp.hpl.jena.datatypes.RDFDatatype; +import com.hp.hpl.jena.datatypes.TypeMapper; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDBaseNumericType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDBaseStringType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDByteType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDDateTimeType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDDateType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDDayType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDDouble; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDDurationType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDFloat; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDMonthDayType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDMonthType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDPlainType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDTimeType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDYearMonthType; +import com.hp.hpl.jena.datatypes.xsd.impl.XSDYearType; +import com.hp.hpl.jena.graph.impl.LiteralLabel; --- End diff -- Gnerally, we havn't enforced style of imports. These will get lost is anyone uses Eclipse to reformat and has * collapse on (which it is by default). > Avoid dependencies on xerces.impl > - > > Key: JENA-878 > URL: https://issues.apache.org/jira/browse/JENA-878 > Project: Apache Jena > Issue Type: Task > Components: Jena >Affects Versions: Jena 2.13.0 >Reporter: Stian Soiland-Reyes >Priority: Minor > > Building jena-osgi complains about xerces.impl dependencies: > > [WARNING] Bundle org.apache.jena:jena-osgi:bundle:2.12.2-SNAPSHOT : Unused > > Private-Package instructions, no such package(s) on the class path: [!*] > > [WARNING] Bundle org.apache.jena:jena-os
[jira] [Updated] (JENA-882) Index support for ordered ResultSet
[ https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Magnus Knuth updated JENA-882: -- Priority: Minor (was: Major) > Index support for ordered ResultSet > --- > > Key: JENA-882 > URL: https://issues.apache.org/jira/browse/JENA-882 > Project: Apache Jena > Issue Type: New Feature > Components: ARQ >Affects Versions: Jena 2.12.1 >Reporter: Magnus Knuth >Priority: Minor > > index statements are never created due to unreachable code: > https://github.com/apache/jena/blob/95b1c7c20b0255715434b820b7c37c667d58a68f/jena-arq/src/main/java/com/hp/hpl/jena/sparql/resultset/RDFOutput.java#L85 > Is that because of any objections? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JENA-882) Index support for ordered ResultSet
Magnus Knuth created JENA-882: - Summary: Index support for ordered ResultSet Key: JENA-882 URL: https://issues.apache.org/jira/browse/JENA-882 Project: Apache Jena Issue Type: New Feature Components: ARQ Affects Versions: Jena 2.12.1 Reporter: Magnus Knuth index statements are never created due to unreachable code: https://github.com/apache/jena/blob/95b1c7c20b0255715434b820b7c37c667d58a68f/jena-arq/src/main/java/com/hp/hpl/jena/sparql/resultset/RDFOutput.java#L85 Is that because of any objections? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JENA-883) ResultSetCompare.equalsByTerm and equalsByValue always returns true
Magnus Knuth created JENA-883: - Summary: ResultSetCompare.equalsByTerm and equalsByValue always returns true Key: JENA-883 URL: https://issues.apache.org/jira/browse/JENA-883 Project: Apache Jena Issue Type: New Feature Components: ARQ Affects Versions: Jena 2.12.1 Reporter: Magnus Knuth Priority: Critical isomorphic() is called with (rs1, rs2) instead of (rs1a, rs2a). That should fix this issue!? https://github.com/apache/jena/blob/7e5abeed5eac39b32397d9d8f05c6a84be3d516a/jena-arq/src/main/java/com/hp/hpl/jena/sparql/resultset/ResultSetCompare.java#L112 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JENA-883) ResultSetCompare.equalsByTerm and equalsByValue always returns true
[ https://issues.apache.org/jira/browse/JENA-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Magnus Knuth updated JENA-883: -- Issue Type: Bug (was: New Feature) > ResultSetCompare.equalsByTerm and equalsByValue always returns true > --- > > Key: JENA-883 > URL: https://issues.apache.org/jira/browse/JENA-883 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.12.1 >Reporter: Magnus Knuth >Priority: Critical > > isomorphic() is called with (rs1, rs2) instead of (rs1a, rs2a). That should > fix this issue!? > https://github.com/apache/jena/blob/7e5abeed5eac39b32397d9d8f05c6a84be3d516a/jena-arq/src/main/java/com/hp/hpl/jena/sparql/resultset/ResultSetCompare.java#L112 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JENA-882) Index support for ordered ResultSet
[ https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Magnus Knuth updated JENA-882: -- Issue Type: Improvement (was: New Feature) > Index support for ordered ResultSet > --- > > Key: JENA-882 > URL: https://issues.apache.org/jira/browse/JENA-882 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ >Affects Versions: Jena 2.12.1 >Reporter: Magnus Knuth >Priority: Minor > > index statements are never created due to unreachable code: > https://github.com/apache/jena/blob/95b1c7c20b0255715434b820b7c37c667d58a68f/jena-arq/src/main/java/com/hp/hpl/jena/sparql/resultset/RDFOutput.java#L85 > Is that because of any objections? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (JENA-883) ResultSetCompare.equalsByTerm and equalsByValue always returns true
[ https://issues.apache.org/jira/browse/JENA-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne reassigned JENA-883: -- Assignee: Andy Seaborne > ResultSetCompare.equalsByTerm and equalsByValue always returns true > --- > > Key: JENA-883 > URL: https://issues.apache.org/jira/browse/JENA-883 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.12.1 >Reporter: Magnus Knuth >Assignee: Andy Seaborne >Priority: Critical > > isomorphic() is called with (rs1, rs2) instead of (rs1a, rs2a). That should > fix this issue!? > https://github.com/apache/jena/blob/7e5abeed5eac39b32397d9d8f05c6a84be3d516a/jena-arq/src/main/java/com/hp/hpl/jena/sparql/resultset/ResultSetCompare.java#L112 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JENA-883) ResultSetCompare.equalsByTerm and equalsByValue always returns true
[ https://issues.apache.org/jira/browse/JENA-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-883: --- Priority: Major (was: Critical) > ResultSetCompare.equalsByTerm and equalsByValue always returns true > --- > > Key: JENA-883 > URL: https://issues.apache.org/jira/browse/JENA-883 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.12.1 >Reporter: Magnus Knuth >Assignee: Andy Seaborne > Fix For: Jena 2.13.0 > > > isomorphic() is called with (rs1, rs2) instead of (rs1a, rs2a). That should > fix this issue!? > https://github.com/apache/jena/blob/7e5abeed5eac39b32397d9d8f05c6a84be3d516a/jena-arq/src/main/java/com/hp/hpl/jena/sparql/resultset/ResultSetCompare.java#L112 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-883) ResultSetCompare.equalsByTerm and equalsByValue always returns true
[ https://issues.apache.org/jira/browse/JENA-883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14326653#comment-14326653 ] Andy Seaborne commented on JENA-883: Oops! Fixed Thanks > ResultSetCompare.equalsByTerm and equalsByValue always returns true > --- > > Key: JENA-883 > URL: https://issues.apache.org/jira/browse/JENA-883 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.12.1 >Reporter: Magnus Knuth >Assignee: Andy Seaborne > Fix For: Jena 2.13.0 > > > isomorphic() is called with (rs1, rs2) instead of (rs1a, rs2a). That should > fix this issue!? > https://github.com/apache/jena/blob/7e5abeed5eac39b32397d9d8f05c6a84be3d516a/jena-arq/src/main/java/com/hp/hpl/jena/sparql/resultset/ResultSetCompare.java#L112 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JENA-883) ResultSetCompare.equalsByTerm and equalsByValue always returns true
[ https://issues.apache.org/jira/browse/JENA-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-883: --- Fix Version/s: Jena 2.13.0 > ResultSetCompare.equalsByTerm and equalsByValue always returns true > --- > > Key: JENA-883 > URL: https://issues.apache.org/jira/browse/JENA-883 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.12.1 >Reporter: Magnus Knuth >Assignee: Andy Seaborne > Fix For: Jena 2.13.0 > > > isomorphic() is called with (rs1, rs2) instead of (rs1a, rs2a). That should > fix this issue!? > https://github.com/apache/jena/blob/7e5abeed5eac39b32397d9d8f05c6a84be3d516a/jena-arq/src/main/java/com/hp/hpl/jena/sparql/resultset/ResultSetCompare.java#L112 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (JENA-883) ResultSetCompare.equalsByTerm and equalsByValue always returns true
[ https://issues.apache.org/jira/browse/JENA-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne closed JENA-883. -- Resolution: Fixed > ResultSetCompare.equalsByTerm and equalsByValue always returns true > --- > > Key: JENA-883 > URL: https://issues.apache.org/jira/browse/JENA-883 > Project: Apache Jena > Issue Type: Bug > Components: ARQ >Affects Versions: Jena 2.12.1 >Reporter: Magnus Knuth >Assignee: Andy Seaborne > Fix For: Jena 2.13.0 > > > isomorphic() is called with (rs1, rs2) instead of (rs1a, rs2a). That should > fix this issue!? > https://github.com/apache/jena/blob/7e5abeed5eac39b32397d9d8f05c6a84be3d516a/jena-arq/src/main/java/com/hp/hpl/jena/sparql/resultset/ResultSetCompare.java#L112 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.
[
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14326857#comment-14326857
]
Bruno P. Kinoshita commented on JENA-632:
-
Hi Andy! Sorry for the delay. Sounds good to me. I should have followed your
initial suggestion of starting by doing the streaming version first :-) I will
take a look at {{JSWriter}} and will try to come up with an update in the next
days.
Thanks!
> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
> Labels: java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL)
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user
> community, basic understanding of HTTP and content negotiation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
