Re: Mandatory client supported serializations

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