Re: RDF 1.1 -- changes to plain literals
On 14/10/13 09:11, Rob Vesse wrote: Andy Thanks for the great overview, I've been looking at supporting this on dotNetRDF as well lately so have been thinking much along the same lines. I think the check language first needs to be emphasized in messaging to users about this change, dotNetRDF has the same issue and I've seen recently that Sesame was also affected by this. Therefore I think we need to be clear about the need for this change in usage. My feeling is we should make this a configurable behavior, the default going forward should be RDF 1.1 but it would be nice if users could toggle that back to RDF-2004 behaviors if they need to produce data for older systems. Some way of reverting to old behaviour would be good. As long as it's system-wide I don't foresee any problems. On a per graph basis would be very hard; on a per parser run is possible but does not catch API created data. Once data has passed through in RDF 1.1 mode and written to file, whether database or syntax written to disk, it gets confusing to mix-and-match and go back to RDF-2004 style. There is reasonable need for some compatibility style, then, yes, let's put it in. One thing I think is worth avoiding is too much speculatively compatibility (i.e. guessing!), like putting in all variations of Node creation into NodeFactory as different factory methods. These tend to end up with a life beyond the transition. On the database side particularly for TDB would it be feasible to produce a migration utility which would check a database to see if it is affected and if so produce a migrated version of the database? Backup to N-Quads in RDF-2004 style, update software and restore in RDF 1.1 style will work and it will leave a backup should the deployment wish to reverse the process. A special utility to convert TDB databases would be possible by looking in the node table for explicit xsd:strings, then looking in the indexes for the internal value of term and changing it (delete-add). Doing a backup first is a good thing (tm) at that point anyway. It would be an offline process as it is munging the internal tables directly. A transactional version is also doable but each layer of complexity increases the risk of getting it wrong in some corner case. A special utility has the disadvantage of not being well-used so at risk of bugs. So, currently, I would want to see a significant need for this before embarking on something other than backup-upgrade-restore. Andy Rob
[jira] [Commented] (JENA-555) Deprecate StageGenerators prior to removal.
[
https://issues.apache.org/jira/browse/JENA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794146#comment-13794146
]
Andy Seaborne commented on JENA-555:
The call to {{QC.setFactory}} in {{TDB.wireIntoExecution}} should have been
unnecessary. It covers up a bug whereby {{StageGeneratorDirectTDB}} is not
adhering to the assumed naming of graphs used by {{SolverLib}} because
{{OpExecutorTDB}} is not used.
Deprecate StageGenerators prior to removal.
---
Key: JENA-555
URL: https://issues.apache.org/jira/browse/JENA-555
Project: Apache Jena
Issue Type: Improvement
Reporter: Andy Seaborne
Assignee: Andy Seaborne
StageGenerators are an old way of extending SPARQL query execution. It is
better to extend OpExecutor (the general purpose algebra execution engine).
OpExecutor calls the generic StageGenerator currently.
# Remove StageGenerator from documentation on extending ARQ.
# Extract the BGP execution into a library.
# OpExecutor to directly call this library unless the context option is set.
# Don't set the global context(key = ARQ.stageGenerator) with a
StageGenerator.
# Mark StageGenerator \@Deprecated
# Update examples
# Check TDB and SDB, esp TDB on single graphs.
Important here is how a graph from one of those storage subsystems, when
places in general purpose dataset with other graph types, still manages to go
to the storage specific BGP execution. (Maybe this does not matter - if it
misses it will fall back to using {{find()}} so always be correct.)
We may been to retain the idea of a StageGenerator to catch the single-graph
case but at least remove as a general extension point in favour of OpExecutor.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (JENA-564) JSON parse errors blocks later use of JSON parser
Andy Seaborne created JENA-564: -- Summary: JSON parse errors blocks later use of JSON parser Key: JENA-564 URL: https://issues.apache.org/jira/browse/JENA-564 Project: Apache Jena Issue Type: Bug Affects Versions: Jena 2.11.0 Reporter: Andy Seaborne Assignee: Andy Seaborne Priority: Minor Fix For: Jena 2.11.1 See http://mail-archives.apache.org/mod_mbox/jena-users/201310.mbox/%3C525B3406.7000302%40knublauch.com%3E -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-564) JSON parse errors blocks later use of JSON parser
[ https://issues.apache.org/jira/browse/JENA-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794171#comment-13794171 ] ASF subversion and git services commented on JENA-564: -- Commit 1531932 from [~andy.seaborne] in branch 'jena/trunk' [ https://svn.apache.org/r1531932 ] JENA-564 JSON parse errors blocks later use of JSON parser - Key: JENA-564 URL: https://issues.apache.org/jira/browse/JENA-564 Project: Apache Jena Issue Type: Bug Affects Versions: Jena 2.11.0 Reporter: Andy Seaborne Assignee: Andy Seaborne Priority: Minor Fix For: Jena 2.11.1 See http://mail-archives.apache.org/mod_mbox/jena-users/201310.mbox/%3C525B3406.7000302%40knublauch.com%3E -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JENA-564) JSON parse errors blocks later use of JSON parser
[ https://issues.apache.org/jira/browse/JENA-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne closed JENA-564. -- JSON parse errors blocks later use of JSON parser - Key: JENA-564 URL: https://issues.apache.org/jira/browse/JENA-564 Project: Apache Jena Issue Type: Bug Affects Versions: Jena 2.11.0 Reporter: Andy Seaborne Assignee: Andy Seaborne Priority: Minor Fix For: Jena 2.11.1 See http://mail-archives.apache.org/mod_mbox/jena-users/201310.mbox/%3C525B3406.7000302%40knublauch.com%3E -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (JENA-564) JSON parse errors blocks later use of JSON parser
[ https://issues.apache.org/jira/browse/JENA-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne resolved JENA-564. Resolution: Fixed JSON parse errors blocks later use of JSON parser - Key: JENA-564 URL: https://issues.apache.org/jira/browse/JENA-564 Project: Apache Jena Issue Type: Bug Affects Versions: Jena 2.11.0 Reporter: Andy Seaborne Assignee: Andy Seaborne Priority: Minor Fix For: Jena 2.11.1 See http://mail-archives.apache.org/mod_mbox/jena-users/201310.mbox/%3C525B3406.7000302%40knublauch.com%3E -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-564) JSON parse errors blocks later use of JSON parser
[ https://issues.apache.org/jira/browse/JENA-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794181#comment-13794181 ] Hudson commented on JENA-564: - SUCCESS: Integrated in Jena_Development_Test #1000 (See [https://builds.apache.org/job/Jena_Development_Test/1000/]) JENA-564 (andy: rev 1531932) * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/io/CharStreamBuffered.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/io/PeekReader.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/json/io/parser/JSONP.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/json/io/parser/JSONParserBase.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/json/io/parser/ParserBase.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/json/io/parser/TokenizerJSON.java JSON parse errors blocks later use of JSON parser - Key: JENA-564 URL: https://issues.apache.org/jira/browse/JENA-564 Project: Apache Jena Issue Type: Bug Affects Versions: Jena 2.11.0 Reporter: Andy Seaborne Assignee: Andy Seaborne Priority: Minor Fix For: Jena 2.11.1 See http://mail-archives.apache.org/mod_mbox/jena-users/201310.mbox/%3C525B3406.7000302%40knublauch.com%3E -- This message was sent by Atlassian JIRA (v6.1#6144)
