JSON serialization/parsing

[GoogleCodeExporter]

Attached JSON serializer and parser, for consideration.

Original issue reported on code.google.com by azarot...@gmail.com on 15 Jul 2009 at 5:41

Attachments:

• JsonParser.py
• JsonSerializer.py

[GoogleCodeExporter]

Original comment by eik...@gmail.com on 1 Feb 2010 at 8:25

• Added labels: Component-Serializer, Milestone-Release2.5

[GoogleCodeExporter]

Original comment by ed.summers on 1 Feb 2010 at 10:43

[GoogleCodeExporter]

Given the current plethora of JSON formats for RDF, can we really endorse this 
one? It's 
a nice take (seems based on the Google JSON format for Atom/GData), but see 
also e.g.:

 <http://code.google.com/p/linked-data-api/wiki/JSONFormats>
 <http://code.google.com/p/oort/wiki/Gluon> (my own, experimental, works with 
rdflib)

(Furthermore, Google seems to be moving away from their current format to a 
simplified/compact version 
(<http://code.google.com/intl/en/apis/youtube/2.0/developers_guide_jsonc.html>).
)

Although I'd very much like to see JSON support in RDFLib, we should take care 
to 
support only things with a wide adoption, or wait until more consensus (there 
is interest 
within W3C for this as well).

Original comment by lindstr...@gmail.com on 2 Feb 2010 at 12:56

[GoogleCodeExporter]

Why pick and choose?  So long as each format has an identifier, then they can 
be used
or not as the developer desires. Some better naming system could be used to 
make the
distinctions easier:  json-(name)  for example.

Original comment by azarot...@gmail.com on 2 Feb 2010 at 1:14

[GoogleCodeExporter]

Since eikeon is leaning towards bundling additional non-core functionality as 
3rd 
party extensions perhaps json serialization/deserialization can be left out of 
the 
core and distributed separately somehow?

Original comment by ed.summers on 2 Feb 2010 at 2:56

[GoogleCodeExporter]

Yeah, let's focus on getting the core bits back in order first for 
Milestone-Release2.5.

Original comment by eik...@gmail.com on 2 Feb 2010 at 4:00

• Added labels: Milestone-Unscheduled
• Removed labels: Milestone-Release2.5

[GoogleCodeExporter]

Rob, would you be open to me working with you to bundle this as an extension? 
I'm 
thinking of putting the code on github/bitbucket or in an extensions svn 
directory 
here in rdflib svn, adding setup.py, docs, pushing to pypi, and adding an 
extensions 
page to the rdflib wiki?

Original comment by ed.summers on 2 Feb 2010 at 4:30

[GoogleCodeExporter]

@edsu:  Yep, no problem :)

Original comment by azarot...@gmail.com on 2 Feb 2010 at 5:03

[GoogleCodeExporter]

Sounds like a great plan guys; thank you. I think we'll all benefit from more 
distributed development and keeping 
rdflib a little leaner.

Original comment by eik...@gmail.com on 2 Feb 2010 at 5:27

[GoogleCodeExporter]

hmm I didn't get much time to spend on packaging up this as an extension. As 
lindstream said, there are some other more "standard" json formats that would 
make sense to bundle in rdflib. There's nothing that prevents azaroth42 from 
distributing his rdflib plugin himself. So I'm going to close this one.

Original comment by ed.summers on 28 Nov 2010 at 10:53

• Changed state: WontFix

[GoogleCodeExporter]

I agree, as expected. ;) There's a lot going on right now on this front, and we 
should wait to see how the dust settles standardization-wise. Specifically for 
RDFLib, I've included the Gluon mechanics in the Oort trunk proper for anyone 
interested (just one of many ways to do it, and gluon *will* get updated as 
consensus is hopefully approached).

Original comment by lindstr...@gmail.com on 28 Nov 2010 at 12:17

[GoogleCodeExporter]

I should also say that if there's a convergence in the plethora of formats, I 
expect Gluon to merge with that. If so, I think my parsing and serializing code 
should be moved from "Oort" to rdfextras (considering that for "incubation" for 
possible inclusion in RDFLib once the format is 
finalized/standardized/"defacto"-ized).

Original comment by lindstr...@gmail.com on 28 Nov 2010 at 12:25