[foaf-protocols] WebID Incubator Charter draft
kidehen at openlinksw.com
Thu Dec 16 21:55:37 CET 2010
On 12/16/10 3:19 PM, Jiří Procházka wrote:
> On 12/16/2010 08:57 PM, Kingsley Idehen wrote:
>> On 12/16/10 1:52 PM, Jiří Procházka wrote:
>>> On 12/16/2010 07:24 PM, Kingsley Idehen wrote:
>>>> On 12/16/10 11:00 AM, Jiří Procházka wrote:
>>>>> I am not sure I comprehend you. My idea was, that WebID should be a
>>>>> for technology of interoperable implementations.
>>>> WebID Protocol. That's what I am talking about. No different from
>>>> essence of your comment.
>>>>> I don't think there
>>>>> would be much value for having "WebID-RDF" and WebID-OData" or
>>>>> each being a separate ecosystem if non-interoperable implementations of
>>>>> the abstract WebID protocol.
>>>>> For the implementations to be
>>>>> interoperable, there has to be some choices regarding minimal
>>>>> requirements on syntax.
>>>> A misconception. You can keep syntax out of the picture, really.
>>>> There are many ways to encode an Entity-Attribute-Value graph. You would
>>>> be amazed the degree to which most structured data encoding boils down
>>>> to EAV graphs. Even better, this boils down to FOL (re. Logic based
>>>> Conceptual Schema).
>>>> RDF is a provincial distraction, and a very expensive one at that, when
>>>> you factor in the vast community of people (pre. Web) that comprehend
>>>> EAV graphs and FOL.
>>>> Keep RDF syntax out, and these communities are all going to comprehend,
>>>> appreciate, aid development of, and adopt WebID -- everyone feels the
>>>> pain of the problem it solves.
>>> I don't think we understand each other here. There is non-negligible
>>> amount of possible implementors who would like to implement their
>>> client, and forget about it, expecting it to work with any other WebID
>> No doubt, but RDF creep isn't the solution.
>> Example the Concept, let implementers encode the data using a common
>> model based on a logic based conceptual schema (basically what "RDF is
>> everything" obscures).
> Can you expand on this? What is this logic based conceptual schema?
In a nutshell, EAV based 3-tuples. SPO/EAV is FOL when all is said an
done re. underlying model. The problem is "RDF is Everything" clouds this.
RDF's Graph Model and EAV are a bunch of labels for the same thing:
The problem is RDF narrative is too conflated, and this overeach repels
or confuses people outside the SemWeb community.
Making EAV 3-tuples with resolvable URIs, scoped to Named 3-tuple
Containers (Named Graphs) which may or may not represent a philosophical
universe of discourse is something lots of folks already understand very
well. We want to engage rather than alienate said folks.
RDF is markup, best to leave it at that. Just as HTML is markup. And
guess what, beneath both sits EAV guided by FOL.
>>> This means they won't have some magical client code which learns
>>> all the other WebID syntaxes, which would people invent pretty much like
>>> RDF serializations (even if they downloaded some freely available
>>> library from the web, I don't think there would be any which would
>>> support all serializations - again, like with RDF). So there needs to be
>>> some canonical syntax, which every client would support, exactly because
>>> of these implementors (after all, syntax independence is quite new for
>>> some people, especially network programmers who are used to strict
>>> syntax defined by RFCs etc.).
>> That's like saying, we can't have EAV model based Linked Data atop
>> Relational Data Sources unless Relational Database vendors commit to a
>> common syntax at the very least.
>> In reality a Relational Tables based DBMS and Relational Property Graph
>> DBMS are both based on FOL. The key difference boils down to
>> implementation choices made by RDBMS folks not allowing Reference Types.
>> Today, many younger RDF folks would categorize RDBMS to RDF
>> transformation as some new age magic. In reality, this is just an
>> exercise re. discovering a common base i.e., FOL.
>>> When we agree, that there needs to be some canonical syntax, question
>>> rises: which? It can be any RDF serialization, OData, or some other EAV
>>> based syntax.
>> Just a EAV graph. When you pull back the encoding of most structured
>> data in the wild today (and from the past) you will find EAV at the
>> base, and spin to the side its basically FOL logic.
>>> My arguments for some RDF serialization are that we don't have to market
>>> the syntax as RDF serialization - being it brings the advantage, that if
>>> implementor chooses some of the wide range of already available
>>> libraries supporting it (another plus), he gains power to understand any
>>> other metadata which might be stored with the WebID, for free, making
>>> the endless range of RDF vocabularies and its expressive power available
>>> to WebID publishers, hopefully creating the open social web, which many
>>> of us strive for.
>> The mistake is assuming that we need a syntax based lingua franca for
>> this to work. We just need logic and a variety of encodings.
>> If we keep RDF in the "implementers choice box", and emphasize
>> structured data via EAV model, there will be an arms race to implement
>> WebID, and in the process people will choose the most productive route
>> (enter RDF and its family of syntaxes).
>> Let's emphasize the logic of the system while leaving syntax choices to
>> developers of libraries and full blown WebID based solutions. In due
>> course, the most productive bits win out.
>> I choose to learn Unix before learning MS-DOS in the late '80s, it
>> remains the best decision I've made on the professional skills front to
>> date. Through Unix (POSIX) I discovered TCP/IP and plethora of key
>> infrastructure components that weren't anywhere close to being the
>> global standards they are today; at a time when plurality reigned at
>> every conceivable technology infrastructure turn.
>> The best stuff always wins out long term, especially when it isn't
>> forced on anyone i.e., its own merits simply bubble to the surface via
>> productivity gains.
> I agree EAV might be the best common model for our purpose, but for
> certain use, there is need for "syntax based lingua franca".
> I think I start to understand your position - if I am right, you propose
> the market to solve what syntax is used the most.
> I agree with that too,
> but on the other hand consider this - for each syntax there are certain
> pros and cons, which guide how people decide if to adopt them. I see no
> harm in settling on a syntax, which single purpose and advantage would
> be its support, even if in every other aspect other syntaxes would
> dominate it. Basically adopting it would mean compatibility with all
> implementations of WebID.
But.... RDF has a major image problem. It also has a stubbornness
problem, so the net effect is net negative for endeavors like this.
> If you know another way of dealing with this and maintaining fully
> interoperable system, please explain it to me.
I've tried. It can be done without mandating a lingua franca -- overtly
Let's make a spec that describes how the system works.
We are very close to something big, but I am still very queasy about
stubborn RDF and its ability to distract.
Again, when I write about RDF in this way it's quite ironic. We (at
OpenLink) do so much work using RDF and understand its big-time
benefits. The thing is, people have to find this out for themselves. In
some cases, by attempting to reinvent it :-)
> PS: I don't believe in building another and another abstraction layers
> on top each other - languages for describing languages for describing
>>>>> Of course separating the specs in WebID abstract protocol semantics and
>>>>> WebID the interoperable system spec is fine and I encourage that, but
>>>>> lets make sure the latter is understood by the label "WebID", not the
>>>> WebID Protocol is what this is about :-)
>>> foaf-protocols mailing list
>>> foaf-protocols at lists.foaf-project.org
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foaf-protocols