[foaf-protocols] First WebID Teleconference minutes (July 27th 2010)
kidehen at openlinksw.com
Tue Aug 3 00:26:33 CEST 2010
Henry Story wrote:
> On 2 Aug 2010, at 23:55, Kingsley Idehen wrote:
>>> Then when you speak to customers use a different word. Most RFC use technical language like SHOULD, MUST, RDFXXXX etc. Customers don't care.
>> I said "People", no mention of "Customers :-)
> People don't read specs either. People use social networks.
> Engineers read specs, and then very few of them do. When they do they
> want something that is clear, precise and solid.
>> The issue is communicating the value proposition of a technology without distraction. RDF is a distraction magnet.
> That's an exaggeration, sorry. The terminology is clear, and well documented.
I have nothing to gain by exaggerating problems with RDF.
I am sure you know I use RDF extremely extensively. I even use the thing
I criticize the most (RDF/XML) extensively, but none of that detracts
from its historic challenges when it comes to value prop. articulation.
> The maths is solid. We can clarify a few concepts if needed, but we can't avoid RDF and semantics.
> People will see how flexible it is as we use it.
> But frankly if that bothers you, then lets forget the spec.
So this is an RDF spec? No RDF over emphasis or no spec? I am saying:
tone it down a little re. RDF, that's all.
I am fundamentally concerned about the following:
1. FUD protection
2. Clear articulation of the value prop. of WebIDs and the WebID protocol.
Again, deliverables from OpenLink should demonstrate that RDF/XML is
something we use extensively, the fact that we use it doesn't make it
impervious to serious issues re. value prop. articulation.
On a different note, I spent years trying to get the Mozilla folks to
stick with RDF (which again was RDF/XML to them) and even tried to get
the HTML5 folks to give RDF a chance instead of the myopic SQLite based
interface for the Web Database API. All of this had no specific benefit
to us (OpenLink) since leaving SQL as the sole data access mechanism
works fine for a company that can route SPARQL and RDF via SQL channels
to its own multi protocol and multi model DBMS (Virtuoso). The fact the
we are able to do that doesn't stop me advocating to these parties how
they should really construct abstract data access APIs.
Its really important that we stop being over protective about RDF, its
history isn't good (when it comes to value prop. articulation and
uptake), and Linked Data is not a product of RDF (as initially
prescribed) neither is it inextricably bound to RDF oriented data
formats. If anyting, Linked Data was about side stepping all RDF
distractions and just getting on with the real task of unleashing HTTP
based Structured Linked Data. Ironically, the one the few bits of
semantics that crept in (owl:sameAs) remains the single biggest Linked
Data distraction to date.
President & CEO
More information about the foaf-protocols