Re: experiences promoting a JSON format for RDF

Hi Manu,

On 2 Jun 2011, at 03:42, Manu Sporny wrote:
> We've found that we cannot write fully generic code without
> post-processing the JSON-LD that we get in. That is, we're consistent in
> what we publish, but when we get JSON-LD in from developers, we cannot
> expect that they will follow the same strict rules that we use to
> generate "clean" JSON-LD.
> 
> That is, for the example above, we would expect that some developers
> would send us:
> 
> phoneNumber: "123-555-6789"
> 
> While others would send us:
> 
> phoneNumber: ["123-555-6789", "111-222-3333"]

I find this strange.

JSON APIs usually document whether a key takes a singleton value or a list of values.

Producing JSON that does this consistently is easy.

Consuming JSON that does this consistently is easy.

Why do you expect that developers don't do this consistently?

The only situation I can think of that makes is hard to do this consistently is when you produce JSON from RDF, because in RDF you usually don't know whether *everyone* has just one phone number or whether there might be one person somewhere in the data that has two.

I suggest that a JSON representation of the RDF should not be made more variable (and hence complex to process) just because of this quirk of RDF.

This suggests to me that by default, if phoneNumber is produced from RDF then its value should always be a list, which might have only one element.

This also suggests to me that there should be something in the profile/context that allows me to state that a certain key (like phoneNumber) is a singleton. Like,

  "phoneNumber": { "maximum": 1 }

And that amounts to an assertion that I only want one phone number per person serialized in the JSON view of my RDF.

Best,
Richard


> Our code would have to have endless if/then statements to check to see
> if the value is a string or an array and if it is an array, process the
> array. Instead, we have created a system of "framing" that is sort of
> like a "projection template" described by the "Projection" interface
> provided by the RDFa API:
> 
> http://www.w3.org/TR/2011/WD-rdfa-api-20110419/#advanced-concepts
> 
> In other words, the "framing" code in JSON-LD would always give you an
> object formatted in a way that you expect. For the example above, you
> could provide a "frame" that would always give you an array of strings
> for "phoneNumber".
> 
> We found that this greatly simplified the code that developers had to
> write for systems that accepted arbitrary JSON-LD input.
> 
> -- 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 10:05:13 UTC