On 29/11/2018 15:48, ajs6f 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!
This is JSON-LD's strong point.
It is weaker for RDF->JSON, or rather you have to work at it.
Getting nice looking JSON out of RDF via JSON-LD is harder than the mere
pretty printing we have for Turtle and RDF/XML. It's closer to wanting
the output as speific XML schema (something that has come up several
times on StackOverflow in the past 2 weeks). The hard part is "nice
looking JSON" has a strong component of being in the eye of the beholder
once it's past a flat JSON object.
The JSON-LD ecosystem has stuff to help with this but no longer a matter
of a simple "model.write".
Andy
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 <marco.neum...@gmail.com> 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 <aj...@apache.org> wrote:
I agree _very heartily_ with the caution that Andy and Marco are
expressing. I've been following the conversation on semantic-...@w3.org
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 <marco.neum...@gmail.com>
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 <a...@apache.org> 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 <ti...@w3.org>
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
To: David Booth <da...@dbooth.org>
Cc: SW-forum Web <semantic-...@w3.org>, Dan Brickley <
dan...@google.com
,
Sean B. Palmer <s...@miscoranda.com>, Olaf Hartig <olaf.har...@liu.se
,
Axel Polleres <a...@polleres.net>
On 2018-11 -21, at 22:40, David Booth <da...@dbooth.org> 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
