Re: Web Identity draft spec released

On 11/25/13 11:03 AM, Manu Sporny wrote:
> On 11/25/2013 10:22 AM, Kingsley Idehen wrote:
>> On 11/24/13 8:59 PM, Melvin Carvalho wrote:
>>> 2. I would suggest having json ld as the only mandatory
>>> serialization to be supported, but allowing other w3c RECs to be
>>> returned, such as turtle
>> It is important to note:
>>
>> 1. Turtle -- targets everyone 2. JSON-LD -- targets JSON developers.
>>
>> Identity is an issue for everyone i.e., programmers and
>> non-programmers alike, so if there is going to be a default (not that
>> I think there should) then Turtle is the natural candidate. Ideally,
>> you should simply support Turtle and JSON-LD by default :-)
> The downside with supporting two formats is that it makes
> implementations more complex, and it makes integration far more difficult.

Of course it doesn't. If it did, why would I even consider the 
suggestion; bearing in mind I have no interest whatsoever in artificial 
complexity :-)

Please, let's not start yet another distracting formats war. Turtle and 
JSON-LD can co-exist.
>
> Our design goal w/ the PaySwarm stack is to support mechanisms for which
> there is broad familiarity. The primary reason we're picking JSON-LD is
> not because it's a Linked Data format, but because it's JSON and Web
> developers understand JSON far better than they understand TURTLE.

That isn't my point.

My point is to be inclusive, inline with the underlying architecture of 
the Web. There isn't a single piece of the Web's core architecture that 
mandates a single format for structured data representation. That's what 
makes it so cool!

> Asking most Web developers to read in a TURTLE document and work with
> the data is a very dodgy proposition.

No it isn't. That's like insinuating that most Web developers can't 
process natural language sentences. Look at Turtle modulo "@prefix" (a 
premature optimization) and you have a very intuitive short-hand for 
basic natural language sentences.
> Asking them to read in a JSON
> document and work with the data is better.

I don't quite understand your characterization of what Data actually is?

To me, Data is a collection of relationships that express observation 
using a variety of notations. Thus, a Datum is a statement while data is 
a collection of statements. Pushing this analogy further along, a 
statement is a kind of sentence, and a collection of sentences give you 
a paragraph.

If what I state is true, then the intuition inherent in Turtle speaks 
(as it should) for itself. As I said, why would anyone literate in a 
natural language find Turtle confusing, once you put aside the 
distractions that "@prefixes" introduce (solely for aesthetic reasons) 
prematurely?

>
> That said, there is no reason that an implementer couldn't also support
> content negotiating for TURTLE.

This isn't about content negotiation. This is about designing something 
that targets a broad audience, from the onset.

>   For the general case, however, it should
> be the most popular data serialization format for Web developers, which
> is JSON.

We don't need to think in terms of popularity, that's already put the 
Web into enough misconception-driven trouble as it is, just look at the 
mess known as Web 2.0!

>
>> History teaches us that format spats (however they manifest)
>> ultimately detract from the big picture re. web-like (or webby)
>> structured data representation -- that leverages HTTP URIs.
> There's no spat :). PaySwarm has been using JSON-LD as the mandatory
> serialization format for years now because most Web developers
> understand JSON and are using it far more than any other data
> serialization format for Web APIs.

You know I am no stranger to JSON-LD . I had it implemented in DBpedia 
before anyone was even interested in what it was, for the very same 
reasons I am encouraging you to be more open and flexible here. Let's 
not repeat errors from the past i.e.,  simply give people 
(non-web-programmers and web-programmers) options.

[1] http://linkeddata.uriburner.com:8000/vapour -- we've even 
implemented that (note: JSON-LD addition) for the very same reasons.
[2] http://bit.ly/1aOatVa -- simple example of vapour processing JSON-LD 
from DBpedia .

>
> -- manu
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen