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

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.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Towards Universal Web Commerce
http://digitalbazaar.com/2011/01/31/web-commerce/

Received on Thursday, 10 March 2011 01:35:52 UTC