On 23/01/14 10:53, Olivier Rossel wrote:
Let's say you want to retrieve this graph:
:s :p :o
as this JSON-LD:
{"@id": "o", "reverse-p": "s"}
Would it be possible, or is the JSON serialization harcoded to
serialize each resource and only its outgoing properties ?
The JSON-LD engine being used is
https://github.com/jsonld-java/jsonld-java -- the core module, not the
Jena adapter there (which is taken from my project in teh past anyway).
This removes the problem of the jsonld-java adapter depending on Jena
and hence on a Jena version. Otherwise, each new Jena version is ahead
of the named version in jsonld-java. By putting the adapter into Jena,
the dependency is reversed and Jena can ship, e.g. in Fuseki combined
jar, with a version of jsonld-java.
But it's only the adapter that is code I've added.
Jena only depends on stable/formal releases. For jsonld-java that's
v0.2. v0.3 has had quite a lot of engineering applied. I don't know
it's full capabilities.
Jena also allows writer variants to be registered so a customizer writer
could be added by an application. So - it's going to be possible. It's
not going to happen out-of-the-box on the first integration.
Theer are choices here - it's also possible to see the requirement as
being addressed with a JSON-LD to JSON-LD translation step.
Andy
Are there examples of graph serialization in the JSON-LD spec?
On Thu, Jan 23, 2014 at 11:29 AM, Andy Seaborne <[email protected]> wrote:
On 23/01/14 09:26, Olivier Rossel wrote:
Can a SPARQL endpoint return data in JSON-LD format?
It will be able to when JSON-LD is integrated into Jena. It may not look
nice in all cases though - there's no path for a specialized @context.
There are scaling issues with JSON-LD - the spec mandates certain
algorithms which work on the whole structure - but ATM I believe these will
not be much trouble because the client isn't streaming (it's JSON so you
need to parse the whole object/map) and the client is naturally limited in
what it will ask for.
Andy
On Wed, Jan 22, 2014 at 10:37 PM, Andy Seaborne <[email protected]> wrote:
On 22/01/14 20:52, Phillip Rhodes wrote:
I know it's been discussed before, since I think I was the last one
(or one of the last) to bring it up. :-)
To search the archives, try using Gmane.org.
http://dir.gmane.org/search.php?match=jena
But the short version, as I understand it, is that Jena JSONLD support
is here: https://github.com/afs/jena-jsonld
I don't actually know enough about the history and the project
internals to know why it's separate or if there are plans to pull it
into main Jena or not, but there is support there and usable. We use
it in a couple of our projects and it works fine.
Because I haven't moved it into Jena proper yet :-) You may notice there
was a small amount of activity a few days ago - clearing up prior to
moving
to RIOT. It's just a small matter of finding the time. Then it'll will
be
in the main build.
The real work is done by https://github.com/jsonld-
java/jsonld-java(which only depends on other Apache Licensed
dependencies). I was waiting
for jsonld-java to go to v0.3 but I'll move the code in depending on v0.2
and switch when they release 0.3.
Andy
relatively quick)
Phil
This message optimized for indexing by NSA PRISM
On Wed, Jan 22, 2014 at 3:41 PM, Samuel Padgett <[email protected]>
wrote:
JSON-LD is now a W3C Recommendation [1]. Has JSON-LD been considered
for
Jena? I was curious if it was in the roadmap or if there are no plans
for
support. It would be nice if JSON-LD were supported natively.
I searched the JIRA issues for Jena and didn't find anything.
(Apologies
if
this has been discussed on the mailing list before... I couldn't find
an
obvious way to search the archives.)
[1] http://www.w3.org/TR/2014/REC-json-ld-20140116/
--
Samuel Padgett | IBM Rational | [email protected]
Eclipse Lyo: Enabling tool integration with OSLC
