- From: Sandro Hawke <sandro@w3.org>
- Date: Thu, 07 Apr 2011 23:35:51 -0400
- To: public-rdf-wg <public-rdf-wg@w3.org>
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