[
https://issues.apache.org/jira/browse/JENA-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281988#comment-16281988
]
ASF GitHub Bot commented on JENA-1430:
--------------------------------------
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/314
Ouch! I realize I wasn't clear enough at all in my last comment: I was
actually -1 on this. I think the confusion that `ja:data` now has in its
semantics is too much, and I completely disagree with:
> We can't change the predicates due to existing deployed assemblers
We change the public API when we must, we just do it carefully and after
clear depreciation with a clear migration path. What's more, the docs have been
wrong about the assembler type for TIM for a year or more, so I don't think
there will be users waiting with pitchforks and torches!
I'd like to either revert this merge or add a further commit adding the use
of `ja:graph` to TIM's assembler (just like the general dataset assembler) and
depreciating the use of `ja:data` for anything but quads with the expectation
that we will disallow it in a near-future version. I can do that after a
release, if that is easier.
> Quad loading for in-memory assemblers
> -------------------------------------
>
> Key: JENA-1430
> URL: https://issues.apache.org/jira/browse/JENA-1430
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Reporter: A. Soroka
> Assignee: A. Soroka
> Fix For: Jena 3.6.0
>
>
> In-memory dataset Assemblers should support loading quad files.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
