Re: [JSON] user segments, version 2

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.


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


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


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