SOLVED Re: Consuming JSON-LD?

[Phillip Rhodes <mo...@gmail.com>]

Andy, that works now, using the StringReader.  Thank you very much
for the rapid reaction to this.  It is greatly appreciated.

I will revisit reworking this to use an InputStream eventually, due to the
character encoding issues, but this helps me get a prototype out
quickly, given that
Groovy's RestClient gives me back a String instance when I request JSON, and the
most obvious way to bridge that into jena (when I first started
looking) appeared to be
using the StringReader.  I guess I could have turned that into a
ByteArrayInputStream
had a I realized what was going on sooner.  Oh well, live and learn.

Thanks again for the help, and - more generally - for all your work on Jena.


Phil


On Fri, Nov 15, 2013 at 8:42 AM, Phillip Rhodes
<mo...@gmail.com> wrote:
> Ah, OK.   I'll give that a try then.  Thanks for the heads-up.
>
>
> Phil
> This message optimized for indexing by NSA PRISM
>
>
> On Fri, Nov 15, 2013 at 4:01 AM, Andy Seaborne <an...@apache.org> wrote:
>> On 15/11/13 05:59, Phillip Rhodes wrote:
>>>
>>> FWIW... I just grabbed the Jena source, imported it into my workspace
>>> and set my project to reference that, so I could debug into this as
>>> it's running. What I see is the code getting to line 864 in RDFDataMgr
>>> and executing this code:
>>>
>>> parser = RiotReader.createParser(tokenizer, lang, base, output) ;
>>>
>>> which returns null.  The next line tries to use the null reference,
>>> and hence the NPE.
>>>
>>> Looking at RiotReader.createParser(), I don't see anything in there
>>> that mentions JSON-LD at all.    But the docs for java-jsonld say
>>> something like:
>>>
>>> "JenaJSONLD must be initialized so that the readers and writers are
>>> registered with Jena."  and I do call the init() method.  But I don't
>>> see how that registration process plays with this createParser() code.
>>>
>>> I'm guessing things have just gotten out of sync between Jena and the
>>> JSON-LD stuff?
>>
>>
>> The problem is reading from a reader (I should have noticed this earlier in
>> the thread).
>>
>> If you use an InputStream it will work (= it does for me).
>>
>> Readers are troublesome because they fix the charset before Jena gets a
>> chance set the encodign according to syntax.  A FileReader is particularly
>> troublesome because it fixes the charset as the system default so if that is
>> not UTF-8 (and it isn't on Windows) it will not be UTF-8.
>>
>> StringReader is only usecase but it currently follows a hardwired path
>> inside RDFDataMgr.  The general ReaderRIOT interface does not have Readers.
>>
>> Regrettably, I think I'll have to go and add Readers to ReaderRIOT (it only
>> results in parallel code - InputStream and Reader have no commonality) just
>> because of StringReader.
>>
>> You should be able to pass the input stream from HTTP request to the
>> RDFDataMgr or model.read directly.
>>
>>         Andy
>>
>>> Phil
>>
>>

Re: SOLVED Re: Consuming JSON-LD?

[Phillip Rhodes <mo...@gmail.com>]

This message optimized for indexing by NSA PRISM


On Mon, Nov 18, 2013 at 12:58 PM, Andy Seaborne <an...@apache.org> wrote:
> Glad you got it working - emails with "SOLVED" in the title are always nice
> to see!

I can totally relate to that.  Thanks again for the help!

>
> Presumably, you are a snapshot build of Jena.

Yes, and also jena-jsonld.  The only thing that threw me for a minute,
was that I'd been playing with a snapshot "from source" build of
jsonld-java as well, only to eventually discover that I needed to roll
that back to 0.2 for everything to work.


> Readers should all work now
> and if your HTTP library messes up the reader from the HTTP response
> charset I'd be very surprised but it does presume that the response is
> complete and valid. HTTP has too many moving parts with "some
> assembly
> required".

Right now we're using the Groovy RESTClient to talk to Apache Stanbol
and everything seems to work just fine with the Reader approach.  In a
lot of ways, we're only trying to prototype some functionality right
now anyway, so if all the corner cases aren't handled, it's not the
end of the world.   We mainly just want to show people the cool things
you can do by running content through Stanbol, enhancing it, and then
storing the triples in a triplestore to enable 'semantic' queries.

That said, if anybody is interested in seeing the projects we're
working on, it's all Open Source and also ALv2 licensed.   I'll post a
separate email about that, by way of introduction, in case anyone is
interested in seeing how we're using Jena.


Phil

Re: SOLVED Re: Consuming JSON-LD?

[Andy Seaborne <an...@apache.org>]

Hi Phil,

Glad you got it working - emails with "SOLVED" in the title are always 
nice to see!

Presumably, you are a snapshot build of Jena.  Readers should all work 
now and if your HTTP library messes up the reader from the HTTP response 
inc charset I'd be very surprised but it does presume that the response 
is complete and valid. HTTP has too many moving parts with "some 
assembly required".

	Andy

On 16/11/13 01:15, Phillip Rhodes wrote:
> Andy, that works now, using the StringReader.  Thank you very much
> for the rapid reaction to this.  It is greatly appreciated.
>
> I will revisit reworking this to use an InputStream eventually, due to the
> character encoding issues, but this helps me get a prototype out
> quickly, given that
> Groovy's RestClient gives me back a String instance when I request JSON, and the
> most obvious way to bridge that into jena (when I first started
> looking) appeared to be
> using the StringReader.  I guess I could have turned that into a
> ByteArrayInputStream
> had a I realized what was going on sooner.  Oh well, live and learn.
>
> Thanks again for the help, and - more generally - for all your work on Jena.
>
>
> Phil
>
>
> On Fri, Nov 15, 2013 at 8:42 AM, Phillip Rhodes
> <mo...@gmail.com> wrote:
>> Ah, OK.   I'll give that a try then.  Thanks for the heads-up.
>>
>>
>> Phil
>> This message optimized for indexing by NSA PRISM
>>
>>
>> On Fri, Nov 15, 2013 at 4:01 AM, Andy Seaborne <an...@apache.org> wrote:
>>> On 15/11/13 05:59, Phillip Rhodes wrote:
>>>>
>>>> FWIW... I just grabbed the Jena source, imported it into my workspace
>>>> and set my project to reference that, so I could debug into this as
>>>> it's running. What I see is the code getting to line 864 in RDFDataMgr
>>>> and executing this code:
>>>>
>>>> parser = RiotReader.createParser(tokenizer, lang, base, output) ;
>>>>
>>>> which returns null.  The next line tries to use the null reference,
>>>> and hence the NPE.
>>>>
>>>> Looking at RiotReader.createParser(), I don't see anything in there
>>>> that mentions JSON-LD at all.    But the docs for java-jsonld say
>>>> something like:
>>>>
>>>> "JenaJSONLD must be initialized so that the readers and writers are
>>>> registered with Jena."  and I do call the init() method.  But I don't
>>>> see how that registration process plays with this createParser() code.
>>>>
>>>> I'm guessing things have just gotten out of sync between Jena and the
>>>> JSON-LD stuff?
>>>
>>>
>>> The problem is reading from a reader (I should have noticed this earlier in
>>> the thread).
>>>
>>> If you use an InputStream it will work (= it does for me).
>>>
>>> Readers are troublesome because they fix the charset before Jena gets a
>>> chance set the encodign according to syntax.  A FileReader is particularly
>>> troublesome because it fixes the charset as the system default so if that is
>>> not UTF-8 (and it isn't on Windows) it will not be UTF-8.
>>>
>>> StringReader is only usecase but it currently follows a hardwired path
>>> inside RDFDataMgr.  The general ReaderRIOT interface does not have Readers.
>>>
>>> Regrettably, I think I'll have to go and add Readers to ReaderRIOT (it only
>>> results in parallel code - InputStream and Reader have no commonality) just
>>> because of StringReader.
>>>
>>> You should be able to pass the input stream from HTTP request to the
>>> RDFDataMgr or model.read directly.
>>>
>>>          Andy
>>>
>>>> Phil
>>>
>>>