Re: [JSON] A starting point...

On 04/07/2011 08:16 AM, Andy Seaborne wrote:
> On 07/04/11 03:00, Manu Sporny wrote:
>> On 04/06/2011 03:14 PM, Andy Seaborne wrote:
>>> I don't quite understand how this list of questions arises as being the
>>> key questions, or maybe just I don't know which user segments we are
>>> addressing.
>>>
>>> If it's 3/4/5+C, that segment assumes a library, and we have two forms
>>> of that: a one step specific-parser to produce a JS structure that the
>>> app can use, or a full-blown library where access is always via a
>>> library call. Either way the format on-the-wire isn't directly visible
>>> to the application.
>>
>> We are interested in that segment,
> 
> "we" being?

Strictly speaking, "we" being "Digital Bazaar, Inc."

>> but we are attempting to reach a
>> broader audience. That is - we can do almost anything with a library so
>> the on-the-wire format doesn't matter.
> 
> But it does need defining.

It does need defining, yes.

My point was that the library-based on-the-wire format is far more
malleable than the "JSON as RDF" on-the-wire format because the
library-based approach means that the developers never have to see the
on-the-wire format. So, it does need defining, but we don't have to be
as careful with the library-based on-the-wire format as we do with the
"JSON as RDF" on-the-wire format.

> OK - this is "JSON as RDF" - annotate the JSON to make it interpretable
> as RDF for those that want to.  The annotations can be ignored to leave
> "standard" JSON.

Correct.

> "JSON as RDF" assumes there will be uptake (a plausible belief, but a
> belief) and is speculative.

Yes, that's correct.

> Targeting the no-library-at-all case does not automatically come up with
> a good solution for the library case.

The "good solution for the library case" is not automatic - but that's
not what I was saying. I was just stating that there would be /a/
workable solution that was automatic and that the reverse was not true.
Having a good solution for the library case does not automatically mean
that there would be /a/ solution for the "JSON as RDF" use case.

> It's not good for the RDF publisher - for example, the annotations are
> designed for the typical data but an RDF publishing system has a graph,
> no other information, and wants the export RDF in JSON.  Where does the
> @context/@vocab come from? 

It comes from the publisher.

> It's not going to look like if it's
> synthetically generated, and so it will not meet the expectations of the
> group a consumers.

I don't follow. What do you mean by "It's not going to look like if..."?

> Just don't call "JSON as RDF" "application/rdf+json" because it's not.

We were calling it "application/json-ld" - :P

> Why it's not in the RDF web application WG is another question - won't
> the get the right people involved? And align it to the RDF API?

Maybe... but if it were there, we wouldn't be having this conversation -
which is a very good conversation to have. I'm always wary of groups
where, when an idea is presented, there is just a bunch of agreeable
nodding. I think we can safely say that is not happening here - and I
see that as partly a good thing. It forces us to examine each others
viewpoints before proceeding.

The RDF Web Apps WG was just re-chartered... I don't think the W3C team
wants to re-charter it yet again.

Frankly, I don't care where the work gets done... as long as it gets
done. I'd rather it happen in this group with a handful of people that
are critical of it, than in the RDF Web Apps group with a handful of
people that want to see the work happen.

> I hope the outcome of the F2F will be a decision on what is the target
> and who is interested.  Jumping to a starting point is jumping that
> decision.

The starting point was merely meant as a proposal - not attempting to
jump any decisions. It's merely another feeler out to the group. I find
it's easier to make decisions like this when there are a few solid
proposals on the table. I think we have at least one proposal for the
"JSON as RDF" work starting point now. I don't know if we have one such
thing for the "RDF in JSON" work starting point. Would someone care to
create one (or more) such proposals?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The PaySwarm Vocabulary
http://digitalbazaar.com/2011/03/31/payswarm-vocab/

Received on Friday, 8 April 2011 02:12:03 UTC