[foaf-protocols] WebID - mandated syntax or market solution? was WebID Incubator Charter draft
ojirio at gmail.com
Fri Dec 17 19:32:11 CET 2010
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
> 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
> 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.
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".
Some people just want to have the guarantee the latter won't happen -
exactly the people I said you weren't considering in your
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).
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.
Otherwise the nice and striking "WebID" name is just good to use on
academic papers and conferences.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20101217/64eed6d4/attachment.pgp
More information about the foaf-protocols