[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=14327775#comment-14327775 ] ASF subversion and git services commented on JENA-883: -- Commit 3c5ba6eabc773705a4d626bb527aeda0c1bfc31f in jena's branch refs/heads/master from [~andy.seaborne] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=3c5ba6e ] JENA-883 : Fix of testing result sets. > 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-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=14327671#comment-14327671 ] christopher james dollin commented on JENA-686: --- That was a merge but there are conflicts to resolve. epimorphics/jena-config-doc-producer has the (broken) code in the branch updated-text-indexing and has been merged with the latest apache-jena. I will fix the conflicts tomorrow morning. Chris > 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)
[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=14327613#comment-14327613
]
Bruno P. Kinoshita commented on JENA-632:
-
Hi again,
Here's the updated code
https://github.com/kinow/jena/commit/7b3b10134f4201314d5f6c6103a595181e82f997
I noticed that I have been updating several imports (Eclipse auto-removes the
space before the {{;}}). I'll try to fix it before preparing the code for a
merge.
Here's how I used the {{JSWriter}}
https://github.com/kinow/jena/commit/7b3b10134f4201314d5f6c6103a595181e82f997#diff-c42503247148fd09663639cb9df2e641R693
And here's the new output:
{noformat}
[ {
"author" : "J.K. Rowling" ,
"title" : "Harry Potter and the Order of the Phoenix"
}
{
"author" : "J.K. Rowling" ,
"title" : "Harry Potter and the Philosopher's Stone"
}
{
"author" : "J.K. Rowling" ,
"title" : "Harry Potter and the Half-Blood Prince"
}
{
"author" : "J.K. Rowling" ,
"title" : "Harry Potter and the Deathly Hallows"
}
]
{noformat}
> 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)
[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=14327599#comment-14327599 ] christopher james dollin commented on JENA-686: --- Oops. That wasn't a merge. > 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)
[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=14327596#comment-14327596 ] christopher james dollin commented on JENA-686: --- I'm working toward exposure right now. I've updated my local repo to the latest master -- which seems to have worked as is, the (local) tests still pass, I'm just convincing myself that I have actually merged code -- and then I shall put the changes in the jena-config-etc repo. Chris > 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)
[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=14327501#comment-14327501 ] Andy Seaborne commented on JENA-686: Would it be possible to expose the code now even if not ready to integrate, e.g. in a personal github repository? As this is quite an old JIRA, minimising unnecessary change, or split pul request sin two "essential" and "other" will make integration a lot easier. > 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)
[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=14327462#comment-14327462 ] christopher james dollin commented on JENA-686: --- Pause while I deal with a bug that has surfaced in our soak tests of dependant code and pulling the changes up to a recent version of Jena (turns out the one I was using is more out-of-date than I had realised). Chris > 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)
[jira] [Commented] (JENA-882) Index support for ordered ResultSet
[ https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327434#comment-14327434 ] Andy Seaborne commented on JENA-882: Changes made. Naming chosen to maximise comparibility. Please could you review? If it helps, there will be a snapshot build soon as well (if the Apache Jenkins complex is running OK - we get unrelated build failures probbaly due to the extreme load the system is under). > 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] [Commented] (JENA-882) Index support for ordered ResultSet
[ https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327429#comment-14327429 ] ASF subversion and git services commented on JENA-882: -- Commit a0de31588a7aed4391e9d13738d84596125f33a6 in jena's branch refs/heads/master from [~andy.seaborne] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=a0de315 ] JENA-882 : align to deprecations in ResultSetFormatter/ResultSetFactory > 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] [Commented] (JENA-882) Index support for ordered ResultSet
[ https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327427#comment-14327427 ] ASF subversion and git services commented on JENA-882: -- Commit 84b0697de34f782872daa647942ab15830010295 in jena's branch refs/heads/master from [~andy.seaborne] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=84b0697 ] JENA-882 : Add flag for inserting result set row number. Add statics to shadow result set as RDF operations in ResultSetFormatter and ResultSetFactory. > 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] [Commented] (JENA-882) Index support for ordered ResultSet
[ https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327428#comment-14327428 ] ASF subversion and git services commented on JENA-882: -- Commit abf8809dd6ada4cc7bf34ac7b421ca5b444cd189 in jena's branch refs/heads/master from [~andy.seaborne] [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=abf8809 ] JENA-882 : Deprecate result set as RDF operations > 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] [Commented] (JENA-882) Index support for ordered ResultSet
[ https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327420#comment-14327420 ] Andy Seaborne commented on JENA-882: Generally, pull requests or patches are easier but here, as we have been having this discussion, I already have changes in my dev copy of jena. > 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] [Commented] (JENA-882) Index support for ordered ResultSet
[ https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327409#comment-14327409 ] Magnus Knuth commented on JENA-882: --- Sure, that is totally fine, since ResultSetFormatter is made for output formats of SELECT and ASK query results and RDF does not seem to be standardized for this. Btw there is a duplicate for JSON in output(): https://github.com/apache/jena/blob/bc37348521aa016a4481dea74ed884d720001920/jena-arq/src/main/java/com/hp/hpl/jena/query/ResultSetFormatter.java#L379 Just thinking, do you prefer pull requests instead of discussing this here? > 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] [Resolved] (JENA-878) Avoid dependencies on xerces.impl
[
https://issues.apache.org/jira/browse/JENA-878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne resolved JENA-878.
Resolution: Done
Fix Version/s: Jena 2.13.0
Assignee: Andy Seaborne
Pull request #31 + some tidying up in passing.
> 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
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 2.13.0
>
>
> 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)
[jira] [Commented] (JENA-882) Index support for ordered ResultSet
[
https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327366#comment-14327366
]
Andy Seaborne commented on JENA-882:
That's reasonable if done on RDFOutput.
How about also moving the RDF format out of the top level public convenience
operations in {{ResultSetFormatter}} and {{ResultSetFactory}}? Different people
are, quite reasonably, confused about these operations, e.g. underatdnign them
as return all the RDF touched by the query.
"moving" means leaving deprecated operations in {{ResultSetFormatter}} and
{{ResultSetFactory}} so a not to break user code.
> 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] [Comment Edited] (JENA-882) Index support for ordered ResultSet
[
https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327347#comment-14327347
]
Andy Seaborne edited comment on JENA-882 at 2/19/15 12:35 PM:
--
Alright, thanks for the clarification.
I wanted to use RDF for serialization (RDFOutput) and de-serialization
(RDFInput) of a SPARQL Result Set. That works fine for unordered sets. Couldn't
the index field be serialized optionally?
Suggestion:
{noformat}
public Resource asRDF(Model model, ResultSet resultSet) { return asRDF(model,
resultSet, false); }
public Resource asRDF(Model model, ResultSet resultSet, boolean sorted) { ... }
{noformat}
was (Author: mgns):
Alright, thanks for the clarification.
I wanted to use RDF for serialization (RDFOutput) and de-serialization
(RDFInput) of a SPARQL Result Set. That works fine for unordered sets. Couldn't
the index field be serialized optionally?
Suggestion:
{noformat}
public Resource asRDF(Model model, ResultSet resultSet) \{ return asRDF(model,
resultSet, false); \}
public Resource asRDF(Model model, ResultSet resultSet, boolean sorted) \{ ...
\}
{noformat}
> 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] [Comment Edited] (JENA-882) Index support for ordered ResultSet
[
https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327347#comment-14327347
]
Andy Seaborne edited comment on JENA-882 at 2/19/15 12:34 PM:
--
Alright, thanks for the clarification.
I wanted to use RDF for serialization (RDFOutput) and de-serialization
(RDFInput) of a SPARQL Result Set. That works fine for unordered sets. Couldn't
the index field be serialized optionally?
Suggestion:
{noformat}
public Resource asRDF(Model model, ResultSet resultSet) \{ return asRDF(model,
resultSet, false); \}
public Resource asRDF(Model model, ResultSet resultSet, boolean sorted) \{ ...
\}
{noformat}
was (Author: mgns):
Alright, thanks for the clarification.
I wanted to use RDF for serialization (RDFOutput) and de-serialization
(RDFInput) of a SPARQL Result Set. That works fine for unordered sets. Couldn't
the index field be serialized optionally?
Suggestion:
public Resource asRDF(Model model, ResultSet resultSet) { return asRDF(model,
resultSet, false); }
public Resource asRDF(Model model, ResultSet resultSet, boolean sorted) { ... }
> 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] [Commented] (JENA-882) Index support for ordered ResultSet
[
https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327347#comment-14327347
]
Magnus Knuth commented on JENA-882:
---
Alright, thanks for the clarification.
I wanted to use RDF for serialization (RDFOutput) and de-serialization
(RDFInput) of a SPARQL Result Set. That works fine for unordered sets. Couldn't
the index field be serialized optionally?
Suggestion:
public Resource asRDF(Model model, ResultSet resultSet) { return asRDF(model,
resultSet, false); }
public Resource asRDF(Model model, ResultSet resultSet, boolean sorted) { ... }
> 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] [Commented] (JENA-882) Index support for ordered ResultSet
[ https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327346#comment-14327346 ] Andy Seaborne commented on JENA-882: Propose to close "not a problem"/"won't fix" > 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] [Commented] (JENA-882) Index support for ordered ResultSet
[
https://issues.apache.org/jira/browse/JENA-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327334#comment-14327334
]
Andy Seaborne commented on JENA-882:
When the first SPARQL working group started, the idea was that turning result
sets into graphs and comparing graphs would be the way to do testing. Coupled
with the fact that SPARQL results sets were marked as to whether they are
ordered or not by an attribute in the XML. That feature was removed well
before the SPARQL 1.0 standard was published. (There was also a "results
distinct" flag at the same time.)
The "result set marked sorted" has problems: often the results are only
strictly partially sorted, e.g. {{SELECT ?x ?y \{ . . . \} ORDER BY(?x)}}. That
may well be totally sorted, or at least totally stable, if the data happens to
have one unique {{?y}} for each {{?x}} but from the query alone, you can't tell
that.
So the feature was removed. From just a result set, you can't tell if it is
sorted or not.
The testing has to be done by "result set" comnparision, not turning into
graphs. This was also a reaction from developers that graph isomorphism was
too great a burden for a SPARQL implementation to pass conformance tests. See
{{ResultSetCompare}} - you have to tell it to compare by order.
If indexes were to be added, then two equivalent result sets can generate RDF
graphs. Worse, the order of results in ARQ is not guaranetted without ORDER BY
in the query. While ARQ is very deterministic, the order can change, and may
well change across different versions. When used as test results with indexes,
the test would fail due reordering.
The result set to RDF is a relic and remains as a historical feature. Over
time, a small, but steady stream of people ask about it so removing it would
inconvenience them.
> 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] [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=14327268#comment-14327268
]
ASF GitHub Bot commented on JENA-878:
-
Github user asfgit closed the pull request at:
https://github.com/apache/jena/pull/31
> 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)
[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=14327269#comment-14327269
]
ASF GitHub Bot commented on JENA-878:
-
Github user asfgit closed the pull request at:
https://github.com/apache/jena/pull/30
> 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)
[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=14327267#comment-14327267
]
ASF subversion and git services commented on JENA-878:
--
Commit 1072c02f0c31032cee9dbec8c07522925f3d210b in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=1072c02 ]
JENA-878 : Hide stuff from OSGi.
Remove getHashCode (use Arrays.hashCode directly)
Tidy code.
This closes #31
This closes #30
> 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: Explicit imports of org.apache.xerces...
Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/30 --- 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: JENA-878 Avoid exposing xerces.impl.dv
Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/31 --- 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=14327258#comment-14327258
]
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_r24980025
--- Diff:
jena-core/src/main/java/com/hp/hpl/jena/datatypes/xsd/XSDDatatype.java ---
@@ -251,7 +269,7 @@ public XSDDatatype(String typeName, Class javaClass)
{
* @param xstype the XSSimpleType definition to be wrapped
* @param namespace the namespace for the type (used because the
grammar loading doesn't seem to keep that)
*/
-public XSDDatatype(XSSimpleType xstype, String namespace) {
+XSDDatatype(XSSimpleType xstype, String namespace) {
--- End diff --
Jena provides all the meaningful XSD types (just some XML specific types
are missing) so it is unlikely that external code is calling this public
constructor. Howver, it is public. If the aim is to hide Xerces XSSimpleType,
then hop
about:
1. Make this protected.
2. Add `public XSDDatatype(Object xstype, String namespace)` and cast to
`XSSimpleType`
I thhnk that will keep OSGi happy(ier).
> 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_r24980025
--- Diff:
jena-core/src/main/java/com/hp/hpl/jena/datatypes/xsd/XSDDatatype.java ---
@@ -251,7 +269,7 @@ public XSDDatatype(String typeName, Class javaClass)
{
* @param xstype the XSSimpleType definition to be wrapped
* @param namespace the namespace for the type (used because the
grammar loading doesn't seem to keep that)
*/
-public XSDDatatype(XSSimpleType xstype, String namespace) {
+XSDDatatype(XSSimpleType xstype, String namespace) {
--- End diff --
Jena provides all the meaningful XSD types (just some XML specific types
are missing) so it is unlikely that external code is calling this public
constructor. Howver, it is public. If the aim is to hide Xerces XSSimpleType,
then hop
about:
1. Make this protected.
2. Add `public XSDDatatype(Object xstype, String namespace)` and cast to
`XSSimpleType`
I thhnk that will keep OSGi happy(ier).
---
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.
---
