Re: [JSON] market segments

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...

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