W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2011

Re: [JSON] user segments, version 2

From: Sandro Hawke <sandro@w3.org>
Date: Fri, 08 Apr 2011 14:10:31 -0400
To: Ivan Herman <ivan@w3.org>
Cc: public-rdf-wg <public-rdf-wg@w3.org>
Message-ID: <1302286231.6230.1204.camel@waldron>
On Fri, 2011-04-08 at 09:46 +0200, Ivan Herman wrote:
> On Apr 8, 2011, at 05:35 , Sandro Hawke wrote:
> 
> > After some more thought, I think my user segments matrix [1] is a poor
> > fit for the issues we need to understand.   I suggest a somewhat
> > different approach here.
> > 
> > To start, we can simplify the space by ignoring the rows, ignoring the
> > different kinds of producers.  This is reasonable if we think that data
> > producers will use whatever formats are demanded by their intended
> > consumers.   Yes, some may be recalcitrant in some way, but I think if
> > they have an option that makes all their users happy, they will adopt
> > it.  So we can just focus on what will make the users happy.
> > 
> > So that leaves us with the same three groups of users, which I'll
> > reframe slightly, and one more I neglected earlier:
> > 
> > Group A -- Developers who want a simple JSON view of their application
> >           data.  These are the folks using all the popular json APIs,
> > 	   such as twitter, facebook, flickr, etc, etc.
> > 
> > Group B -- Developers who want a simple JSON view of arbitrary RDF
> >      	   triples.  These are the folks happy to use things like
> >           Talis' RDF JSON, JTriples, etc.  
> > 
> > Group C -- Developers who want RDF triples, but are willing to use a
> >      	   library or API to get it.  This group would be satisfied by
> >      	   something that worked for Group B, since a library could
> >      	   easily extract the triples.
> > 
> > Group D -- Developers who want a simple JSON view of a limited subset
> >           of RDF triples, such a tree-shaped data without any
> >           language tags or dates.  This group would also be
> >           satisfied by something that worked for Group B; they just
> >           don't need as complete a format.
> > 
> > Groups A, B, and C are the same as in the matrix.  Group D is new.
> 
> I am not sure this is what you meant, but 'D' probably also means that user in this category are not really willing to use a specialized API. I guess they want to be able to make use of the data through a json.parse() command right away and they are not willing (at first) to make the extra step of using an extra library.

Yes, my use of the word "simple" was meant to convey that Group D
doesn't want to use a library.


> > 
> > Now, with this simpler view, we can see where the real complication is:
> > we'd like to address several of these groups at once.  Ideally, we'd
> > like a single JSON format that works for everyone.  If it worked for
> > Group A, it would keep the current users happy (and twitter, facebook,
> > etc wouldn't mind adopting it). If it also worked for Group B (call
> > this an "AB" solution), it follows that it would also work for C and D
> > and everyone would be happy.  But I don't think there are any AB
> > solution.
> > 
> > It's somewhat easier to imagine "AC" and "AD" solutions.  I think
> > mostly the debates are which of B, AC, and AD we can or should do.
> > Maybe ACD is possible, too.     I *think* Manu is pushing for an AC
> > solution
> 
> I believe JSON-LD's goal (ie, Manu's:-) would be more something like ACD (not sure it reaches it, though). Ie, a format that, at least in simple data, *can* be used by users in group D.

Can prefixes really be handled without a library?   I don't think so.  
 
> > and Andy and Steve are pushing back, since their current users
> > are mostly in Group B.
> 
> I think you are right.
> 
> Others have said it before: I think we have, potentially, two JSON+RDF things here, and that is what we may have to do. 

Agreed - an AC solution and a B (and D) solution.

   -- Sandro

> 
> Ivan
> 
> > 
> > FWIW JRON aimed for AB, but I don't think it quite hits the mark.  In
> > particular, its JSON is perhaps too cluttered to be a real Group-A
> > solution (although for normal JSON data it's pretty clean), and for
> > some things (like namespaces) the consumer code need too much code to
> > work for Group B.
> > 
> >    -- Sandro
> > 
> > [1] http://www.w3.org/2011/rdf-wg/wiki/JSON_User_Segments
> > 
> > 
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
> 
Received on Friday, 8 April 2011 18:10:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:41 GMT