Re: [JSON] object-based JSON vs. triple-based JSON

On Wed, 2011-03-09 at 20:35 -0500, Manu Sporny wrote:
> On 03/09/2011 06:08 PM, Nathan wrote:
> >>> I disagree with several steps of your argument here, but I agree we
> >>> should focus on object-based instead of triple-based approaches, so I
> >>> think I'll just leave it there.
> >>
> >> Don't just leave it there! :) If there are holes in my argumentation, we
> >> should expose them so that we're sure of the reason(s) we're picking one
> >> approach over the other.
> > 
> > If I may chip in, "object-based" may not be defined quite right here,
> > most people use JSON as "plain old data objects", e.g.
> > 
> >   { name: "nathan", foo: "bar" }
> > 
> > and use it simply with no tooling:
> > 
> >   print( obj.name )
> 
> Hmm... we need to be very clear here - do you mean "JavaScript" or do
> you mean "JSON"? You seem to have provided JavaScript:
> 
> { name: "nathan", foo: "bar" }
> 
> In other words, what you provided above is invalid JSON (because you
> need to wrap 'name' and 'foo' in double quotes for it to be valid,
> right?). The reason I'm being pedantic here is because this JSON
> expressed via a Web Service:
> 
> { "name": "nathan", "foo": "bar" }
> 
> is typically read in like this:
> 
> jsonData = getDataFromWebService();
> var obj = JSON.parse(jsonData);
> 
> before you can do this:
> 
> print(obj.name);
> 
> > Both JSON-LD and JSN3 are object-based, however they are not just plain
> > old data objects, sure they offer features so that (ignoring the maps)
> > they can be used as plain old objects, but they are not constrained to
> > be plain old objects, which means that when you use it in the wild, you
> > require tooling to do so, else developers will need to write code such
> > as this:
> > 
> >  for(o in objects) {
> >   if(o["@"] == "<http://example.org/people#nathan>") {
> >     print( o["foaf:name"] );
> >   }
> >  }
> 
> It depends on what you're doing and the service with which you're
> interfacing. Keep in mind that anyone that claims things like "Well,
> solution XYZ requires tooling and so it's not as good as JSON" tends to
> forget that even JSON requires tooling. Remember, JSON has the .parse()
> method... or direct eval() if you like living on the edge. The JSON spec
> states:
> 
> """
> If the server is not rigorous in its JSON encoding, or if it does not
> scrupulously validate all of its inputs, then it could deliver invalid
> JSON text that could be carrying dangerous script. The eval() function
> would execute the script, unleashing its malice.
> 
> To defend against this, a JSON parser should be used. A JSON parser will
> recognize only JSON text, rejecting all scripts.
> """
> 
> http://www.json.org/js.html
> 
> So, JSON requires tooling and I don't think requiring a small set of
> tooling for JSON in RDF would be that terrible. In fact, it could solve
> many of the issues some of the folks in this group have with
> microsyntaxes, normalization, and other such warts.
> 
> > Primary problem being, that code isn't reusable, even if generalized and
> > turned in to a function, the properties may be a full URI, might use a
> > different prefix, and so forth. [1]
> 
> Ahh, but remember, if we have some simple tooling we can give something
> to the developers that they can rely upon to give them consistent
> objects. For example, assume that we have a RDF in JSON parser called
> RDFinJSON, and a parse method called .parse(). So far, we're exactly
> like JSON.
> 
> Now imagine that we could pass arguments to the parser, things like:
> 
> EXPAND_IRI
>    Expands all Terms/CURIEs into full IRIs
> REMOVE_MICROSYNTAX_MARKUP
>   Removes any Microsyntax markup so that values can be used more
>   directly
> COMPACT_IRI
>   Directs the parser to use a mapping we provide to shorten IRIs
> 
> Now assume this input (jsonldText):
> 
> {
>    "#":
>    {
>       "name": "http://xmlns.com/0.1/foaf/name",
>       "foo": "http://example.com/vocab#foo"
>       "ex": "http://example.com/v#"
>    },
>    "name": "nathan",
>    "foo": "bar^^<ex:baz>"
> }
> 
> If we wanted to make sure the IRIs were always expanded, we could do this:
> 
> var obj = RDFinJSON.parse(jsonldText, EXPAND_IRI);
> 
> which would give us this:
> 
> {
>    "<http://xmlns.com/0.1/foaf/name>": "nathan",
>    "<http://example.com/vocab#foo>": "bar^^<http://example.com/v#baz>"
> }
> 
> If we wanted to ensure that there is no nasty microsyntax markup, we
> could do this:
> 
> var obj = RDFinJSON.parse(jsonldText, REMOVE_MICROSYNTAX_MARKUP);
> 
> which would give us this:
> {
>    "name": "nathan",
>    "foo": "bar"
> }
> 
> If we wanted to make sure there was no nasty microsyntax markup and that
> all IRIs were expanded, we could do this (and perhaps this would be the
> default result of the .parse() method):
> 
> var obj = RDFinJSON.parse(jsonldText, EXPAND_IRI |
>                                       REMOVE_MICROSYNTAX_MARKUP);
> 
> which would give us this:
> {
>    "http://xmlns.com/0.1/foaf/name": "nathan",
>    "http://example.com/vocab#foo": "bar"
> }
> 
> If we wanted to remap "name" and "foo" to "fn" and "fo" respectively, we
> could provide a developer-specified mapping:
> 
> var mappings =
> {
>    "foaf": "http://xmlns.com/0.1/foaf/",
>    "fo": "http://example.com/vocab#foo"
> };
> var obj = RDFinJSON.parse(jsonldText, COMPACT_IRI |
>                                       REMOVE_MICROSYNTAX_MARKUP,
>                           mappings);
> 
> would give us this:
> {
>    "foaf:name": "nathan",
>    "fo": "bar"
> }
> 
> I could go on, but I think you get the idea - having just one .parse()
> method with a number of arguments can be very powerful and solve a large
> number of the problems that you're outlining. The above is a
> straw-proposal and doesn't solve all of the problems but hopefully
> clarifies that much of the "code isn't re-usable" problem can be
> addressed pretty simply.
> 
> > Why is that a problem? well, it means that the benefits of RDF are lost
> > (core data model, use generic tooling for any data from any source) and
> > the benefits of JSON are lost (simple domain specific k/v objects
> > requiring no tooling).
> 
> Hopefully I've shown how this problem can be mitigated to a fairly large
> degree.
> 
> > As in, meeting in the middle between RDF and plain old objects, requires
> > trading off the simplicity whilst giving the perception that you don't
> > need the tooling - which leads to unexpected functionality, confused
> > users/developers, and imho, is certainly not a recipe for success at all/
> 
> Is this an argument to not try to meet in the middle and go one way or
> the other?
> 
> If so, I wouldn't necessarily agree with that direction. I think many of
> the goals that the triple-based camp wants can be accomplished using the
> object-based approach. I do not think, however, that many of the goals
> of the object-based approach can be accomplished via the triple-based
> approach.

Now I'm confused.   If users have to call .parse() anyway (as I agree
they should for JSON, but I'm not sure if they do), then why not
transmit the data in turtle?   We have turtle parsers in JS already,
etc.    Then the rest of this discussion is just about the API for the
JS library (which is a subject for your other Working Group.)

The argument that convinced *me* JSON+RDF was important for this WG was
the idea that an important subset of RDF could be put into JSON in a
straightforward way that would make sense even if one didn't really
understand RDF.   I was hoping for a language that could be read and
generally understood without even reading the spec.  It could be as much
a teaching tool, a gentle slope to RDF, as a practical format.  That's
what I was trying to do with JRON.  

   -- Sandro

Received on Thursday, 10 March 2011 02:06:20 UTC