Re: Social API: Scope

On 3 Aug 2014, at 20:18, Nicola Greco <me@nicolagreco.com> wrote:

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

yes, there are a few json-ld parsers for everyone to use so it is certainly convenient.

The point of the RDF framework, is that it solved the problem of how to turn the web 
into a distributed hyerlinked database. I suppose what we wish to create here is 
a platform for a distributed social web, where I can have my profile one one server and link to your profile,
activity streams or whatever on a different server, and so on recursively, in a uniform manner. RDF provides
the framework for that. All that we need to agree on now is the vocabulary to allow us to work together.
Since this group has decided on a JSON based syntax, we can move with JSON-LD. 

We could start by seeing if activity streams can be expressed in JSON-LD, by simply writing out the vocabulary
for it.

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

If you can automate the problem, then you can move very fast. The Resource Description Framework allows you
to map automatically between different syntaxes, and even - if you add reasoning - between vocabularies. 
I add immediately and with emphasis that it helps to reduce reasoning ( which can be expensive ).
This can be done simply by agree on a common vocabulary.  Again a reasonable engineering decision.

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

It is pretty easy if you can learn to distinguish between syntax and semantics. I wrote up a short blog
post in 2005 when I was working at Sun Microsystems on the Atom syntax with Tim Bray.  

  https://blogs.oracle.com/bblfish/entry/the_relation_between_xml_and

At the time JSON-LD did not exist, so I could not use it in my example. But it would be easy to
write the example in JSON-LD too. A server can serve a number of representations for the same URI.
This is known as content-negotiation. So that older and new software can interact without trouble.

Tim Bray got stuck on syntax. Time has shown that to be a mistake. If we avoid this blockage,
then the job of this group will be a lot easier, move on a lot faster, and be extreemly productive.

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

Social Web Architect
http://bblfish.net/

Received on Sunday, 3 August 2014 19:22:36 UTC