W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011

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

From: Nathan <nathan@webr3.org>
Date: Thu, 10 Mar 2011 02:20:46 +0000
Message-ID: <4D78357E.6020801@webr3.org>
To: RDF WG <public-rdf-wg@w3.org>
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"?

yes, apologies as below:

> { "name": "nathan", "foo": "bar" }
>> 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.

I'm not sure we're using "tooling" in the same way here, parsing JSON is 
pretty much native in most languages now as we both know.

More about tooling for JSON in RDF below..

>> 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:
>    Expands all Terms/CURIEs into full IRIs
>   Removes any Microsyntax markup so that values can be used more
>   directly
>   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.

In all honesty Manu, if this is useful, I don't see why it should be 
bound to or dependant on "RDF in JSON", why not add a .toObject(g,map) 
to the RDF API so that it's available and common for every serialization?

>> 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.

Yes, with an API, and why have two APIs?

>> 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?

Yes, as noted in the other thread, if it requires "tooling" (I used this 
term rather than API) then I'm struggling to see why custom for RDF in 
JSON rather than just normal RDF tooling, it's either RDF or not surely?

Apologies if it seems like I'm hard lining here Manu, as you know I'm 
always open to multiple suggestions / approaches and frequently wrong on 
things, but I am concerned about unexpected functionality for "normal" 
developers - or, perhaps there needs to be some interim bridge between 
the OO and Triple worlds and that is one of the trade offs to be considered.

Whichever way, time will tell, both within the group to see which 
direction is taken, and ultimately from the web at large, who'll choose 
the techs they want for themselves.

> 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.

Depends if you throw an API in to the mix I guess, can't see any reason 
why graphs can't be turned in to objects, and likewise the inverse.


Received on Thursday, 10 March 2011 02:22:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:04 UTC