RE: experiences promoting a JSON format for RDF

Manu Sporny wrote:
> > Other simplifications that we use:
> >  - Only simple literals, no language tagging and no datatyping.
> >  - URIs appeared as simple literals.
>
> The newest version of JSON-LD does this as well... but with the
> additional feature of allowing data-typing via the @coerce mechanism, as
> Gregg outlined.

I went back and looked at the @coerce mechanism and I like it.

> May I ask which large organization you work for? I'm curious. The reason
> I ask is that we've seen different answers from different types of large
> organizations and I wanted to get a feeling which industry or market
> vertical yours is in.

I work for Next Century [1] as a contractor in the DoD community. The DoD
Agency I primarily work at is quite large with an extensive investment in
IT. There's a small army of programmers from a wide variety of contractors
and government workers. The team I work on is bringing Linked Data to this
large network of web services that drive a wide variety of applications and
UIs. 

Our primary use case is to support the use of Linked Data for the developer
of client applications: the developer knows what the service is, and the
service has published a single vocabulary that covers the entire entity in
the response.

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).

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 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 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.

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.

> 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.

> 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.
 
> 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. 


[1] http://www.nextcentury.com/

-----Original Message-----
From: public-linked-json-request@w3.org
[mailto:public-linked-json-request@w3.org] On Behalf Of Manu Sporny
Sent: Wednesday, June 01, 2011 10:36 PM
To: public-linked-json@w3.org
Subject: Re: experiences promoting a JSON format for RDF

On 05/30/2011 10:37 PM, Brian Peterson wrote:
> I ended up rolling up multiple values into a JSON array. So if I had
> multiple phone numbers, then it would be 
> 
>    phoneNumber : ["123-555-6789", "111-222-3333"]

That makes sense - and is also what JSON-LD does.

> Values in arrays can be strings, URIs, or nested objects for other those
> resources. Arrays are not be used as values themselves. This limitation
has
> had no practical impact for us because we aggressively avoid RDF lists.

Agreed.

> Other simplifications that we use:
>  - Only simple literals, no language tagging and no datatyping.
>  - URIs appeared as simple literals.

The newest version of JSON-LD does this as well... but with the
additional feature of allowing data-typing via the @coerce mechanism, as
Gregg outlined.

> Our developers were very much against embedding structure within JSON
> strings, which ruled out tags, datatypes, and angle-bracketing URIs. These
> simplifications will rule out many RDF use cases, but it was quite evident
> that the advantages outweighed the drawbacks. I hope to use rdf:domain and
> rdf:range assertions on the vocabulary (or perhaps in the profile) to help
> mitigate the drawbacks.

Some of the preliminary versions of JSON-LD used microsyntaxes, and we
learned over the course of several months that many people hated the
microsyntaxes - so we got rid of them, too. It's nice to see that you
came to the same conclusions as well.

May I ask which large organization you work for? I'm curious. The reason
I ask is that we've seen different answers from different types of large
organizations and I wanted to get a feeling which industry or market
vertical yours is in.

> On the "link" objects: I originally had just "profile" on the root object,
> but talked myself into treating it like another web link, analogous to the
> HTML link elements (I think the RDFa profile reference appears in a link
> element). So other links for the resource would also end up in that
> structure rather than mixing with the RDF properties of the resource:

I don't think we need to bring in HTML semantics into JSON, do we?

> I like the symmetry with XHTML links, the generality of treating the
profile
> as another link, and keeping these links separate from the RDF properties
on
> the resource; however, I do like the simplicity of a simple "profile"
> mapping on the root object. I'm also not sure it was worth trying to model
> the Web Links in the RFC.

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? 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? Or do you think
every website should create their own profile and use it? 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?

-- 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, 3 June 2011 17:57:03 UTC