[
https://issues.apache.org/jira/browse/JENA-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16370005#comment-16370005
]
A. Soroka commented on JENA-1490:
---------------------------------
Yes, but my experiences are uninteresting. Small transactions against various
triplestores, mostly Fuseki, all straightforward and without relevant problems
from which we could learn anything. I guess I'm just not doing weird enough
stuff with RDF these days. :)
Other SPARQL Query protocol impls also may have other (or extensible)
endpoints, so it might make sense to try to design this as an add-on mechanism
instead of subclasses that are server-specific. I admit that doing a good
extension design is usually harder, but in this case it might be pretty
simple-- something like a marker interface for extension operation classes and
then some kind of method that makes such things available from
{{RDFConnection}} depending on how the client built that {{RDFConnection}}
instance. E.g. something like
{code:java}
Context context = ... // configures extensions
RDFConnection conn = RDFConnectionFactory.connect("http://endpoint";, context);
MyExtension ext = conn.getExtension(MyExtension.class);
ext.doSomethingCoolAgainstTheServer(with, some, data);
{code}
Or for our use case:
{code:java}
Context connectionContext = new Context();
context.set(PreserveBlankNodesSymbol, true);
RDFConnection conn = RDFConnectionFactory.connect("http://endpoint";, context);
{code}
but maybe better not to reuse {{Context}}, maybe better to have a fresh type.
Do you see what I'm getting at? The idea would be that for something like Graph
Store protocol, which many triplestores impl, we could potentially reuse parts,
and if (a consummation devoutly to be wished) triplestores ever converge on
protocols for some of these "beyond SPARQL" functions, we are positioned to
work with that easily.
> Working with Blank Nodes with Fuseki
> ------------------------------------
>
> Key: JENA-1490
> URL: https://issues.apache.org/jira/browse/JENA-1490
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
> Affects Versions: Jena 3.6.0
> Reporter: Andy Seaborne
> Assignee: Andy Seaborne
> Priority: Major
>
> Be able to work with blank nodes between client and Fuseki server.
> This ticket is mainly about pulling together existing mechanisms.
> This would be a new {{RDFConnectionFactory}} function to return a
> {{RDFConnection}} with the right settings for presevring blank node id.
> Having a new {{RDFConnectionFuseki}}, subclass of {{RDFConnectionRemote}}, to
> handle the right settings and not simply option for {{RDFConnectionRemote}},
> because it is than a place for future Fuseki-specific operations.
>
> When working with a Fuseki remote:
> * Use RDF Thrift (RDF and Result set forms) for efficiency
> * Preserve blank node ids.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
