[foaf-protocols] WebID Incubator Charter draft
ojirio at gmail.com
Thu Dec 16 21:19:48 CET 2010
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?
>> 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.
If you know another way of dealing with this and maintaining fully
interoperable system, please explain it to me.
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
-------------- 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/20101216/c79d2ae5/attachment.pgp
More information about the foaf-protocols