Ok so, I was able to look at this in more detail and indeed JSON-LD seems to be the way to go here. I even found some code from an EU project that actually builds a whole pipeline around the ETL process that already works. LinkedPipes ETL quite interesting.
https://etl.linkedpipes.com/tutorials/how-to/map_json_to_rdf On Thu, Nov 29, 2018 at 3:54 PM ajs6f <[email protected]> wrote: > I'm not Martynas, so you didn't misname anyone that I saw. > > JSON-LD can certainly help with this: any time you have JSON, and you wish > it were RDF, JSON-LD is there for you! Whether it's the best choice, only > you can say. Keep in mind that JSON-LD contexts can take JSON and create > triples (or even quads) from properties. That's it. It cannot create > triples that aren't translated directly from a property (except for > rdf:type triples, which are a bit weird). It cannot transform data values. > > You might end up with a two-stage process, in which you first mung your > JSON (as JSON) as need be to clean the data, and then apply a context and > let Jena read the RDF directly. If the data is already in a form that is > close to what you need, the first phase might be short or absent. If the > data is wacky, the gains from introducing JSON-LD might be very small. > > ajs6f > > > On Nov 29, 2018, at 8:27 AM, 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
