Re: Mandatory client supported serializations

Not everyone belongs to the google web concept. In realty, google is irrelevant (tho google apps may be big, being an outsourced LAN ).

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

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



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

Received on Friday, 30 December 2011 23:50:25 UTC