Re: [JSON] user segments, version 2

On 2011-04-08, at 04: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.
> 
> 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 and Andy and Steve are pushing back, since their current users
> are mostly in Group B.

To be clear, it's not my users I'm pushing back on behalf of, it's us *as* users.

We consume a lot of JSON, and use a lot of RDF internally.

Our commercial users aren't in any of those groups, I would guess 4/5store users are mostly in the A group, but hard to say.

- Steve

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

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Friday, 8 April 2011 08:37:34 UTC