Re: Social API: Scope

I have been following this conversations and webID one for the last month and language is a current struggle. I think I would rather define a standard that one should respect, as long as existing language have the level of expressivity we define.

It is not just about coolness, but about convenience. JSON is clearly the language of data used in the industry and the language that web developers are the most familiar with. To adopt JSON-LD, is just a “@context” field, to adopt the rest is a new language. But you know, people will make parsers and the market will judge on what language we should use.

I think language is a “layer below” what we should be doing here. As long as they are pretty much interchangeable, pick one, move fast, do examples.

I am pretty new to this field, so forgive incorrect content. I am here to learn how to avoid bottlenecks.

On 03 Aug 2014, at 10:57, henry.story@bblfish.net wrote:

> 
> On 3 Aug 2014, at 19:14, Erik Wilde <dret@berkeley.edu> wrote:
> 
>> the assumption here being that tomorrow, RDF might be cool. maybe it will be, and we'll see tomorrow, i guess. to quote tim bray, what matters is the bits on the wire. it's kind of hard to get around this simple truth. cheets, dret.
> 
> Teenagers make their decisions based on coolness. As you get older you try to make
> them based on experience, and where possible try to use foundations that are secure.
> In this case maths, logic and web architecture.
> 
> The idea is simple: You specify the meaning of the words, then you allow the data to be expressed in whatever
> syntax is more convenient.  Because it is useful to have a default, you take the fashion of the
> moment - currently JSON-LD - as the serialisation on the wire to agree on. 
> 
> For those with legacy software one can the write a JSON to JSON-LD mapper
> to make integration easier.
> 
> Then if between the time you start this process and the time it ends you find another
> serialisation more fashionable ( say as happend with Atom between Tim Bray - father of 
> XML - pushing it, and a few years later when JSON started becoming cool ), then you
> don't have to change all the existing software. 
> 
> That also makes a lot of economic sense, which it is true is what managers tend
> to think as being cool. So I can't completely escape being cool. (sigh!)
> 
> 
>> 
>>> On Aug 3, 2014, at 10:01, "henry.story@bblfish.net" <henry.story@bblfish.net> wrote:
>>> 
>>> 
>>>> On 3 Aug 2014, at 18:53, Harry Halpin <hhalpin@w3.org> wrote:
>>>> 
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>> 
>>>> 
>>>> 
>>>>> On 08/03/2014 06:02 PM, Erik Wilde wrote:
>>>>> hello james.
>>>>> 
>>>>>> On 2014-07-31, 10:32 , James M Snell wrote:
>>>>>> FWIW, AS2 does not *re-base* itself on JSON-LD, it aligns with 
>>>>>> JSON-LD. It's a critical difference.
>>>>> 
>>>>> i think this will get interesting when it comes to defining an
>>>>> extension model. what was great about AS1 was that it had both an
>>>>> XML and a JSON syntax, so it was useful for both communities. once
>>>>> you subscribe to some layer higher than that, it gets a bit
>>>>> trickier to have a well-defined domain-based extension model,
>>>>> without resulting in rather horrible structures in one of the
>>>>> underlying syntaxes.
>>>>> 
>>>>> i tried to work on an AS2 XML encoding for a little while
>>>>> (analogous to http://activitystrea.ms/specs/atom/1.0/), because it
>>>>> might be helpful to also serve the XML/Atom community. but it gets
>>>>> rather tricky to translate AS2's "alignment" with JSON-LD into
>>>>> reasonable XML constructs. that's because as an XML user, you'd
>>>>> like to see XML's/Atom's extension model to be used rather than
>>>>> some more complicated way of folding what's required by JSON-LD
>>>>> into some generic XML mapping.
>>>>> 
>>>>> i think it wold be important to discuss whether an XML syntax is a 
>>>>> requirement. if it is, my guess is that this will have some
>>>>> implications for how much layered models such as JSON-LD can be
>>>>> used, and where the line has to be drawn to avoid dependencies on
>>>>> their implicit models.
>>>> 
>>>> Actually, according to the charter only a JSON-based syntax is a
>>>> requirement. The WG can of course have an XML syntax, but the focus on
>>>> should be on JSON.
>>>> 
>>>> cheers,
>>>>   harry
>>> 
>>> If the group would manage to agree at the semantic level ( ie, one 
>>> an RDF vocabulary for whatever ) with a default
>>> syntax ( say JSON ), then these issues would just go away. 
>>> 
>>> Otherwise you'll just spend two years debating syntax issues. Yesterday
>>> XML was cool. Right now JSON is. Sometime in the future something else
>>> will be....
>>> 
>>> Henry
>>> 
>>> 
>>> 
> 
> Social Web Architect
> http://bblfish.net/
> 
>