[foaf-protocols] WebID - mandated syntax or market solution? was WebID Incubator Charter draft
henry.story at bblfish.net
Fri Dec 17 16:54:25 CET 2010
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.
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.
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
Social Web Architect
More information about the foaf-protocols