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
