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 Thursday, 2 June 2011 02:36:27 UTC