[foaf-protocols] WebID - mandated syntax or market solution? was WebID Incubator Charter draft

Kingsley Idehen kidehen at openlinksw.com
Fri Dec 17 21:20:43 CET 2010

On 12/17/10 1:32 PM, Jiří Procházka wrote:
> On 12/17/2010 07:13 PM, Kingsley Idehen wrote:
>> On 12/17/10 10:42 AM, Jiří Procházka wrote:
>>> Like you say, the Web isn't 100% interoperable. So anyone waving with
>>> "Web compatible" badges is not taken seriously. I expect people using
>>> "WebID compatible" badges same like they use "OpenID 2.0 compatible"
>>> now, and I think I am not alone.
>>> My point isn't that WebID would be worthless if there is no mandatory
>>> syntax (at least one; best be it just one).
>> The alternative is to have a variety of syntax examples for EAV model
>> based structured data.
>> ASN.1 is an old notation which is also used for EAV based data encoding.
>> I don't recommend it, but that doesn't mean it wouldn't be useful to
>> others with toolkits for handling data encoded using this markup language.
>>> My point is that for majority of consumers, "WebID badge" would be
>>> useless, since they couldn't point their app at any WebID praying it
>>> supports at least one syntax their app supports.
>> So for those who can't get over the "one syntax" or "a syntax" issue, I
>> suggest making examples using a variety of syntaxes.
>> Thus, if this is an inclusive party, post concept comprehension,
>> examples would come in from people who prefer specific syntaxes for
>> encoding EAV model data.
>>> I dare to say there will be much more people concerned about this than
>>> people like you would would be deterred by existence of mandated syntax.
>> I am not deterred by anything.
>> Again, we (at OpenLink) benefit (basically competitive advantage+++++++)
>> if it's RDF. This is the strange irony that you aren't discerning from
>> my commentary. That still doesn't compel be to sit back on the issue of
>> RDF.
>> I want this party to be devoid of RDF distractions. Even if I (or
>> OpenLink) have huge advantages with RDF anything. Being inclusive must
>> be the number goal.
>>> Repeating myself, the core protocol (the logic as you say), should be
>>> abstract as possible, fulfilling the 3 points you mention above, but for
>>> the usability sake, lets call WebID the spec which would benefit the
>>> most from a simple striking name "WebID" is - the one requiring
>>> inclusive usage of one mandated syntax, making the "badges" actually
>>> useful.
>> There are many ways to encode EAV, so there should be a variety of
>> markup based examples. Anything less will ultimately inject inertia into
>> WebID uptake momentum.
>> The letters "R-D-F" still turn of a majority of people (profile: Web
>> Developer) , instinctively.
>>> Best,
>>> Jiri
> No, you are missing the point, this isn't about RDF at all, I mentioned
> RDF only because it would be convenient if the mandated syntax was also
> RDF serialization. Please lets not talk about RDF any more.


> The issue is whether the "supports WebID" should mean "supports the
> WebID Protocol with at least syntax XYZ" or just "supports the WebID
> Protocol, eventhough it may speak to you in syntax which would be
> incomprehensible to your software, thus spewing a confusing error message".

It speaks the protocol. The data that the protocol operates on should be 
structured such that: an Entity (Subject), its Attributes (Predicates), 
and Attribute Values (Predicate Objects) are clearly discernible to 
machines and humans.

Representations should be negotiated between clients and servers.

> Some people just want to have the guarantee the latter won't happen -
> exactly the people I said you weren't considering in your
> let-the-best-syntax-win idea.

HTTP lets you negotiate Structured Data Representation.

> Also even if we fairly soon settle on a set of syntaxes which would
> cover 99% of WebIDs in the wild like Henry hopes, still this would be a
> "set of syntaxes" which is rising the implementation costs compared to
> having to support just the one syntax (if you are willing to sacrifice
> the possible advantages of the other probaly newer ones).

See comment above re. content negotiation.

> Realistically, there will be a range of implementations from feature and
> syntax support rich, to bare bones implemetations *both on the publisher
> side and the client side*. If we want even the bare bones
> implementations to be interoperable, they have to use the same syntax.

They have to grok the model and negotiate preferred structured data 

> Otherwise the nice and striking "WebID" name is just good to use on
> academic papers and conferences.

WebID isn't popular in academic circles. Most implementations to date 
aren't from academia :-)


> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols



Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20101217/19ed54e8/attachment-0001.htm 

More information about the foaf-protocols mailing list