I've used xslt transformations in the past and was impressed by the speed and its ability to transform large documents. But in the end I usually reverted back to custom transformations (in code) on the production machine due to quirks in the incoming or outgoing data. Still a generic JSON to RDF template might be a god guidance for future development. As mention earlier I will take a look at the JSON-LD tools to see if we already have something in place here.
On Thu 29 Nov 2018 at 15:58, Martynas Jusevičius <[email protected]> wrote: > 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 > -- --- Marco Neumann KONA
