Re: RDF's challenge

On 6/11/13 10:30 AM, Alvaro Graves wrote:
> When talking to web developers, they tell me they find little benefit 
> on using RDF. This is due to two main reasons, in my opinion (there 
> may be others, for sure):
>
> - Lack of usable tools: How many good, stable tools for managing data 
> in RDF are available out there? How many are for CSV? Even an array of 
> arrays is good enough sometimes.
> - Lack of usable data: In the case of Open Government Data, there are 
> tons of CSV documents available. Modeling data as RDF requires an 
> extra effort, which most people won't take, since they already have 
> the data available.
>
> If you add the fact that tabular data is easier in many cases easier 
> to understand (or at least we are more used to) I can understand why 
> many developers don't like RDF.

In my experience, they don't like RDF because they don't understand RDF. 
Even worse, the things make RDF confusing are the very ones that are 
hardest to remove from its narrative. Simple example, many RDF advocates 
want to conflate Linked Data and RDF. This is technically wrong, and 
marketing wise -- an utter disaster.

As outlined in my opening of this thread, CSV and RDF can be quite 
complimentary. You can start the process of discovery from a CSV browser 
en route to understanding what RDF actually brings to the table. All 
that's achievable without getting lost in the depths of RDF model 
theory, abstract vs concrete syntaxes etc..


> The cherry on top is the the fact that URIs are not human-friendly 
> (ok, CURIEs makes it easier, I admit it), so the Semantic Web does not 
> look very attractive to web developers.

Not CURIEs, what we have to do is ensure that when RDF based Linked Data 
is published we apply some of the following guidelines:

1. associate every entity a literal label -- rdfs:label will do
2. if possible, associate every entity with a depiction -- thumbnail 
graphics will do.

A visualizer then has the ability to keep HTTP URIs out of sight via 
<a/> without losing their reference and de-reference prowess. In 
addition, a depiction enables visualizers to use visual queues in 
addition to labels en route to the same goal I just mentioned.

>
> I do believe however that RDF is a great data model.

It has a great data model :-)

> For example, features of SPARQL 1.1, (I'm thinking on property paths 
> here) and the use of inference can give you a powerful workbench to 
> work with.

Yes!

> I tend to agree with Rufus re. the diagnosis ("RDF is not web 
> native"), but I differ in the solution.

Well I think RDF is native to the Web. It's some hardcore narratives and 
rhetoric  around it that I find alien to the Web. I say that because at 
the core of the Web lies core principles such as tolerance, openness, 
engagement, and sharing. Basically, where there is a will there also 
lies a foundation to bridge differences.

I believe in turning CSV vs RDF into CSV and RDF via Linked Data, for 
instance.

> For me, instead of getting rid of a nice data model such as RDF, we 
> need is to provide usable tools, usable for developers at least.

To get the tools development ecosystem going we have to actually 
encourage those that are actually building those tools. Historically, 
that hasn't been the case, all too often tools developers are 
discouraged since their work is typically visible as targets of 
criticism or folks basically pretend they don't exist.

In my eyes, every tool that goes through the process of implementing the 
guidelines in TimBL's original Linked Date meme is an awesome tool, period!

> I know there are many efforts on this regard, but there are many 
> opportunities we haven't considered.

Naturally, it's a continuum.

> We need easier ways to take data and convert it, manage it and use it, 
> and the tools for that should be at least as simple as other common 
> tools.

Yes, learning from existing tools is a vital part of the process. Ditto 
learning from patterns that have worked elsewhere rather that 
reinventing the wheel afresh.
>
> I need to bring David Karger's article (based on his keynote at ESWC) 
> at 
> http://groups.csail.mit.edu/haystack/blog/2013/06/10/keynote-at-eswc-part-3-whats-wrong-with-semantic-web-research-and-some-ideas-to-fix-it/. 
> I think he expresses with great clarity some of the problems of the 
> SemWeb community and RDF in particular.

Yes-ish, because it also inadvertently implies that nothing exists 
that's close to solving the problem bar the solutions presented in the 
paper, which isn't accurate.


Kingsley
>
>
>
> Alvaro Graves-Fuenzalida
> Web: http://graves.cl - Twitter: @alvarograves
>
>
> On Tue, Jun 11, 2013 at 1:49 PM, Phil Archer <phila@w3.org 
> <mailto:phila@w3.org>> wrote:
>
>     Thanks for picking this up Kingsley.
>
>     I'd just like to highlight the end of the report [1] where I've
>     described what we're proposing to our members on this, namely a
>     new WG that will look specifically at CSV and the metadata needed
>     to easily transform it into RDF or any other format. Jeni's work
>     and others are inputs to that group. All being well it'll be
>     chartered in the early autumn but we have hoops to go through first.
>
>     I gave a talk on this at SemTech last week and made a slidecast
>     version [2]. It sets out a bunch of things we're doing or
>     proposing to do at W3C in the imminent future.
>
>     Cheers
>
>     Phil.
>
>     [1] http://www.w3.org/2013/04/odw/report#next
>     [2] http://philarcher.org/diary/#semtech
>
>     On 11/06/2013 14:00, Kingsley Idehen wrote:
>
>         All,
>
>         "/RDF isn't natural --- and therefore is barely used --- by
>         the average
>
>         Web developer or data wrangler. CSV, by contrast, is. And you
>         are going
>         to need to win the hearts and minds of those folks for
>         whatever approach
>         is proposed/." -- Rufus Pollock (OKFN) [1][2].
>
>
>         RDF is actually natural.  Unfortunately, narratives around it
>         have now
>         created the illusion that its unnatural. We observe our world
>         using
>         patterns much closer to RDF (entity relationship graphs) than
>         CSV (when
>         used a mechanism for Tabular representation of entity
>         relationships).
>
>         SPARQL enables one to expose RDF based data in a myriad of
>         ways will
>         also enabling easy to comprehend Linked Data utility (i.e.,
>         HTTP URI
>         based super keys that specically resolve to documents that
>         describe a
>         URIs referent).
>
>         Following the Open Data meeting I stumbled across a CSV
>         browser [3]
>         developed by @JeniIT . I took a quick look and realized it
>         could provide
>         the foundation addressing some of the confusion around Open
>         Data, RDF,
>         and Linked Data. Thus, I had one of our interns simply tweak
>         the CSV
>         browser such that on receipt of SPARQL-FED protocol URLs that
>         resolve to
>         CSV formatted data you end up with a Linked Data browser.
>
>         The simple example above basically showcases how Linked Data
>         aids data
>         discovery using the Web's basic follow-your-nose exploration
>         pattern by
>         leveraging what CSV has to offer i.e., using a format that
>         many (users
>         and developers) are already familiar with as a bridge builder
>         en route
>         to showcasing the virtues of RDF, SPARQL, and Linked Data.
>
>         Links:
>
>         [1] http://www.w3.org/2013/04/odw/report -- Open Data Report.
>         [2]
>         http://blog.okfn.org/2013/04/24/frictionless-data-making-it-radically-easier-to-get-stuff-done-with-data/
>         .
>         [3] https://github.com/theodi/linked-csv-browser -- CSV Brower
>         [4] https://github.com/theodi/linked-csv-browser/pulls -- pull
>         request
>         that sniffs for HTTP URIs and then makes them live links
>         [5] http://bit.ly/18axeTP -- tweaked version of CSV browser
>         showcasing
>         effects of live links based on a SPARQL-FED URL (Ordnance
>         Survey) that
>         returns data in CSV format
>         [6] http://bit.ly/ZxSUnc -- ditto using data form
>         health.data.gov <http://health.data.gov>.
>
>
>     -- 
>
>     Phil Archer
>     W3C eGovernment
>
>     http://philarcher.org
>     +44 (0)7887 767755 <tel:%2B44%20%280%297887%20767755>
>     @philarcher1
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen