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

Kingsley Idehen kidehen at openlinksw.com
Fri Dec 17 19:13:41 CET 2010


On 12/17/10 10:54 AM, Henry Story wrote:
> The group should if all goes well start by Jan 10 2010. It would be
> best if everyone can work on improving their implementations by then.
> I'll be working on improving Clerezza.
>
> We seem to have had no problem for the moment dealing with different
> formats... Let's see how things work out in practice.

+1

Kingsley
> Henry
>
> On 17 Dec 2010, at 16:42, Jiří Procházka wrote:
>
>> On 12/17/2010 01:50 PM, Kingsley Idehen wrote:
>>> On 12/17/10 3:46 AM, Jiří Procházka wrote:
>>>>> I outline a repeating pattern above re. our industry. RDF's futile
>>>>>> attempt to break this time tested pattern that has led to its negative
>>>>>> (typically) and enigmatic status (at best) over the years. Claiming to
>>>>>> be everything (markup - RDF, model - RDF, and logic - RDF) only makes
>>>>>> matters worse.
>>>> To be a bit blunt, it means you disregarded my original concern and
>>>> failed to understand the people this part of WebID should cater for.
>>> What? I don't understand the profile of person WebID should cater for?
>>>
>>> I've spent 90% of my professional career in the middleware space (mixing
>>> and matching data and protocols).
>>>
>>> I've been integrating data (as described above) since the late '80s.
>>>
>>>> What you suggest, is that WebID should be a heterogenous system of
>>>> sometimes interoperable, sometimes not applications for years to come,
>>>> like RDF app land is now (I disagree that RDF tried to enforce one
>>>> mandatory syntax, that it failed and it failed because of it) and web
>>>> was pre-HTTP.
>>> So you are saying to me that the Web is 100% interoperable at all levels?
>>>
>>> To be more precise, that HTTP is used consistently across the Web?
>>>
>>>> Why and how HTTP came out as a "winner"?
>>> 1. Data Representation is decoupled from Data Access Protocols
>>> 2. Data Representation is distinct from Data Presentation
>>> 3. Platform agnostic.
>>>
>>> Again, HTTP isn't used consistently on the Web, most developers don't
>>> even understand or exploit content negotiation. It is a major success
>>> because of the points above which enable it to deliver untethered
>>> client-server computing without platform lock-in.
>>>
>>> The emergence of Linked Data showcase how we can up the ante by
>>> combining URIs and HTTP as based for Distributed Data Objects. Network
>>> oriented Objects with de-referencable Identifiers at Network scale
>>> (intranet, extranet, Internet).
>>>
>>> There is a graveyard full of initiatives that preceded HTTP -- in the
>>> distributed computing realm -- that failed due to any combination of
>>> items 1-3 above.
>>>
>>>>   I would argue it
>>>> is because it seemed for most people the syntax which could by
>>>> understood by most clients, not because of its superiority, which is
>>>> exactly what I've been saying we should create and call WebID, like now
>>>> Web is understood as using HTTP.
>>> WebID leverages HTTP, URIs, and Linked Data. That's inherently potent
>>> and doesn't need any syntax distraction re. RDF.
>>>
>>> HTTP based Linked Data took off because HTML (no RDFa in it at the time)
>>> was used as an alternative representation to RDF for pages read by
>>> humans. A nuanced move from the LOD community exemplified by the DBpedia
>>> project. Prior to this effort RDF existed in its own litter vacuum.
>>>
>>> History is always the greatest teacher.
>>>
>>>> You think implementors can live in such syntax-reality-show system, well
>>>> yes, some can, but I say a lot of them refuse to.
>>> So let's move them to RDF covertly?
>>>
>>> Implementers ultimately seek the most productive path for implementing a
>>> clearly understood concept. They don't start with Syntax.
>>>
>>>>   They want to trust to
>>>> rely on WebID like they rely on TCP/IP stack, which is impossible
>>>> without at least one mandatory syntax. You say choosing such mandatory
>>>> syntax would deter many people, I say a lot more will be deterred by
>>>> lack of it and the assurances it provides.
>>> Well I disagree, and time will prove one of us wrong.
>>>
>>>> If you knew me a lot more, you would learn that I would let almost
>>>> anything for market to sort out, but for machine languages is simply not
>>>> practical nor efficient. There is a large crowd of people who would
>>>> stick out the flag "Hey we don't want to participate in this popularity
>>>> contest, lets choose something basic, simple which just works and can be
>>>> relied on, and call it WebID".
>>> I don't really get your point. Primarily because I have no sense of how
>>> you've arrived at these conclusions.
>>>
>>> My views are based on hard core experience based on many years of
>>> dealing with interoperability, where data access and integration is the
>>> prime focus. Middleware has been my focus forever, pre Web.
>>>
>>>>  From a general perspective all the people who would reinvent WebID (with
>>>> different mandated syntax, or no at all like you wish) would create the
>>>> market of competing syntaxes you like. In other words, by choosing a
>>>> mandated syntax you loose nothing.
>>> WebID isn't about syntax. It's actually about Logic.
>> 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).
>> 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.
>> 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.
>>
>> 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.
>>
>> Best,
>> Jiri
>>
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> Social Web Architect
> http://bblfish.net/
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols


-- 

Regards,

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







More information about the foaf-protocols mailing list