I had a similar problem.
When I stored lat long coordinates into a RDF file (32°37'34.57"N for
example), the jena libraries could not load them.
In particular when I have a process receiving data or scanning data on
other sites or endpoints, I thought that XML would complain about xml
delimiters only.
What would be the best strategies in populating a RDF graph store?
What kind of filtering should be done?
On Fri, Apr 27, 2012 at 9:04 AM, Andy Seaborne <a...@apache.org> wrote:
> What is the remote query service? is it dbpedia by any chance?
>
> A similar problem was reported quite recently.
>
> If it's a Fuseki endpoint, you can force the output format with
> "&output=json" but that's non-standard.
>
> Andy
>
>
> On 27/04/12 10:21, Damian Steer wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 27/04/12 09:56, Ziya Akar wrote:
>>>
>>> Hi,
>>
>>
>> Hi Ziya,
>>
>>> i have a problem when querying a remote dataset and my execution is
>>> interrupted.
>>>
>>> com.ctc.wstx.exc.WstxUnexpectedCharException: Illegal character
>>> ((CTRL-CHAR, code 7)) at [row,col {unknown-source}]: [61661,133] at
>>> com.ctc.wstx.sr.StreamScanner.throwInvalidSpace(StreamScanner.java:675)
>>
>>
>> Ugh.
>>
>> Certain
>>>
>>>
>> characters are illegal in XML, and simply can't be written.
>> Your remote dataset contains such a character unfortunately, so some
>> results can't be transferred over the network in the standard way
>> (that is sparql xml result format).
>>
>>> How can i handle this problem?
>>
>>
>> The remote data is probably broken (these characters are typically
>> useless), so report the issue to the upstream provider. Their server
>> is also producing broken XML, and ought to be fixed (although this
>> wouldn't help you, it would just produce a 500 error).
>>
>> You could try asking for an alternate result serialisation like JSON.
>> I don't think there's a convenient way to do that via the query
>> execution factory (?), so you'd need to write more code (although we
>> can help, of course).
>>
>> You could also try filtering the bad characters out pre-xml
>> processing. Once again, more work I'm afraid.
>>
>> Damian
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk+aZSsACgkQAyLCB+mTtymDiACggsbxtdhaifaWOmky9tnl9S6Z
>> +O8AnA/D0knRRj3IFNNuWF0otrAT3n6N
>> =NIk9
>> -----END PGP SIGNATURE-----
>
>
