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 do2. 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: @alvarogravesOn Tue, Jun 11, 2013 at 1:49 PM, Phil Archer <ph...@w3.org <mailto:ph...@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
smime.p7s
Description: S/MIME Cryptographic Signature
