Re: Mandatory client supported serializations

From: Peter Williams <home_pw@msn.com> · Date: Sat, 31 Dec 2011 15:26:20 -0800

I use my spouse as a measure here (being as unme as it gets)

She likes apple  (but knows she is being screwed). And uses an off wall browser (hosted in ios) to view endless blog posts (commenting depressively, largely).

When it came to our realty (since she is in charge, despite my male ego) it was fun to see to which source she turned.

Yes she wanted 15 google posts (to connect), but she didn't believe any of them. Get from google means rant and rave ( not what one based life decisions on ).

Here in trust land, we have learned to distinguish between security and assurance; even in head strong w3c Land.

Things are looking up. That folks can use the term assurance for what's its worth is a major achievement (that php crowd never made).

Sent from my iPhone
On Dec 31, 2011, at 9:09 AM, "Kingsley Idehen" <kidehen@openlinksw.com> wrote:

> On 12/30/11 6:49 PM, Peter Williams wrote:
>> Not everyone belongs to the google web concept. In realty, google is irrelevant (tho google apps may be big, being an outsourced LAN ).
> Of course Google et al., are irrelevant. But following the "reality and legacy" principle re., bootstrap, they cannot be ignored. Influence, even when its implicitly temporary, matters.
>> 
>> Realty already has syndication mechanisms, and some folks want to negate with bog centric syndication, so realtors (distinct from their brokers, distinct from their listing authority, distinct from regional data shares, distinct from websso-integrated cloud vendors with some service) can craft their own presence. But, the core work is fine for them, and the same data accuracy is present at all delivery points). This is what distinguishes realty information from google (who have been allowed to post low grade snippets about current property, for years).
> 
> No doubt, but when it comes to how and why people acquire "Web Presence" we still have search engines as factors re. discovery. Thus, one has to associate appropriate weight to said factor when contemplating document publishing and associated formats.
> 
>> 
>> Now each realtor tend to network with 20 local vendors, 4 homeowners and 10 buyers. These folks are the public, and it seems viable (at that small scale) for following networks to orchestrate a million such tiny hubs of power, now websso/Openid can authenticate the public. Webid is useful, as it also indirectly does community of trust key distribution, so folks can enjoy (medium quality) secure messaging on price/time sensitive topics
> 
> Yes, but the bootstrap is going to be via HTML snippets that we can squeeze into data spaces offered by the likes of Google, Twitter, Facebook, LinkedIn etc. Of course, this is about "bootstrap" nothing more since folks will eventually end up with their own fully controlled data spaces on the InterWeb :-)
> 
> Kingsley
>> 
>> 
>> 
>> Sent from my iPhonenitu
>> 
>> On Dec 30, 2011, at 1:54 PM, "Kingsley Idehen"<kidehen@openlinksw.com>  wrote:
>> 
>>> On 12/30/11 5:38 PM, Jiří Procházka wrote:
>>>> Well probably the main reason I wrote that is because it is also to
>>>> consider in the choice of mandatory serializations.
>>>> So far it seems WebID is set on requiring a more or less random bunch of
>>>> serializations based on guessing what mostly the publishers are going to
>>>> want to use, which has following aspects:
>>>> + publishers get more freedom of choice
>>>> - hard implementing client code
>>>> - probably limiting the WebID use by high serialization parsing requirements
>>>> - alienating the fans of not chosen seralizations
>>>> 
>>>> Now lets consider the alternatives:
>>>> 2) chooising 1 syntax with low parser requirements (n-triples?)
>>>> + easy to implement client
>>>> + low client implementation requirements
>>>> - less choice on publisher side
>>>> - alienating the fans of not chosen serializations
>>>> 
>>>> 3) write the core spec by NOT requiring ANY specific serialization, but
>>>> create a separate document specifying a restrictions for creating an
>>>> interoperability "trade"mark, which carries all the points of 1) (maybe
>>>> lessening the - of alienation) but maintaining the WebID core
>>>> serialization agnostic, which is good modularity which avoids the
>>>> conflict of interests wanting the WebID to be most open and flexible and
>>>> wanting it to be a central piece of reliably interoperable network.
>>>> 
>>>> Feel free to add + and - points to the above, I just want to know why is
>>>> 1) the way WebID is headed, not 3).
>>>> I know I am not participant of WebID XG, nor I have any implementation
>>>> ready, but I don't think that any of those facts makes my point less
>>>> logically valid.
>>>> 
>>>> Best,
>>>> Jiri
>>>> 
>>>> PS: I didn't add the subjective point of supporting the client side is
>>>> more important then giving mroe choice to the publishers
>>>> 
>>>> On 12/30/2011 07:53 PM, Henry Story wrote:
>>>>> On 30 Dec 2011, at 20:42, Jiří Procházka wrote:
>>>>> 
>>>>>> Hi,
>>>>>> I think WebID should be flexible enough to be used on low memory
>>>>>> embedded systems, does this put any restrictions on the mandated
>>>>>> syntaxes? I figure turtle because of prefixes would be no go, and other
>>>>>> syntaxes too - the algorithm for webid validation (client code),
>>>>>> including the parsers for all required syntaxes, would be best to have
>>>>>> constant space complexity...
>>>>>> I don't think such concerns nor the use case are so outlandish they
>>>>>> shouldn't be taken in consideration.
>>>>> I am trying to keep that in mind and keep in mind development for the freedombox.
>>>>> Swap-scala from Dan Connolly seems to indicate that you can write parsers in very little
>>>>> space for all the well known serialisations.
>>>>> 
>>>>>   http://code.google.com/p/swap-scala/

>>>>> 
>>>>> So there is a lot that can be done I think to reduce the space consumption of tools like Jena.
>>>>> 
>>>>> Henry
>>>>> 
>>>>> 
>>>>>> Best,
>>>>>> Jiri
>>>>>> 
>>>>>> _______________________________________________
>>>>>> foaf-protocols mailing list
>>>>>> foaf-protocols@lists.foaf-project.org
>>>>>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

>>>>> Social Web Architect
>>>>> http://bblfish.net/

>>>>> 
>>> Kicker here is "alienation of some set of syntax fans."
>>> 
>>> We can surmount this problem via HTML with a structured data island as the base. We are then left with HTML+Microdata, HTML+RDFa, and XHTML+RDFa as vehicles for the aforementioned base document type.
>>> 
>>> Methinks, most will use HTML+Microdata to publish due to the influences of search engine vendor appeasement. Remember, stuff goes on the Web to be discovered. For now, Google is extremely influential and important.
>>> 
>>> 
>>> -- 
>>> 
>>> Regards,
>>> 
>>> Kingsley Idehen
>>> Founder&   CEO
>>> OpenLink Software
>>> Company Web: http://www.openlinksw.com

>>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen

>>> Twitter/Identi.ca handle: @kidehen
>>> Google+ Profile: https://plus.google.com/112399767740508618350/about

>>> LinkedIn Profile: http://www.linkedin.com/in/kidehen

>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen    
> Founder&  CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com

> Personal Weblog: http://www.openlinksw.com/blog/~kidehen

> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about

> LinkedIn Profile: http://www.linkedin.com/in/kidehen

> 
> 
> 
> 
> 
> 