Discussion:
✅ Literals as subjects Re: Toward easier RDF: a proposal
Marco Neumann
2018-11-22 13:13:42 UTC
Permalink
are we prepared in Jena for such a move on the RDF syntax?



---------- Forwarded message ---------
From: Tim Berners-Lee <***@w3.org>
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
To: David Booth <***@dbooth.org>
Cc: SW-forum Web <semantic-***@w3.org>, Dan Brickley <***@google.com>,
Sean B. Palmer <***@miscoranda.com>, Olaf Hartig <***@liu.se>,
Axel Polleres <***@polleres.net>




On 2018-11 -21, at 22:40, David Booth <***@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
Andy Seaborne
2018-11-22 14:11:42 UTC
Permalink
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
Post by Marco Neumann
are we prepared in Jena for such a move on the RDF syntax?
---------- Forwarded message ---------
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
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
2018-11-29 12:40:55 UTC
Permalink
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?
Post by Andy Seaborne
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.
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
Post by Marco Neumann
are we prepared in Jena for such a move on the RDF syntax?
---------- Forwarded message ---------
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
,
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
Post by Marco Neumann
subject and object positions. Life is too short for arbitrary
unnecessary
Post by Marco Neumann
asymmetry.
timbl
--
---
Marco Neumann
KONA
ajs6f
2018-11-29 12:47:46 UTC
Permalink
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
Post by Marco Neumann
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?
Post by Andy Seaborne
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.
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
Post by Marco Neumann
are we prepared in Jena for such a move on the RDF syntax?
---------- Forwarded message ---------
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
,
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
Post by Marco Neumann
subject and object positions. Life is too short for arbitrary
unnecessary
Post by Marco Neumann
asymmetry.
timbl
--
---
Marco Neumann
KONA
Marco Neumann
2018-11-29 13:27:32 UTC
Permalink
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?
Post by ajs6f
I agree _very heartily_ with the caution that Andy and Marco are
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
Post by Marco Neumann
I agree Andy, there is no need to rush things here and break the API.
Maybe
Post by Marco Neumann
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
Post by Marco Neumann
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
Post by Marco Neumann
generic mapping to a json dataset assembler could work for data access
and
Post by Marco Neumann
transformation. has anybody done anything here already?
Post by Andy Seaborne
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.
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
Post by Marco Neumann
are we prepared in Jena for such a move on the RDF syntax?
---------- Forwarded message ---------
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
,
,
Post by Andy Seaborne
Post by Marco Neumann
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
Post by Marco Neumann
subject and object positions. Life is too short for arbitrary
unnecessary
Post by Marco Neumann
asymmetry.
timbl
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
Martynas Jusevičius
2018-11-29 14:28:57 UTC
Permalink
Marco,

FYI XSLT 3.0 supports JSON transformations: https://www.w3.org/TR/xslt-30/#json

Martynas
Post by Marco Neumann
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?
Post by ajs6f
I agree _very heartily_ with the caution that Andy and Marco are
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
Post by Marco Neumann
I agree Andy, there is no need to rush things here and break the API.
Maybe
Post by Marco Neumann
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
Post by Marco Neumann
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
Post by Marco Neumann
generic mapping to a json dataset assembler could work for data access
and
Post by Marco Neumann
transformation. has anybody done anything here already?
Post by Andy Seaborne
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.
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
Post by Marco Neumann
are we prepared in Jena for such a move on the RDF syntax?
---------- Forwarded message ---------
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
,
,
Post by Andy Seaborne
Post by Marco Neumann
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
Post by Marco Neumann
subject and object positions. Life is too short for arbitrary
unnecessary
Post by Marco Neumann
asymmetry.
timbl
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
Marco Neumann
2018-11-29 15:41:41 UTC
Permalink
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
Post by Martynas Jusevičius
Marco,
https://www.w3.org/TR/xslt-30/#json
Martynas
Post by Marco Neumann
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
Post by Marco Neumann
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
Post by Marco Neumann
a customer that presents any data in json and wants me to read this into
a
Post by Marco Neumann
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?
Post by ajs6f
I agree _very heartily_ with the caution that Andy and Marco are
expressing. I've been following the conversation on
and I have yet to hear anything that seems very useful or practical to
me.
Post by Marco Neumann
Post by ajs6f
That having been said, and speaking very much as a member of W3C's
JSON-LD
Post by Marco Neumann
Post by ajs6f
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
Post by Marco Neumann
Post by ajs6f
for data access? I would hope that you would be able to equip your
generic
Post by Marco Neumann
Post by ajs6f
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
Post by Marco Neumann
I agree Andy, there is no need to rush things here and break the API.
Maybe
Post by Marco Neumann
we could provide an in memory model for "Generalized RDF" as sandbox
for
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
people to play with. But what I'd like to see are more bridges to the
json
Post by Marco Neumann
community as it has become the defacto lingua franca for data
exchange on
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
the web now.
In particular with regards to generic json rather than json-ld.
possibly
Post by Marco Neumann
Post by ajs6f
a
Post by Marco Neumann
generic mapping to a json dataset assembler could work for data
access
Post by Marco Neumann
Post by ajs6f
and
Post by Marco Neumann
transformation. has anybody done anything here already?
Post by Andy Seaborne
Internally, that means Graph/Node/Triple and the ARQ engine, Jena
really
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
works on what is called "Generalized RDF" in RDF 1.1 - so literals
as
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
subjects, literals as predicates blank nodes as predicates - work
just
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
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
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
traditionally SQL also find it hard to handle), there would be work
to
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
do, but it's not impossible.
The impact is on the Model API is where the impact is.
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
Post by Marco Neumann
are we prepared in Jena for such a move on the RDF syntax?
---------- Forwarded message ---------
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
,
,
Post by Andy Seaborne
Post by Marco Neumann
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
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
in
Post by Marco Neumann
subject and object positions. Life is too short for arbitrary
unnecessary
Post by Marco Neumann
asymmetry.
timbl
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
Martynas Jusevičius
2018-11-29 15:58:22 UTC
Permalink
Sure, but you get that if you produce RDF/XML or TriX. I've tried that
and transformed JSON directly into TriX with Saxon.
Post by Marco Neumann
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
Post by Martynas Jusevičius
Marco,
https://www.w3.org/TR/xslt-30/#json
Martynas
Post by Marco Neumann
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
Post by Marco Neumann
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
Post by Marco Neumann
a customer that presents any data in json and wants me to read this into
a
Post by Marco Neumann
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?
Post by ajs6f
I agree _very heartily_ with the caution that Andy and Marco are
expressing. I've been following the conversation on
and I have yet to hear anything that seems very useful or practical to
me.
Post by Marco Neumann
Post by ajs6f
That having been said, and speaking very much as a member of W3C's
JSON-LD
Post by Marco Neumann
Post by ajs6f
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
Post by Marco Neumann
Post by ajs6f
for data access? I would hope that you would be able to equip your
generic
Post by Marco Neumann
Post by ajs6f
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
Post by Marco Neumann
I agree Andy, there is no need to rush things here and break the API.
Maybe
Post by Marco Neumann
we could provide an in memory model for "Generalized RDF" as sandbox
for
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
people to play with. But what I'd like to see are more bridges to the
json
Post by Marco Neumann
community as it has become the defacto lingua franca for data
exchange on
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
the web now.
In particular with regards to generic json rather than json-ld.
possibly
Post by Marco Neumann
Post by ajs6f
a
Post by Marco Neumann
generic mapping to a json dataset assembler could work for data
access
Post by Marco Neumann
Post by ajs6f
and
Post by Marco Neumann
transformation. has anybody done anything here already?
Post by Andy Seaborne
Internally, that means Graph/Node/Triple and the ARQ engine, Jena
really
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
works on what is called "Generalized RDF" in RDF 1.1 - so literals
as
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
subjects, literals as predicates blank nodes as predicates - work
just
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
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
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
traditionally SQL also find it hard to handle), there would be work
to
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
do, but it's not impossible.
The impact is on the Model API is where the impact is.
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
Post by Marco Neumann
are we prepared in Jena for such a move on the RDF syntax?
---------- Forwarded message ---------
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
,
,
Post by Andy Seaborne
Post by Marco Neumann
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
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
in
Post by Marco Neumann
subject and object positions. Life is too short for arbitrary
unnecessary
Post by Marco Neumann
asymmetry.
timbl
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
Marco Neumann
2018-11-29 16:31:26 UTC
Permalink
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.
Post by Martynas Jusevičius
Sure, but you get that if you produce RDF/XML or TriX. I've tried that
and transformed JSON directly into TriX with Saxon.
Post by Marco Neumann
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 <
Post by Martynas Jusevičius
Marco,
https://www.w3.org/TR/xslt-30/#json
Martynas
Post by Marco Neumann
good to know that we are on the same page here Adam. With regards to
json
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
let's limit the scope of the discussion here to the Jena project for
now. I
Post by Marco Neumann
am not looking at an alternative to JSON-LD, correct my if I am
wrong but
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
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
Post by Marco Neumann
Post by Martynas Jusevičius
be
Post by Marco Neumann
a customer that presents any data in json and wants me to read this
into
Post by Marco Neumann
Post by Martynas Jusevičius
a
Post by Marco Neumann
sparql endpoint for further inspection (with bnodes for arrays,
warts and
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
all). Currently I have to programmatically write transformations to
allow
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
me to read the data into a Jena store. Can JSON-LD already help me
with
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
this task?
Post by ajs6f
I agree _very heartily_ with the caution that Andy and Marco are
expressing. I've been following the conversation on
and I have yet to hear anything that seems very useful or
practical to
Post by Marco Neumann
Post by Martynas Jusevičius
me.
Post by Marco Neumann
Post by ajs6f
That having been said, and speaking very much as a member of W3C's
JSON-LD
Post by Marco Neumann
Post by ajs6f
Working Group, I'm also not ecstatic about setting up an
alternative to
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
Post by ajs6f
JSON-LD. Perhaps you could say a little about why it's not a good
choice
Post by Marco Neumann
Post by ajs6f
for data access? I would hope that you would be able to equip your
generic
Post by Marco Neumann
Post by ajs6f
JSON with a JSON-LD context and roll on without any special new
Jena
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
Post by ajs6f
tooling needed... is that not possible (or optimal) for some
reason? If
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
Post by ajs6f
it's related to Jena, we can talk about it here, and if it's
related to
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
Post by ajs6f
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 <
I agree Andy, there is no need to rush things here and break the
API.
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
Post by ajs6f
Maybe
we could provide an in memory model for "Generalized RDF" as
sandbox
Post by Marco Neumann
Post by Martynas Jusevičius
for
Post by Marco Neumann
Post by ajs6f
people to play with. But what I'd like to see are more bridges
to the
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
Post by ajs6f
json
community as it has become the defacto lingua franca for data
exchange on
Post by Marco Neumann
Post by ajs6f
the web now.
In particular with regards to generic json rather than json-ld.
possibly
Post by Marco Neumann
Post by ajs6f
a
generic mapping to a json dataset assembler could work for data
access
Post by Marco Neumann
Post by ajs6f
and
transformation. has anybody done anything here already?
Post by Andy Seaborne
Internally, that means Graph/Node/Triple and the ARQ engine,
Jena
Post by Marco Neumann
Post by Martynas Jusevičius
really
Post by Marco Neumann
Post by ajs6f
Post by Andy Seaborne
works on what is called "Generalized RDF" in RDF 1.1 - so
literals
Post by Marco Neumann
Post by Martynas Jusevičius
as
Post by Marco Neumann
Post by ajs6f
Post by Andy Seaborne
subjects, literals as predicates blank nodes as predicates -
work
Post by Marco Neumann
Post by Martynas Jusevičius
just
Post by Marco Neumann
Post by ajs6f
Post by Andy Seaborne
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
Post by Marco Neumann
Post by Martynas Jusevičius
and
Post by Marco Neumann
Post by ajs6f
Post by Andy Seaborne
traditionally SQL also find it hard to handle), there would be
work
Post by Marco Neumann
Post by Martynas Jusevičius
to
Post by Marco Neumann
Post by ajs6f
Post by Andy Seaborne
do, but it's not impossible.
The impact is on the Model API is where the impact is.
Being "better"isn't enough. There is lots of investment in
people's
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
Post by ajs6f
Post by Andy Seaborne
time and energy has gone in to learning about RDF and
communicating
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
Post by ajs6f
Post by Andy Seaborne
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".
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
Post by ajs6f
Post by Andy Seaborne
Andy
Post by Marco Neumann
are we prepared in Jena for such a move on the RDF syntax?
---------- Forwarded message ---------
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a
proposal
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
Post by ajs6f
Post by Andy Seaborne
Post by Marco Neumann
,
,
Post by Andy Seaborne
Post by Marco Neumann
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
Post by Marco Neumann
Post by Martynas Jusevičius
Post by Marco Neumann
Post by ajs6f
Post by Andy Seaborne
Post by Marco Neumann
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
Post by Marco Neumann
Post by Martynas Jusevičius
things
Post by Marco Neumann
Post by ajs6f
Post by Andy Seaborne
in
Post by Marco Neumann
subject and object positions. Life is too short for arbitrary
unnecessary
Post by Marco Neumann
asymmetry.
timbl
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
ajs6f
2018-11-29 15:48:12 UTC
Permalink
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
Post by Marco Neumann
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?
Post by ajs6f
I agree _very heartily_ with the caution that Andy and Marco are
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
Post by Marco Neumann
I agree Andy, there is no need to rush things here and break the API.
Maybe
Post by Marco Neumann
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
Post by Marco Neumann
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
Post by Marco Neumann
generic mapping to a json dataset assembler could work for data access
and
Post by Marco Neumann
transformation. has anybody done anything here already?
Post by Andy Seaborne
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.
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
Post by Marco Neumann
are we prepared in Jena for such a move on the RDF syntax?
---------- Forwarded message ---------
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
,
,
Post by Andy Seaborne
Post by Marco Neumann
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
Post by Marco Neumann
subject and object positions. Life is too short for arbitrary
unnecessary
Post by Marco Neumann
asymmetry.
timbl
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
Marco Neumann
2018-11-29 16:12:53 UTC
Permalink
Ok so I will give it a spin over the weekend to see how it performs and if
it gets me what I want
Post by ajs6f
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
Post by Marco Neumann
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
Post by Marco Neumann
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
Post by Marco Neumann
a customer that presents any data in json and wants me to read this into
a
Post by Marco Neumann
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?
Post by ajs6f
I agree _very heartily_ with the caution that Andy and Marco are
and I have yet to hear anything that seems very useful or practical to
me.
Post by Marco Neumann
Post by ajs6f
That having been said, and speaking very much as a member of W3C's
JSON-LD
Post by Marco Neumann
Post by ajs6f
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
Post by Marco Neumann
Post by ajs6f
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
Post by Marco Neumann
I agree Andy, there is no need to rush things here and break the API.
Maybe
Post by Marco Neumann
we could provide an in memory model for "Generalized RDF" as sandbox
for
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
people to play with. But what I'd like to see are more bridges to the
json
Post by Marco Neumann
community as it has become the defacto lingua franca for data exchange
on
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
the web now.
In particular with regards to generic json rather than json-ld.
possibly
Post by Marco Neumann
Post by ajs6f
a
Post by Marco Neumann
generic mapping to a json dataset assembler could work for data access
and
Post by Marco Neumann
transformation. has anybody done anything here already?
Post by Andy Seaborne
Internally, that means Graph/Node/Triple and the ARQ engine, Jena
really
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
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.
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
Post by Marco Neumann
are we prepared in Jena for such a move on the RDF syntax?
---------- Forwarded message ---------
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
,
,
Post by Andy Seaborne
Post by Marco Neumann
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
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
in
Post by Marco Neumann
subject and object positions. Life is too short for arbitrary
unnecessary
Post by Marco Neumann
asymmetry.
timbl
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
Andy Seaborne
2018-11-30 15:24:17 UTC
Permalink
Post by ajs6f
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
Post by ajs6f
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
Post by Marco Neumann
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?
Post by ajs6f
I agree _very heartily_ with the caution that Andy and Marco are
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
Post by Marco Neumann
I agree Andy, there is no need to rush things here and break the API.
Maybe
Post by Marco Neumann
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
Post by Marco Neumann
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
Post by Marco Neumann
generic mapping to a json dataset assembler could work for data access
and
Post by Marco Neumann
transformation. has anybody done anything here already?
Post by Andy Seaborne
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.
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
Post by Marco Neumann
are we prepared in Jena for such a move on the RDF syntax?
---------- Forwarded message ---------
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
,
,
Post by Andy Seaborne
Post by Marco Neumann
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
Post by Marco Neumann
subject and object positions. Life is too short for arbitrary
unnecessary
Post by Marco Neumann
asymmetry.
timbl
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
ajs6f
2018-12-01 12:51:01 UTC
Permalink
Post by Andy Seaborne
Post by ajs6f
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".
This is true, partly because JSON is inherently tree-ish and some means must be used to get the arbitrarily-shaped RDF graph into that shape. For that reason the stuff to which Andy refers includes JSON-LD Framing [1] which allows you to control the shape of the JSON and supply default values for properties in the JSON that may or may not be filled in by RDF triples for any given instance.

ajs6f

[1] https://w3c.github.io/json-ld-framing/

Marco Neumann
2018-12-01 12:37:50 UTC
Permalink
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
Post by ajs6f
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
Post by Marco Neumann
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
Post by Marco Neumann
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
Post by Marco Neumann
a customer that presents any data in json and wants me to read this into
a
Post by Marco Neumann
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?
Post by ajs6f
I agree _very heartily_ with the caution that Andy and Marco are
and I have yet to hear anything that seems very useful or practical to
me.
Post by Marco Neumann
Post by ajs6f
That having been said, and speaking very much as a member of W3C's
JSON-LD
Post by Marco Neumann
Post by ajs6f
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
Post by Marco Neumann
Post by ajs6f
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
Post by Marco Neumann
I agree Andy, there is no need to rush things here and break the API.
Maybe
Post by Marco Neumann
we could provide an in memory model for "Generalized RDF" as sandbox
for
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
people to play with. But what I'd like to see are more bridges to the
json
Post by Marco Neumann
community as it has become the defacto lingua franca for data exchange
on
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
the web now.
In particular with regards to generic json rather than json-ld.
possibly
Post by Marco Neumann
Post by ajs6f
a
Post by Marco Neumann
generic mapping to a json dataset assembler could work for data access
and
Post by Marco Neumann
transformation. has anybody done anything here already?
Post by Andy Seaborne
Internally, that means Graph/Node/Triple and the ARQ engine, Jena
really
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
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.
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
Post by Marco Neumann
are we prepared in Jena for such a move on the RDF syntax?
---------- Forwarded message ---------
Date: Thu, Nov 22, 2018 at 1:05 PM
Subject: ✅ Literals as subjects Re: Toward easier RDF: a proposal
,
,
Post by Andy Seaborne
Post by Marco Neumann
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
Post by Marco Neumann
Post by ajs6f
Post by Marco Neumann
Post by Andy Seaborne
in
Post by Marco Neumann
subject and object positions. Life is too short for arbitrary
unnecessary
Post by Marco Neumann
asymmetry.
timbl
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
Loading...