[JSON] user segments, version 2

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.

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

Received on Friday, 8 April 2011 03:36:03 UTC