Re: [JSON] user segments, version 2

On Sun, 2011-04-10 at 08:24 +0100, Nathan wrote:
> Ivan Herman wrote:
> > HI Sandro,
> > 
> > On Apr 9, 2011, at 13:51 , Sandro Hawke wrote:
> > 
> > <snip/>
> > 
> >> On Sat, 2011-04-09 at 10:17 +0200, Ivan Herman wrote:
> >>> On Apr 8, 2011, at 20:10 , Sandro Hawke wrote:
> >>>
> >>> <snip/>
> >>>
> >>>> Yes, my use of the word "simple" was meant to convey that Group D
> >>>> doesn't want to use a 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.
> >>>> Can prefixes really be handled without a library?   I don't think so.  
> >>>>
> >>> No they can't. But the point is: in some cases you do not care. If you have something like
> >>>
> >>> {
> >>>  "@context" : { "name" : "foaf-uri-for-name", ... }
> >>>  "name" : "Sandro"
> >>> }
> >>>
> >>> *some* applications may want a full, RDF-like interpretation of the data (i.e., they need a library to manage the context), but some applications do not really care about that because they operate on very specific pages anyway, in which case they are perfectly happy with something like
> >>>
> >>> f = json.parse(data);
> >>> f.name ...
> >>>
> >>> (or something like that). So a 'C' user is a 'D' user wearing RDF goggles, like Nathan called them... Put it another way, a specific user may start in the 'D' category then he/she realizes that there is more to achieve if an additional library is used, and can migrate into 'C', using the very same data.
> >> Isn't that really a Group A way of looking at the world?  It's only
> >> going to work for one site, following their arbitrary protocol.    In
> >> this case the arbitrariness is their selection of prefixes.   
> > 
> > Ok, that is true. What I wanted to say is that the same format, that covers A may also be appropriate for group D and C.
> 
> Indeed, A and D are so closely related that I don't really see a 
> distinction personally, other than A appears to have no care 
> what-so-ever for RDF / Linked Data, so unsure why it's mentioned :p

I can't tell how much you're joking here; I'll err on the side of
clarity.

Group A wants the nicest simplest JSON API they can get.  They expect to
write different code for each service they talk to, and they want the
JSON to be custom designed for that service.

Group D want the nicest simplest way to get RDF triples they can get.
They differ from B in that they don't care about supporting all RDF
graphs -- the data they care about doesn't use language tags, or
extended datatypes or someting.   They want RDF because they do not want
to write different code for each service they talk to.  The want the
same code to work for every service with that kind of data.  They
certainly do not want the JSON customized for each site, because that
means arbitrarily many different modules they need to write.

The reason Group A is mention is because that's the vast bulk of
developers right now.   Nearly everyone wants to keep them happy.  Any
solution that makes them unhappy is going to be a niche solution.   I
want to keep them happy.   (Like many of use, I sometimes find myself in
Group A, when I don't expect to need to talk to more than one site.)

> To me, a good example is: <http://graph.facebook.com/1234>
> 
> If you somehow said "stick http://ogp.me/ns# before each property, and 
> use the URL as the subject, you've got RDF", then I believe that would 
> cover a large portion of the "JSON as RDF" A/D user segments.

I think if you added that string to every property, the Group A folks
would revolt in a hurry.   Can you think of a way one could conduct that
experiment, without risking the the business?

Also, that's a pretty simple bit of JSON.  How about try it with
something a bit more complicated, like a tweet?   (I took the first
public one to come along, and put it below.)   How much would you have
to change this to make the RDF triples trivial to extract -- so trivial
you don't need a library?   And after that change, would Group A still
be happy with it?

My proposal is that we have one Group B/D solution, something like
JTriples, and another Group A/C solution which can read just like this
JSON (for Group A) and also map it to RDF for group C.  The mapping
would be declarative and found by any of several mechanisms, including
an "@rdfmapping" property (aka @context) and a .well-known file (in
case one wants to keep the text completely untouched).

   -- Sandro


  {"in_reply_to_status_id_str":null,
   "id_str":"57307996111384576",
   "in_reply_to_status_id":null,
   "text":"#itssadwhen ppl have smellly feeet",
   "contributors":null,
   "retweeted":false,
   "in_reply_to_user_id_str":null,
   "source":"web",
   "truncated":false,
   "entities":{"hashtags":[{"text":"itssadwhen",
       "indices":[0,
           11]}],
        "urls":[],
        "user_mentions":[]},
   "coordinates":null,
   "geo":null,
   "place":null,
   "in_reply_to_user_id":null,
   "favorited":false,
   "user":{"id_str":"34764739",
    "default_profile_image":false,
    "verified":false,
    "profile_background_tile":false,
    "contributors_enabled":false,
    "show_all_inline_media":false,
    "geo_enabled":true,
    "profile_link_color":"0099CC",
    "profile_image_url":"http:\/\/a3.twimg.com\/profile_images\/1120719334\/45094_150056601684716_100000411302461_359019_6757717_n_normal.jpg",
    "follow_request_sent":null,
    "friends_count":60,
    "profile_sidebar_border_color":"fff8ad",
    "description":"workaholic",
    "screen_name":"Jhenyfer88",
    "statuses_count":174,
    "profile_use_background_image":true,
    "profile_background_color":"FFF04D",
    "location":"ewing\/edison",
    "listed_count":0,
    "lang":"en",
    "profile_background_image_url":"http:\/\/a3.twimg.com\/a\/1301071706\/images\/themes\/theme19\/bg.gif",
    "protected":false,
    "notifications":null,
    "name":"Jhenyfer ",
    "time_zone":null,
    "favourites_count":9,
    "created_at":"Thu Apr 23 23:09:56 +0000 2009",
    "profile_text_color":"333333",
    "id":34764739,
    "is_translator":false,
    "default_profile":false,
    "following":null,
    "utc_offset":null,
    "profile_sidebar_fill_color":"f6ffd1",
    "followers_count":14,
    "url":null},
   "retweet_count":0,
   "id":57307996111384576,
   "created_at":"Mon Apr 11 05:04:25 +0000 2011",
   "in_reply_to_screen_name":null}



> Best,
> 
> Nathan
>

Received on Monday, 11 April 2011 05:23:46 UTC