2008/11/27 Juan Sequeda <juanfederico@gmail.com> > Hugh, > > Nice point brought up. > > What I do see is that even though we can't make a sql query to the facebook > db, we can use the api's to obtain data. Same as some many different > applications that offer api. > > Now imagine LOD as the data that a developer can obtain from an api. In > this case, instead of learning the api of several different applications, he > learns the vocabulary. The same way nowadays developers get the data from > different apis to make mashups, LOD is another form of making mashups, but > much better. > > I agree that having a sparql endpoint for everyhting may not be safe. That > is why we started thinking about SQUIN [1]. If the data is out there, it is > linked, it is dereferenacble, and it's open, well make the query on SQUIN, > and let SQUIN get the data for you. > There is still the issue of people wanting to do more advanced things with the data in an efficient manner. Resolvable URI's are great, but if you have to resolve every single URI to finish queries which should be simple with sparql like reverse links (eg. http://bio2rdf.mquter.qut.edu.au/links/geneid:12345), then you either have to make up URI's that stand in for the queries, as Bio2RDF have done (see [1]), or you provide SPARQL access. A system that just resolves data URI's to a local cache won't be able to efficiently perform global queries as efficiently as one where the queries are converted to URI's and access to the actual SPARQL endpoint is effectively prevented for long running, performance hampering queries because it is behind the resolver. Cheers, Peter [1] http://bio2rdf.mquter.qut.edu.au/admin/configuration/rdfxml
Received on Thursday, 27 November 2008 00:57:15 UTC