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