On 28/03/17 22:05, Andrew U Frank wrote:
i found that encoding the literals in the requests as latin1 i do not
see errors and the triples are stored.
is this intended behaviour? for now, i have a work around.
i look forward to your analysis of the code? when i look at the java
error message,
thank you for the hints - i use haskell and assume that between the
strings which i see and what is sent 'on the wire' is converted. i am
not familiar with your comment about the difference between utf8
encoding and utf8 on the wire. in the material that you pointed to i do
not see such a conversio
i found that encoding the literals in the requests as latin1 i do not
see errors and the triples are stored.
is this intended behaviour? for now, i have a work around.
i look forward to your analysis of the code? when i look at the java
error message, i sense that there is a encoding selected? is
On 28/03/17 21:35, Andrew U Frank wrote:
the problem/bug is not related to the BOM character but seemingly to
many UTF-8.
i get (consistently) a return code of 204 when the fuseki server is
running without -v and 500 when running with -v if any of the literatls
contains a "strange" (nonASCII?)
the problem/bug is not related to the BOM character but seemingly to
many UTF-8.
i get (consistently) a return code of 204 when the fuseki server is
running without -v and 500 when running with -v if any of the literatls
contains a "strange" (nonASCII?) UTF-8. the current problem is the
character
Recorded as JENA-1312, with a test case.
The difference between -v and no -v is that the verbose logging code
uses java to convert bytes to chars, while the non-verbose path uses javacc.
Andy
On 28/03/17 15:23, Andrew U Frank wrote:
the server was started with
exec /home/frank/jena/apac
the server was started with
exec /home/frank/jena/apache-jena-fuseki-2.5.0/fuseki-server -v --update
--loc=/home/frank/march19 /marchDB
and then with
exec /home/frank/jena/apache-jena-fuseki-2.5.0/fuseki-server --update
--mem /memDB
(first with -v and got the error message, then i removed the
What storage is the Fuseki server using? I can't reproduce the restart
effect.
The BOM is not 65257 (bytes xFE xFF) in a SPARQL Update request, it's
bytes xEF xBB xBF.
We are talking about what is on-the-wire which means UTF-8 encoded
unicode and codepoint 65257, U+FEFF is 3 bytes in UTF-8
I _think_ these could actually be "correctly inconsistent", although not
necessarily in the way they are now. :grin:
Some of them are endpoints for collections of things, e.g. /$/datasets/, but
some are not, e.g. /$/server. There is no /$/server/ because there is no
collection of servers. But t
thank you for your information. starting fuseki with -v gives indeed
more information. in this case i get
[2017-03-28 12:45:07] Fuseki INFO [49] POST
http://127.0.0.1:3030/memDB/update
[2017-03-28 12:45:07] Fuseki INFO [49] => Connection: close
[2017-03-28 12:45:07] Fuseki
Ack. Turned off the computer. Let me try them and re-read that page with more
calm tomorrow.
If you have any other suggestions for that page let me knoe. Like add / remove
sections, re-word, clarify, etc.
ThanksBruno
Sent from Yahoo Mail on Android
On Tue, Mar 28, 2017 at 23:16, Sweeney, Ch
Hi Bruno,
Spelling is correct and consistent now. Still showing the trailing slash.
That gives a 404 on Fusei 2.4.1 at least.
There's an inconsistency here:
/$/datasets and /$/datasets/ both work.
/$/stats and /$/stats/ both work.
/$/tasks and /$/tasks/ both work.
/$/server works and /$/server
Hi Chris,
You are correct. The correct link is /$/backups-list
(https://github.com/apache/jena/blob/347d7764dc9132e182e5f8c12de99c3c20938ce8/jena-fuseki2/jena-fuseki-core/src/main/webapp/WEB-INF/web.xml#L177)
Fixed in SVN. Will be updated once the site is published. You can check the
current st
> Claude Warren (one of the Jena committers) has been working on an Apache
> Cassandra backend, and he can say more about it if it seems relevant.
Is this Apache Cassandra backend "like TDB, but scalable?"
I there any repository on github for Apache Cassandra backend?
2017-03-26 21:55 GMT+03:00 A. Soroka :
> TDB is a native store, with a next generation version in development [1].
> SDB uses a SQL backend. It is not under active development. Claude Warren
> (one of the Jena committers) has been wor
> Not currently with TDB but i have code in production which aggregates
> across multiple DatasetGraph's. We create a DatasetGraphMosaic and add
> DatasetGraph's to it. TDB in other JVM's are supported via a Thrift based
> proxy. This allows simple sparql, otherwise use the service command in your
16 matches
Mail list logo