Re: Timeline and priorities

On 01/10/2012 11:37 PM, Markus Lanthaler wrote:
>> The JSON-LD Syntax document is very close to completion, only a
>> few more passes are necessary before we could move it quickly from
>> FPWD to Last Call at W3C and then on to REC. So, perhaps a few days
>> of editing spread over a month of editorial work if both Gregg and
>> I are working on it.
>
> I can help if needed!?

Fantastic, we will take you up on that offer, Markus. :)

>> The JSON-LD API needs more work, specifically on the framing
>> algorithm and the normalization algorithm. I would estimate about a
>> week or two of editing spread over a two month period of this
>> document between two editors.
>
> I think we should decouple the progress of the syntax and the API a
> bit more.

The short answer is - we can't. The syntax specification by itself
doesn't provide enough detail to implement conformant, interoperable
JSON-LD processors.

That is, many of the implementation details for JSON-LD are in the
JSON-LD API spec. This was done on purpose in order to give readers a
lighter introduction to JSON-LD. The down-side is that we can't just
take the JSON-LD Syntax document to REC by itself. One alternative is to
split the API spec into two parts - the part that defines the API and
the part that explains how to process the context... but even that is a
difficult line to draw and results in yet another spec that implementers
must go and look at.

Ideally, authors would look at the JSON-LD syntax specification while
implementers would look at the JSON-LD syntax specification, JSON-LD API
specification, and RDF Normalization spec. So, all of the specs are
coupled together.

> I have to confess haven't yet had a deep look at framing and
> normalization but since it's a brand new spec which implements a
> thing that is quite different from existing approaches I wouldn't
> rush too much on specifying the API.

I understand your hesitation, but let's look at the flip-side. To you,
JSON-LD is a brand new spec... but to us (Digital Bazaar), it's many
years old at this point. We've been using variations of it to build our
products for that time period. I think a better approach would be for
those in the group to come up to speed on framing and normalization and
provide technical input on the algorithms presented. While it's good to
be cautious about standardizing APIs too soon, it's also bad to put off
standardizing APIs based on unfamiliarity with the solution.

To come at it from another direction, this has been the argument to
/not/ standardize RDF normalization for over 7 years now and the result
is... no standard way to normalize RDF. At some point we have to accept
that the solution that we create is non-optimial and do our best to make
sure that what we create is the best that we can do.

> We don't even know yet how people end up using JSON-LD.

... and we won't until it's at REC. :)

This is the case with all Internet technologies... you don't truly
understand how people use the technology until it is in broad adoption
and to get broad adoption, you need to get to REC. HTML5 is a rare
exception, but remember that it's the 5th iteration of the language...
you have to say "we're done with this version" and hit REC at some point
to find out how people use the technology you developed.

> So especially framing (or other query mechanisms) might be something
> where we might need to spend much more time on.

I hope not... the algorithm is there, several implementations are
available for people to test drive... what we really need is for people
to familiarize themselves with the API and start writing a few
applications to take it for a test drive. That will hopefully educate
people enough such that they either start feeling comfortable with the
API or provide technical feedback on how to change the API.

>> The RDF Graph Normalization document is the document that needs
>> the most work.
>
> The question here is if we completely separate it from JSON-LD or
> not, see also ISSUE-53.

I would, personally, be very much opposed to this. We (the semantic web
/ linked data community) need to address this 7+ year old issue... we
have a chance with JSON-LD, a proposal w/ multiple implementations has
been put forward... the question should be: What are the technical issues?

Sure, we could cut normalization out of the JSON-LD API, but I would see
that as a failure of this group to tackle one of the hardest (and most
important) problems related to RDF. You need normalization to perform
things like graph diffing, digital signatures, etc. It's not as if we're
saying: "We don't know how to solve the problem, so we have to figure it
out.". We're saying: "We know exactly how to solve the problem, here is
the solution, here are implementations... does anyone have any technical
issues with the solution?"

>> End of March 2012: JSON-LD API editing complete End of May 2012:
>> RDF Graph Normalization editing complete
>
> I doubt we will meet those deadlines.

It's good to dream. :P

>> End of May 2012: Start JSON-LD WG at W3C.
>
> Why can't we do that immediately after the syntax spec is complete?

Hopefully, I answered this question above... Syntax spec is dependent on
at least the API spec.

Good feedback, as always, Markus. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm vs. OpenTransact Shootout
http://manu.sporny.org/2011/web-payments-comparison/

Received on Wednesday, 11 January 2012 14:46:11 UTC