Re: [JSON] market segments

On Thu, 2011-03-17 at 14:57 +0100, Ivan Herman wrote:
> Great summary. Because I am a visual type, I created an excel sheet with the tables (attached both an excel and a iWork version). Maybe it will be helpful for others...

And since you know how I love mediawiki...  here's the wiki version:

http://www.w3.org/2011/rdf-wg/wiki/JSON_User_Segments

    -- Sandro

> Ivan
> 
> 
> On Mar 17, 2011, at 02:54 , Sandro Hawke wrote:
> 
> > On Thu, 2011-03-17 at 00:20 +0100, Thomas Steiner wrote:
> >> Hello all,
> >> 
> >> While I love "GRDDL for JSON" as a name, I'm still not sure it is a
> >> generalizable functionality that would be straight-forward to offer.
> >> As I said today on IRC, isn't it one-offs for each and every single
> >> JSON data provider? Isn't the objective of this WG to come up with
> >> something that JSON data providers would use in the first place? We
> >> can still provide (or document how to provide)
> >> mappings/goggles/"GRDDL", but in my opinion this shouldn't be our
> >> primary goal. Lots of questions to be discussed at the F2F or earlier.
> >> Maybe I simply got the concept wrong, though. Thanks for corrections
> >> in either case.
> > 
> > Thinking about it, I'm seeing a spectrum of the folks who send data
> > using JSON and their relationship to RDF and this effort.  In order of
> > least-RDF-friendly to most-RDF-friendly.....
> > 
> > Level 1 - Folks who publish json data which cannot be easily mapped to
> > RDF and are not willing to do anything about it.  If a translator-to-RDF
> > is done for their data, it will have to be complex (probably using a
> > Turing Complete language ) and done without their participation.
> > 
> > Level 2 - Folks who publish json data which has a fairly clean mapping
> > to RDF (basically namespaces prefixes and property types), but are still
> > not willing to do anything at all to help RDF consumers.
> > 
> > Level 3 - Folks who are willing to help with the mapping, and have the
> > mapping information served from their website in a way that machines can
> > find.  But they don't want non-RDF json users to see any hint of RDF in
> > their actually data stream.
> > 
> > Level 4 - Folks who are willing to add a few little flags to their json
> > data, such as the URL of the mapping-to-RDF declaration.
> > 
> > Level 5 - Folks who are willing to include all the necessary information
> > for mapping their json to RDF, so their data can be converted without
> > additional dereferences.    This probably goes along with having a json
> > data design that is close enough to RDF that the mapping is pretty
> > trivial, so maybe they had to design their json a bit differently.
> > 
> > Level 6 - Folks who are willing to make their main json feeds
> > specifically designed for RDF compatibility, probably making their json
> > seem a little odd to people with a feel for json.   These are the folks
> > that I think the charter requires us to address; it's debatable how much
> > we should cater to levels 1-5.   (I think helping levels 3-5 is
> > desirable, but might not be practical.
> > 
> > Level 7 - Folks who are willing to provide their data in RDFa, RDF/XML,
> > or Turtle.   These folks don't actually need us to do anything in the
> > json space.
> > 
> > 
> > I think there are also some different segments among developers (json
> > users):
> > 
> > Group A - Developers consuming data from a relatively small number of
> > sites, willing to do custom coding for each site (eg hardcoding how to
> > read news streams from twitter *and* facebook).   These folks probably
> > want very comfortable and obvious json they can use without libraries.
> > That's what they get now, and they wont like the json to get messier.  I
> > don't think we can offer anything to this group; our job is avoid making
> > their lives difficult or annoying them.
> > 
> > Groups B+C - Developers who do not want to do custom coding per data
> > source.  They want to see those news streams in some common interface,
> > so they don't need special code for each one.  That sounds like RDF to
> > me.   (These developers are also working on behalf of users who don't
> > want to hire more developers for each data site.)  Now, this group can
> > be divided into:
> > 
> > -- Group B, Developers who want the generality of RDF but don't want to
> > use any sort of RDF API.  For them we could try to make a format the
> > Level-6 producers will publish and which Group-B developers can consume
> > without complex code or a library/API.
> > 
> > -- Group C, Developers who want the generality of RDF, but are willing
> > to use an RDF API.   What they really need is for their libraries to
> > support Level-N sources, for as low an N as possible.  They would be
> > most happy if they have RDF API access to even Level-1 sources, without
> > having to do any work.  (This could potentially be done with some sort
> > of open repository of javascript modules which translate various
> > publishers' json to RDF.  I think level-3 is as low as this WG can go,
> > though.)
> > 
> > Looking at this matrix of 21 boxes (in my head), I'm seeing two sweet
> > spots, where we could do some good: 6-B and 3/4/5/6-C.  I'm worried that
> > 6-B is over-constrained (anything we do will annoy Group A -- we went
> > through this with RDF and XML), so I think our best bet is probably
> > 3/4/5/6-C.     At least, that's how it looks to me right now.   This is
> > the space of standardizing annotations, occurring inline or out-of-band,
> > which enable deterministic, efficient conversation of "normal" json into
> > RDF triples, by a library.    
> > 
> > Note that for this space (1) we don't need to serialize every kind of
> > RDF graph, and (2) the json is "pretty" (but not RDFy) for Group-A
> > folks, but can be converted by standard code, eventually built into
> > various libraries, to RDF for Group-C folks.  Group B may just be out of
> > luck any way we slice it.
> > 
> >     -- Sandro
> > 
> > 
> > 
> > 
> >> Best,
> >> Tom
> >> 
> >> Thank God not sent from a BlackBerry, but from my iPhone
> >> 
> >> On 16.03.2011, at 23:27, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:
> >> 
> >>> 
> >>> 
> >>> On 16/03/11 17:07, David Wood wrote:
> >>>> On Mar 16, 2011, at 10:59, Richard Cyganiak wrote:
> >>>> 
> >>>>> On 16 Mar 2011, at 01:11, Manu Sporny wrote:
> >>>>>> I know that Richard did a good job writing up an argument for a
> >>>>>> triple-based serialization, but even the write-up wasn't a
> >>>>>> glowing recommendation for that approach.
> >>>>> 
> >>>>> Fair enough.
> >>>>> 
> >>>>>> PROPOSAL: The RDF Working Group should design the RDF in JSON
> >>>>>> syntax structure to reflect the object-based data model that is
> >>>>>> in wide use in the Web developer community. The group recognizes
> >>>>>> that both the triple-based and iterative-reduction based
> >>>>>> approaches are useful and have a purpose to serve, but the time
> >>>>>> it would take to standardize two RDF in JSON syntaxes may impact
> >>>>>> the ability for the Working Group to meet its tight 1-year
> >>>>>> deadline.
> >>> 
> >>> The time argument only makes sense if you are talking about the same people swapping between the two extremes.  From the discussions so far, that's far from clear to me.
> >>> 
> >>>>> 
> >>>>> I'd prefer not having to vote on this proposal yet, because there
> >>>>> are certain clarifications and discussions that I'd like to see
> >>>>> before making up my mind.
> >>>>> 
> >>>>> My concerns here are:
> >>>>> 
> >>>>> 1. It appears to me that the goal of the RDF-in-JSON approach as
> >>>>> championed by Manu is not to serialize an RDF graph in a JSON
> >>>>> syntax, but to standardize a system of JSON conventions that allow
> >>>>> parsing of the output of existing JSON APIs (perhaps with small
> >>>>> modifications) as RDF.
> >>> 
> >>> I agree.
> >>> 
> >>> Sometimes it sounds more like "GRDDL for JSON".  The mapping isn't universal - the generation of IRIs from data that has sufficiently unique keys is application dependent, for example.
> >>> 
> >>>>> 
> >>>>> 2. If I am mistaken in thinking so, then I observe that a lot of
> >>>>> Manu's arguments in favour of the object-based approach fall apart,
> >>>>> especially those regarding �picking up the developers where they
> >>>>> are right now.�
> >>>>> 
> >>>>> 3. If my observation regarding the goal of this RDF-in-JSON
> >>>>> approach is correct, then I think we need discussion about charter
> >>>>> scope and WG composition, as the goal appears somewhat broader than
> >>>>> what the WG was chartered for.
> >>>> 
> >>>> Perhaps, but this seems like a reasonable conversation to have.
> >>>> Let's get the proposal fully on the table and then take it off if we
> >>>> need to (or coordinate with other groups as appropriate).
> >>> 
> >>> Then the phrase "RDF in JSON" seems the wrong way round.  It's "JSON as RDF".
> >>> 
> >>> PROPOSAL: The RDF Working Group JSON Task Force will work on way of mapping typical existing JSON data objects into a form that can be interpreted as RDF.
> >>> 
> >>> 
> >>> Feel free to suggest a better wording - this is just a quick draft to try to find a proposal that is about the core issue directly, and not indirectly by talking about syntax structure.
> >>> 
> >>>   Andy
> >>> 
> >>>> 
> >>>> Regards, Dave
> >>>> 
> >>>> 
> >>>> 
> >>>>> 
> >>>>> Best, Richard
> >>>> 
> >>>> 
> >>> 
> >> 
> >> 
> > 
> > 
> > 
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
>

Received on Thursday, 17 March 2011 16:40:29 UTC