Re: experiences promoting a JSON format for RDF

On 06/03/11 13:56, Brian Peterson wrote:
> I went back and looked at the @coerce mechanism and I like it.

Good to know. :)

> We aren't trying to solve a general problem of consuming a JSON resource
> with no a priori knowledge of where it came from. The developer will have an
> expectation of what the resource will look like (eg literal values vs arrays
> of values, or strings as URIs versus dates).

That does make the problem simpler to solve.

> I think our targeted used case is a good first step for a JSON format. It
> allows for a very simple specification, which I think is critical for the
> general JSON community. JSON is popular (IMHO) because it is simple,
> dynamic, and -- most important of all -- SIMPLE.

I agree with you in principle.

Keep in mind that our use case isn't addressed with the simple
specification that you outline. That is, it would work for you - but the
Web Payments and PaySwarm work would not be able to use this simplified
specification.

Any disagreement that we have on what constitutes a "simple" solution is
grounded on a commercial system that is in development right now:

http://payswarm.com/

The definition of "simple" should be the minimum set of things that work
for the majority of the linked JSON community.

>> I don't think we need to bring in HTML semantics into JSON, do we?
> 
> Certainly not. I agree that the complexity of the HTML links specification
> might not fit well within the simplicity of JSON.

Good - glad we agree on that as well.

>> Good to know - and your experiences have been very helpful to read
>> through, Brian. Thanks for sharing them. Do you think there is a place
>> for CURIEs in property names for advanced use cases, or do you think
>> that we should not use them at all? 
> 
> I think there needs to be a layered specification: First a dirt simple one
> that a front-line JSON/UI developer can pickup with no understanding of RDF,
> then a series of extensions that add complexity and more of an RDF feel. And
> the simpler spec should be kept quite distinct in the documentation from the
> more complicated ones. RDF suffers from people getting the simple and
> effective parts confused with the more complex and esoteric parts.

Again, I agree with you in principle. My concern is that if we have a
"layered" specification (and I don't quite understand what you mean by
that), I'm afraid that people may get confused with there being multiple
conformance levels (JSON-LD light vs. JSON-LD medium vs. JSON-LD heavy).
At the extreme end is the MPEG-4 specification - it has 24 parts most of
which are rarely implemented. We don't want that and I know you're not
saying that we should do that, but the question of where to draw the
line is important. So, let's try to get some clarification on this:

Do you want to modify the prose in the spec to start out simple and then
get more complex? Should there be one, two or three parts? Would each
one of these parts be a different conformance level? That is, people
could choose to implement part 1, but not implement part 2 or part 3?

> I don't think CURIEs fit in the simple spec. JSON is fundamentally simple.
> CURIEs are an embedded structure within JSON's simple keywords. They aren't
> needed for a simple, intro spec, so don't introduce the added complication
> at the start.

Are you talking about the prose of the spec, or the conformance level of
the spec?

>> What about a default context -
>> should there be objects that are universal to the Web - like FOAF
>> identities and geo locations and audio/video objects? 
> 
> Personally I like a default context. But what I've seen is that developers
> using JSON or producing JSON really don't like reserved keywords, which is
> what the default context would be. If the default context was used only at
> the level of the spec that introduces CURIEs, then I think it would be
> great.

Hmm, interesting. So, you are asserting that people are going to get
upset because they can't use "dc", "geo", "foaf", "xsd", or "ps" as
property names?

To play devils advocate - if they're using JSON-LD, aren't they going to
know that the JSON keys are important in some way? Why are they going to
be upset that there are a set of common prefixes already defined for
them? Would this group of people be less upset if they can choose to not
load the default context?

>> Or do you think
>> every website should create their own profile and use it? 
> 
> For a simple spec and for our use case, this works fine for us. A spec based
> on tokens as keywords (which I very strongly endorse) would work fine with
> website/service specific profiles.

That works for your webservice, but it doesn't work for the Web Payments
/ PaySwarm web service use cases. We want people to be able to mix
vocabularies and we want to allow ourselves room to grow by using more
than one vocabulary profile. Distributed extensibility of what can go in
a digital contract in PaySwarm is also important, so we want people to
be able to use their own vocabularies to describe things that can be
purchased.

>> What do you
>> think of the "@" special properties in JSON? Do you think that people
>> should just use "uri" instead of something like "@subject" or "@iri"?
>> What about established JSON objects, like what Twitter uses, that
>> already use "url" to identify certain things?
> 
> I made a mistake when I reserved "uri" and "type" as special keywords. I
> regretted it soon after we started using it. I really like the idea of using
> a "@" prefix on all reserved keywords associated with the JSON-LD spec. 

That's a very useful data point. Do you have a preference on "a" vs.
"@type"? or "@" vs. "@subject"?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Developer Tools and Demo Released
http://digitalbazaar.com/2011/05/05/payswarm-sandbox/

Received on Friday, 17 June 2011 14:35:44 UTC