RE: experiences promoting a JSON format for RDF

In general it decides on the fly; however, the utility we have that
generates JSON from annotated Java classes will always generate an array if
the Java bean property returns a collection. So in that case, the JSON
keyword value will always be an array even if there is only one value. But
there is nothing in our in-house specification that requires consistency
between resources. 

Brian

-----Original Message-----
From: Richard Cyganiak [mailto:richard@cyganiak.de] 
Sent: Tuesday, May 31, 2011 2:48 AM
To: Brian Peterson
Cc: public-linked-json@w3.org
Subject: Re: experiences promoting a JSON format for RDF

Thanks Brian!

On 31 May 2011, at 03:37, 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"]

Did you decide on the fly whether to use an array or a simple value? That
is, if Alice has one phone number and Bob has two, would Alice get a simple
string value and Bob an array of strings?

Thanks,
Richard


> 
> 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.
> 
> Other simplifications that we use:
> - Only simple literals, no language tagging and no datatyping.
> - URIs appeared as simple literals.
> 
> 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.
> 
> 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:
> 
>   link : {
>      profile : {...},
>      next : {...}
>      ...
>   }
> 
> Each mapping in the link object maps to another object, one modeled along
> the lines of the Web Links RFC (http://tools.ietf.org/html/rfc5988).
> 
> 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.
> 
> Brian
> 
> -----Original Message-----
> From: public-linked-json-request@w3.org
> [mailto:public-linked-json-request@w3.org] On Behalf Of Richard Cyganiak
> Sent: Monday, May 30, 2011 7:44 PM
> To: Brian Peterson
> Cc: public-linked-json@w3.org
> Subject: Re: experiences promoting a JSON format for RDF
> 
> +1
> 
> This resonates with my experience when negotiating with JSON developers. I
> would quite like to have a well-defined format like this.
> 
> I find the link/profile/rel/anchor thing a bit complicated (why not just
> profile:"http://..." on the root object?) and would like to see how to
deal
> with multi-valued properties.
> 
> Best,
> Richard
> 
> 
> On 30 May 2011, at 23:10, Brian Peterson wrote:
> 
>> I work in a group within a much larger organization. Part of my job in
> this
>> group is to promote the adoption of Linked Data as an enterprise-wide
>> architecture, including supporting RDF. Manu asked (in a previous
posting)
>> for some feedback and suggestions for a JSON format. I thought I'd
>> contribute an overview of the JSON format that we came up with to help
>> promote Linked Data throughout our enterprise.
>> 
>> It is easy enough to convince other development groups to adopt REST and
> to
>> use URIs to identify their web resources. It was impossible to convince
>> Javascript developers to adopt RDF. An initial JSON format for RDF that
>> included URIs or CURIEs for properties went nowhere. Javascript
developers
>> would never chose to work in that format, and service developers
consuming
>> JSON would never choose to use it; consequently, services would never
>> include support for it. They would always end up with custom JSON that
had
>> little relation to RDF.
>> 
>> We still wanted to eventually get to where RDF was supported throughout
> the
>> enterprise. So the challenge was to design a JSON format that encoded RDF
>> without looking like RDF, without requiring developers to lean and
>> understand RDF. 
>> 
>> I know most people look at RDF from the perspective of graphs. I started
>> looking at RDF and promoting it as a formalization of hypermedia links,
> and
>> as a pattern for designing resources - a resource has properties, and
> these
>> properties have values (SPO - a triple). Looking at RDF more as a
resource
>> description framework (not intended to be flippant) and less as a vehicle
>> for logical semantics and graph models made it much easier for system
>> engineers, architects and developers to understand and utilize. This
> helped
>> focus the role of RDF in the day-in-a-life of a developer to something
> they
>> could work with. Suddenly RDF was so scary and confusing.
>> 
>> I then took a lesson from the RDFa specification for vocabulary profiles.
> I
>> haven't looked at the RDFa 1.1 specification recently, but at one time
the
>> idea was to use profiles to make keywords to URIs. This was exactly what
I
>> needed to make an RDF+JSON accessible to regular Javascript and service
>> developers. Our RDF+JSON started looking like this:
>> 
>> {
>>   uri : "http://ex.org/hr/people/123",
>>   name : "Brian Peterson",
>>   phoneNumber : "123-555-6789",
>>   address : {
>>       street : "123 Sesame St",
>>       city : "New York",
>>       state: "NY"
>>   },
>>   link : {
>>     profile : {
>>       rel : "profile",
>>       anchor : "http://ex.org/vocabs/hr/profile"
>>     }
>>   }
>> }
>> 
>> The "uri" is the URI for the resource. The "link" mapping was intended to
> be
>> analogous to the link element in XHTML, mapping from the link type to an
>> object representing the link. The "profile" link is to the vocabulary
>> profile for the resource. That profile would map the tokens "name",
>> "phoneNumber", "address", "street", "city", and "state" (and possibly
>> others) to their vocabulary URIs (I this case, probably a mix of FOAF and
>> maybe others).
>> 
>> So except for the "uri" and the "link" elements, this would look almost
>> exactly like what a developer would have designed themselves without
>> thinking about RDF. However, the use of those profiles and the standard
>> usage of uri and link.profile keywords, we can generate RDF from this
JSON
>> when we need it.
>> 
>> I understand that this style of RDF+JSON would not fit all use cases for
> RDF
>> in JSON, but it makes it a lot easier to get other non-semantic-web
groups
>> to start using RDF in their linked data architecture. So we also have
>> another format that looks much more like RDF (looks kind of like the
>> JSON-LD) that is available for use cases that need it.
>> 
>> So perhaps having several formats would be useful. The simple format for
> the
>> simple cases and to help adoption, then another more traditional RDF for
> the
>> hard core cases.
>> 
>> Brian 
>> 
>> 
> 
> 
> 
>

Received on Wednesday, 1 June 2011 02:30:27 UTC