On 6/11/13 12:05 PM, Martynas Jusevic(ius wrote:
I disagree completely that RDF is not Web-native. Read-write RDF Linked Data is the way the Web was supposed to be, in my opinion.
Solutions are the only way to demonstrate that RDF based Linked Data is native to the Web. The same approach applies to the fact that the Web was always designed to be Read-Write medium.
We will make little progress without demonstrable solutions, let's keep cranking out those solutions :-)
Imagine Linked Data without DBpedia and the Linked Open Data cloud, all of Linked Data's potential would be locked in theory-laden permathreads etc..
Kingsley
MartynasOn Jun 11, 2013 5:33 PM, "Alvaro Graves" <alv...@graves.cl <mailto:alv...@graves.cl>> 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. 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. I do believe however that RDF is 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. I tend to agree with Rufus re. the diagnosis ("RDF is not web native"), but I differ in the solution. 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. I know there are many efforts on this regard, but there are many opportunities we haven't considered. 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. 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. Alvaro Graves-Fuenzalida Web: http://graves.cl - Twitter: @alvarograves On 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
