Sure, but you get that if you produce RDF/XML or TriX. I've tried that
and transformed JSON directly into TriX with Saxon.
On Thu, Nov 29, 2018 at 4:41 PM Marco Neumann <[email protected]> wrote:
>
> thanks for the link Martynas, one still has to go to rdf from xml. I find
> the data assembler in jena/d2rq more convenient but am open to new ideas.
>
> btw I never quite know who is posting on ajs6f hence the misnomer
>
> On Thu 29. Nov 2018 at 14:29, Martynas Jusevičius <[email protected]>
> wrote:
>
> > Marco,
> >
> > FYI XSLT 3.0 supports JSON transformations:
> > https://www.w3.org/TR/xslt-30/#json
> >
> > Martynas
> > On Thu, Nov 29, 2018 at 2:27 PM Marco Neumann <[email protected]>
> > wrote:
> > >
> > > good to know that we are on the same page here Adam. With regards to json
> > > let's limit the scope of the discussion here to the Jena project for
> > now. I
> > > am not looking at an alternative to JSON-LD, correct my if I am wrong but
> > > as far as my limited understanding of JSON-LD goes it is a way to
> > > store/serialize RDF like data in a json format. while my use case would
> > be
> > > a customer that presents any data in json and wants me to read this into
> > a
> > > sparql endpoint for further inspection (with bnodes for arrays, warts and
> > > all). Currently I have to programmatically write transformations to allow
> > > me to read the data into a Jena store. Can JSON-LD already help me with
> > > this task?
> > >
> > >
> > >
> > > On Thu, Nov 29, 2018 at 12:47 PM ajs6f <[email protected]> wrote:
> > >
> > > > I agree _very heartily_ with the caution that Andy and Marco are
> > > > expressing. I've been following the conversation on
> > [email protected]
> > > > and I have yet to hear anything that seems very useful or practical to
> > me.
> > > >
> > > > That having been said, and speaking very much as a member of W3C's
> > JSON-LD
> > > > Working Group, I'm also not ecstatic about setting up an alternative to
> > > > JSON-LD. Perhaps you could say a little about why it's not a good
> > choice
> > > > for data access? I would hope that you would be able to equip your
> > generic
> > > > JSON with a JSON-LD context and roll on without any special new Jena
> > > > tooling needed... is that not possible (or optimal) for some reason? If
> > > > it's related to Jena, we can talk about it here, and if it's related to
> > > > JSON-LD, I'd be very happy to take your concern to the WG.
> > > >
> > > > ajs6f
> > > >
> > > > > On Nov 29, 2018, at 7:40 AM, Marco Neumann <[email protected]>
> > > > wrote:
> > > > >
> > > > > I agree Andy, there is no need to rush things here and break the API.
> > > > Maybe
> > > > > we could provide an in memory model for "Generalized RDF" as sandbox
> > for
> > > > > people to play with. But what I'd like to see are more bridges to the
> > > > json
> > > > > community as it has become the defacto lingua franca for data
> > exchange on
> > > > > the web now.
> > > > >
> > > > > In particular with regards to generic json rather than json-ld.
> > possibly
> > > > a
> > > > > generic mapping to a json dataset assembler could work for data
> > access
> > > > and
> > > > > transformation. has anybody done anything here already?
> > > > >
> > > > >
> > > > > On Thu, Nov 22, 2018 at 2:11 PM Andy Seaborne <[email protected]>
> > wrote:
> > > > >
> > > > >> Internally, that means Graph/Node/Triple and the ARQ engine, Jena
> > really
> > > > >> works on what is called "Generalized RDF" in RDF 1.1 - so literals
> > as
> > > > >> subjects, literals as predicates blank nodes as predicates - work
> > just
> > > > >> fine. Whether they are a good idea is a different question.
> > > > >>
> > > > >> RDF* works as well (in-memory graphs). Jena has Node_Triple and
> > > > >> Node_Graph nowadays for completeness.
> > > > >>
> > > > >> If we get into structured values (lists not encoded in triples,
> > > > >> sets/bags as datastructures - and these are things property graphs
> > and
> > > > >> traditionally SQL also find it hard to handle), there would be work
> > to
> > > > >> do, but it's not impossible.
> > > > >>
> > > > >> The impact is on the Model API is where the impact is.
> > > > >>
> > > > >> Personal opinion about changing the core specs:
> > > > >>
> > > > >> Being "better"isn't enough. There is lots of investment in people's
> > > > >> time and energy has gone in to learning about RDF and communicating
> > > > >> about RDF.
> > > > >>
> > > > >> The impact is when new data meets old apps but also existing
> > > > >> thinking/learning/blogs/books/...
> > > > >>
> > > > >> Changes to the basics need to meet a higher barrier than "better".
> > > > >>
> > > > >> Andy
> > > > >>
> > > > >> On 22/11/2018 13:13, Marco Neumann wrote:
> > > > >>> are we prepared in Jena for such a move on the RDF syntax?
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> ---------- Forwarded message ---------
> > > > >>> From: Tim Berners-Lee <[email protected]>
> > > > >>> Date: Thu, Nov 22, 2018 at 1:05 PM
> > > > >>> Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
> > > > >>> To: David Booth <[email protected]>
> > > > >>> Cc: SW-forum Web <[email protected]>, Dan Brickley <
> > > > [email protected]
> > > > >>> ,
> > > > >>> Sean B. Palmer <[email protected]>, Olaf Hartig <
> > [email protected]
> > > > >,
> > > > >>> Axel Polleres <[email protected]>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On 2018-11 -21, at 22:40, David Booth <[email protected]> wrote:
> > > > >>>
> > > > >>> 7. Literals as subjects. RDF should allow "anyone to say
> > > > >>> anything about anything", but RDF does not currently allow
> > > > >>> literals as subjects! (One work-around is to use -- you guessed
> > > > >>> it -- a blank node, which in turn is asserted to be owl:sameAs
> > > > >>> the literal.) This deficiency may seem unimportant relative
> > > > >>> to other RDF difficulties, but it is a peculiar anomaly that
> > > > >>> may have greater impact than we realize. Imagine an *average*
> > > > >>> developer, new to RDF, who unknowingly violates this rule and
> > > > >>> is puzzled when it doesn't work. Negative experiences like
> > > > >>> that drive people away. Even more insidiously, imagine this
> > > > >>> developer tries to CONSTRUCT triples using a SPARQL query,
> > > > >>> and some of those triples happen to have literals in the
> > > > >>> subject position. Per the SPARQL standard, those triples will
> > > > >>> be silently eliminated from the results,[13] which could lead
> > > > >>> to silently producing wrong answers from the application --
> > > > >>> the worst of all possible bugs.
> > > > >>>
> > > > >>>
> > > > >>> Agreed.
> > > > >>>
> > > > >>> I thought we had fixed that in some later spec but I guess not.
> > > > >>>
> > > > >>> All code I have written, like cwm and rdflib.js, allows the same
> > things
> > > > >> in
> > > > >>> subject and object positions. Life is too short for arbitrary
> > > > >> unnecessary
> > > > >>> asymmetry.
> > > > >>>
> > > > >>> timbl
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > >
> > > > > ---
> > > > > Marco Neumann
> > > > > KONA
> > > >
> > > >
> > >
> > > --
> > >
> > >
> > > ---
> > > Marco Neumann
> > > KONA
> >
> --
>
>
> ---
> Marco Neumann
> KONA
